Closed Bug 1679649 Opened 3 years ago Closed 7 days ago

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)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1678702
Webcompat Priority P2

People

(Reporter: dholbert, Assigned: hiro)

References

(Blocks 1 open bug, )

Details

Attachments

(2 files)

STR:

  1. Visit https://store.ui.com/collections/accessories/products/u-poe-af
  2. Hover the product image on the right side of the page, and click the > button to advance to the next image.
  3. 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 to false, 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).

(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.)

See Also: → 1668073
Flags: needinfo?(hikezoe.birchill)

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).

Attached file A test case

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.

Assignee: nobody → hikezoe.birchill
Status: NEW → ASSIGNED
Flags: needinfo?(hikezoe.birchill)

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.

Flags: needinfo?(kberezina)
Attached file 62835-2.html

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

Flags: needinfo?(kberezina)

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.

See Also: → 1680648
See Also: 1680648
Severity: -- → S3
Webcompat Priority: --- → ?
Webcompat Priority: ? → P2
See Also: → 1676259

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?

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.

Status: ASSIGNED → RESOLVED
Closed: 7 days ago
Duplicate of bug: 1678702
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: