Fixed
Status Update
No update yet.
Comments
sc...@chromium.org
Thanks for the very thorough report. Unfortunately I have no idea when we'll have a chance to look at it. Is this affecting a production site?
[Monorail components: Blink>Paint>Invalidation]
[Monorail components: Blink>Paint>Invalidation]
fs...@opera.com
This sounds similar to https://crbug.com/chromium/1281085 (and a few other issues). I'd agree the two symptoms described are likely to have the same root cause (for the scrollbar case I'd think it's a sign of multiple passes, where the width from the first end up being used).
ji...@gmail.com
> "Is this affecting a production site?"
Sorf of, I've been experimenting with SVG based responsive animations and stumbled upon the issues I've reported and also on #1297837 (gave it a star).
Luckily, there's nothing impossible to work around and in my case the hack
```
element.style.transform = "none";
setTimeout(() => {
element.style.transform = "";
}, 0);
```
works just fine to force a redraw and render things properly :)
Sorf of, I've been experimenting with SVG based responsive animations and stumbled upon the issues I've reported and also on #1297837 (gave it a star).
Luckily, there's nothing impossible to work around and in my case the hack
```
element.style.transform = "none";
setTimeout(() => {
element.style.transform = "";
}, 0);
```
works just fine to force a redraw and render things properly :)
[Deleted User] <[Deleted User]>
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.
Sorry for the inconvenience if the bug really should have been left as Available.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Sorry for the inconvenience if the bug really should have been left as Available.
For more details visit
sz...@chromium.org
This still reproduces on tip-of-tree.
The general issue seems to be that we're not invalidating layout for the transformed rect when we should be.
The "extra scrollbar space" issue is most likely based on the fact that when we layout a new page for the first time, we always assume a vertical srollbar. If we determine after the first layout that the page doesn't have vertical overflow, then we remove the vertical scrollbar.
[Monorail components: -Blink>Paint>Invalidation Blink>Layout]
The general issue seems to be that we're not invalidating layout for the transformed rect when we should be.
The "extra scrollbar space" issue is most likely based on the fact that when we layout a new page for the first time, we always assume a vertical srollbar. If we determine after the first layout that the page doesn't have vertical overflow, then we remove the vertical scrollbar.
[Monorail components: -Blink>Paint>Invalidation Blink>Layout]
sz...@chromium.org
ikilpatrick@, can you investigate the layout angle?
is...@google.com
This issue was migrated from crbug.com/chromium/1311813?no_tracker_redirect=1
[Multiple monorail components: Blink>Layout, Blink>SVG]
[Monorail blocked-on:crbug.com/chromium/709437 ]
[Monorail components added to Component Tags custom field.]
[Multiple monorail components: Blink>Layout, Blink>SVG]
[Monorail blocked-on:
[Monorail components added to Component Tags custom field.]
fs...@opera.com
Looks like this was fixed by c9c7acaff6811f4e65bd8c02908c454a5b048319
Description
Steps to reproduce the problem:
1. Have an <svg> with a size in percentages (most importantly width)
2. Create 2 identical shapes (e.g. <rect>)
3. Set `transform="scale(-1, 1)"` and `transform-origin="center"` for one of the shapes
What is the expected behavior?
The 2nd rectangle must be perfectly mirrored
What went wrong?
The 2nd rectangle doesn't have correct horizontal position.
I've done some investigation and found out that after initial draw the 2nd rectangle has incorrect offset which makes up the exact width of a scroll bar if it were there. So it seems for some reason that inexistent scrollbar reduces width of svg container used in transform-origin calculations.
The interesting part is that making <body> `overflow: hidden` eliminates this issue further supporting the scroll bar theory.
(check min.html)
ALSO
This report is kinda 2 in 1 but I believe the 2nd bug is either closely related to the main one or in fact the same thing.
So the 2nd bug is that if you resize the window the image won't change, but it's expected that transition-origin will change as the width changes preserving the mirror image.
Both of the bugs can be "cleared" by briefly setting `transform: none` style and then removing it (I guess it just triggers redraw which uses all correct values)
(check index2.html)
It's a more visually representative showcase of both bugs. When you resize the window you will see that the path changes for both shapes as expected but transformed one won't have its transform-origin updated resulting in incorrect position. Click left mouse button to trigger force redraw so it must look correct after.
Did this work before? N/A
Does this work in other browsers? No
In Firefox the behavior is the same, while on iOS Safari it works properly
Chrome version: 99.0.4844.84 Channel: stable
OS Version: 10.0