1930907 - Elements with same translation and transition applied, coming into the view from hidden overflow, have a delay

Status: VERIFIED FIXED

(Core :: CSS Transitions and Animations, defect)

Description

[Tudor]

Attachment: rendertest.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0

Steps to reproduce:
Check out the source of the attached file demo. Or follow these instructions:
Create a group of DOM elements inside a stage that is longer than its container. The overflow is hidden.
Each element is positioned next to another, at a small distance.
Add pointer event listeners with attached handlers that read the user's dragging actions over the stage surface.
Apply the pointer dragging delta value on the X translation value of each element from the group, using a for-loop that adjusts each X coordinate by this delta.

Expected result:
All the DOM elements from this stage should move in lockstep on a dragging action, without any delays, since all of them have exactly the same kind of translations and transition applied at once, collectively.

Actual result:
DOM elements that are outside the viewport of the stage container and which come into view from the hidden overflow area show a graphical delay while rendering the translation on which the same transition string is applied.
You can see this by running the demo I attached in the latest Firefox (132) and comparing that to the latest Chrome (131). Or you could try load the video from the link below -- the Firefox test is on the top side, the Chrome test is on the bottom side.

Video demo:
http://163.172.222.229/temp/v.mp4
(file will be taken down after this case gets resolved)

Don't know how to use the regression tool and don't have time to invest in this, but I did something to help you out. I downloaded past versions of Firefox and tested to see which was the last version in which rendering was normal for this case. That was 123.0. The rendering problem can be seen already in version 124.0, so that will narrow it down for you to just a few intermediary versions.

I imagine it's a similar cause as the last time I reported a rendering bug. You're doing some optimisation somewhere: elements are queued for graphical updates but those in the hidden overflow area get their update on the next tick, to improve performance. But this makes elements in scenarios like this one behave in a way that breaks the logic of "same rules applied to similar elements should behave in the same way". I think browser optimisations should not break how elements should behave according to web standards.

I hope this can get resolved in less than a month. Thanks.

Comment 1

[Tudor]

Forgot to mention: to use the demo, you have to drag the elements inside the visible container.

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a325ddccae9b4381abab92bb365767cb0d052e8d&tochange=7fd3bd56943d8ee09efb1929911f2bfa93f1ef3f

• The former build: There is a slight delay from the dragging start to the start of movement. However, no delay is seen for the added elements.
• The latter build: Just this bug behavior starts.

Comment 3

[Tudor]

Attachment: screencapture.mp4

Comment 4

[Tudor]

It's quite obvious if you watch the video. I attached the video directly to this bug report, because your browser might prevent you from loading a resource from a non-https domain.

Firefox latest (132) can be seen on top.
Chrome latest (131) is on the bottom side of the video.
Found out through testing that this rendering bug appeared somewhere between Firefox version 123 and 124.
FF 123 works normally, performance is not so great like Chrome's, but at least the rendering is correct.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1864425

:emilio, since you are the author of the regressor, bug 1864425, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Attachment: More reduced test-case

Still not minimal, but it's easier to see what's going on now.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

So I think what's happening is that:

• Every time you move the mouse we update the transform.
• The transition is not started the very same frame, because the element is not painted.
• That triggers a new transition, with the old / original start point, rather than the equivalent existing point at the current transition... Or something along those lines.

Comment 8

[Emilio Cobos Álvarez [:emilio]]

So the main difference seems to be that this code only works for transitions currently running in the compositor.

If I remove the IsRunningOnCompositor condition, then it works a lot better. Brian, Boris, do you know why that replaced transition code is limited to compositor animations?

It also seems that we should be able to replace it even if GetStartTime is null, if we have a pending start time...

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1930907 - Allow replacing transitions that are not running on the compositor. r=birtles!,boris

This improves the behavior significantly, but I don't have a lot of
context for this code so careful review would be appreciated :)

Comment 10

[Boris Chiou [:boris]]

We do this only for compositor animations because there may be a time gap between the timing of the creation of this new transition and the timing when we send the transition to the compositor. The time gap may be large because of the busy main thread.

That is the main reason we do this only for compositor animation.

If there are other reasons we have issues when replacing the transitions, perhaps it's fine to tweak a little bit to make sure we have to proper time value.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

I think the issue is that if we cancel the transition and then start a new one, that might introduce a frame delay which accumulates over time, which is what causes the effect in comment 0.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/810b920242d1
Allow replacing transitions that are not running on the compositor. r=boris,birtles

Comment 13

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/810b920242d1

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox133 to wontfix.

For more information, please visit BugBot documentation.

Comment 15

[Emilio Cobos Álvarez [:emilio]]

Probably worth letting it ride the trains.

Comment 16

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2024-11-13 Nightly build on Windows 10, using the testcase from Comment 0.
Verified as fixed on Firefox Nightly 135.0a1 and Firefox 134.0b4 on Windows 10, macOS 14, Ubuntu 22.