Bug 204116 – [Web Animations] Retargeted transitions targeting accelerated properties do not stop the original transition

• Component: Animations
• Status: RESOLVED FIXED

[Antoine Quint]

Created attachment 383358 [details]
Test

Open the attached test case and move your mouse over the text and quickly out of it. You'll notice that the opacity transition to fade the text out completes anyway even if you've moved out of the element.

[Radar WebKit Bug Importer]

<rdar://problem/57116961>

[Antoine Quint]

As far as I can tell, there are two issues here:

1. calling cancel() and setting its timeline to null for an accelerated animation has no effect, or at least calling AnimationTimeline::cancelDeclarativeAnimation() does not.

2. while we correctly call AnimationTimeline::cancelDeclarativeAnimation() while hovering out of the text, we don't create a reverse transition. I think this is because the opacity style doesn't reflect the animated value, we'd have to ask the computed style for that.

[Antoine Quint]

Created attachment 383439 [details]
Patch

[Antoine Quint]

The test imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html is failing on WK1 bots, investigating.

[Antoine Quint]

*** Bug 193088 has been marked as a duplicate of this bug. ***

[Dean Jackson]

Comment on attachment 383439 [details]
Patch

Can this be a new WPT?

[Antoine Quint]

The transitioncancel in the test "CSS Transitions transitioncancel event fires on disabled form elements" is not dispatched although it is queued.

[Antoine Quint]

Committed r252455: <https://trac.webkit.org/changeset/252455>

[Truitt Savell]

It looks like imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html

is also failing now on iOS bots.

history:
https://results.webkit.org/?suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fdom%2Fevents%2FEvent-dispatch-on-disabled-elements.html&platform=mac&platform=ios

tracked in: https://bugs.webkit.org/show_bug.cgi?id=204223

[Aakash Jain]

EWS also indicated this test failure on mac. Seems like the fix was made (but wasn't run through EWS and landed directly), and unfortunately it broke iOS.

The uploaded patch and the commit r252455 are different.

This failure is slowing down ios-wk2 EWS.

[WebKit Commit Bot]

Re-opened since this is blocked by bug 204272

[Aakash Jain]

The rollout(r252526) broke the build, probably because there were other commits landed after r252455, which depended on r252455.

This code was re-landed in r252527. 

Please have a look at the original test failure (imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html).

[Antoine Quint]

Committed r252540: <https://trac.webkit.org/changeset/252540>

[Aakash Jain]

(In reply to Antoine Quint from comment #13)
> Committed r252540: <https://trac.webkit.org/changeset/252540>
Now this test is flaky on iOS. Tracked in Bug 204509.

[Antoine Quint]

If we decide to roll this out, I think we also need to roll out r252461, the fix for https://bugs.webkit.org/show_bug.cgi?id=204198.

[Antoine Quint]

And most likely the follow up r252540.