Transform transitions are broken in slideshow on https://store.ui.com/ (images just flash from one to the next), unless I disable Partial Prerender
Categories
(Core :: CSS Transitions and Animations, defect)
Tracking
()
Webcompat Priority | P2 |
People
(Reporter: dholbert, Assigned: hiro)
References
(Blocks 1 open bug, )
Details
Attachments
(2 files)
STR:
- Visit https://store.ui.com/collections/accessories/products/u-poe-af
- Hover the product image on the right side of the page, and click the
>
button to advance to the next image. - Repeat step 2 a few more times (clicking through the various images)
EXPECTED RESULTS:
When you advance the preview-image, the old image & new image should slide across smoothly.
ACTUAL RESULTS:
The first transition has a smooth image-sliding effect, but after that, the slideshow is quite jumpy and usually just jumps directly from one image to the next.
Chrome gives EXPECTED RESULTS.
Firefox Nightly gives ACTUAL RESULTS.
Additional observations:
- If I set
layout.animation.prerender.partial
tofalse
, then I get expected results. - WebRender doesn't make any difference here. (It's enabled by default for me, and force-disabling it does not help. And turning off partial-prerender does reliably work around the bug, whether or not WebRender is on.)
I'm using Firefox Nightly 85.0a1 (2020-11-27) (64-bit).
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 1•3 years ago
|
||
(This seems related to bug 1668073, but it's not exactly a dupe, since that other bug can be worked around by disabling WebRender whereas this one cannot.)
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Comment 2•3 years ago
|
||
Profile:
https://share.firefox.dev/37l0mtX
First click is at about 2.3s, and that plays a smooth transition as you can see in the screenshot track for the ~second after that.
Second click is at about 4.4s, and third is at 6.6s. Neither of those get a smooth transition (as you can see if you hover over the screenshot track for the time period after those clicks).
Assignee | ||
Comment 3•3 years ago
•
|
||
This is not a reduced test case generated from the site in question, but it's representing what the underlying problem is.
The underlying problem is that when the inner most clip frame is inside the reference frame of the transform, we don't need to apply the offset from the reference frame when we check jank, but we do apply it both for WebRender and nonWebRender.
Updated•3 years ago
|
Assignee | ||
Comment 5•3 years ago
|
||
Ksenia, can you please attach an HTML file to reproduce the instagram issue? I'd like to see whether it's a dup of this issue or new one, but I have no account on instagram unfortunately.
Comment 6•3 years ago
|
||
I've attached a slightly reduced test case. Not sure why, but it's only reproducible if that gray circle placeholder exists on the page
Assignee | ||
Comment 7•3 years ago
|
||
Ksenia, thanks for the reduced case! You are absolutely right, the instagram case is exactly same as this bug, i.e. overflow:hidden element inside the transform reference frame.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•2 years ago
|
Comment 9•7 days ago
|
||
As far as I could tell the sites listed here that are still up seem to work now? Is anyone able to reproduce or should we close this one as WFM?
Comment 10•7 days ago
|
||
Ah, I guess we should actually have marked this as a dupe of 1678702 or vice-versa. But that one has the important information that the feature was disabled, so I'll make this a dupe of that.
Description
•