1517168 - CSS Transition sometimes jumps back and forth between initial position and current position

Status: NEW

(Core :: CSS Transitions and Animations, defect, P3)

Description

[Xidorn Quan [:xidorn] UTC+10]

I observe this weird behavior when I'm trying to refactor some animation with CSS Transitions in Canva. I tried to build a reduced testcase from scratch, but haven't got any luck.

If this sounds like a duplicate, feel free to close it. I'll try to dig into it further and see if I can build a simple testcase otherwise.

Comment 1

[Xidorn Quan [:xidorn] UTC+10]

Set a ni? flag for myself for now.

Comment 2

[Brian Birtles (:birtles)]

I don't recall any bugs like this. One consideration might be whether or not it is running on the compositor. If you can't reproduce it using 'left' for example, it might be related to updating transitions on the compositor.

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

Attachment: testcase

OK, so I got a testcase.

When you move mouse in the viewport, the small block should try to follow the cursor with a delay.

However, in Firefox, the block doesn't move when you are still moving mouse. Sometimes it flickers like what I described in the summary, but with this testcase that behavior not very reproducible, though I think I still see that sometimes. Maybe when the JavaScript is more busy, the flickers happen more frequently.

The problem here seems to be the setTimeout. If I do the style update synchronously, or use requestAnimationFrame instead, the problem doesn't show up.

I tested latest nightly with and without WebRender, and nothing seems to help with this case.

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

Actually, it seems that WebKit is suffered from the same issue. It's even more serious than Gecko. Blink is the only engine from my testing so far which seems to work as expected.

Comment 5

[Brian Birtles (:birtles)]

Attachment: Test case using top/left

If you do the same with top/left you still get undesirable results (due to the setTimeout tasks not getting a chance to run when there is a flood of mousemove events) -- but you see the same in Chrome too.

I expect the jerkiness in the original report is due to our special transition updating code we use for compositor animations (introduced to make Firefox OS transitions smoother).

I do seem to recall there being another bug recently where that code was problematic.

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #4)
> Actually, it seems that WebKit is suffered from the same issue. It's even
> more serious than Gecko. Blink is the only engine from my testing so far
> which seems to work as expected.

Actually... Safari doesn't have this problem, it was Safari Technology Preview which has this problem as well, so it's a regression for them.

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

FWIW I filed a bug for WebKit here: https://bugs.webkit.org/show_bug.cgi?id=193088

Comment 8

[georg.pukk]

Attachment: Test case using setInterval + comparison with filter

Comment 9

[georg.pukk]

The bug does not occur when you're in dev tools' "Inspector" tab and hovering a mouse cursor over the dom tree.