RESOLVED FIXED 204116
[Web Animations] Retargeted transitions targeting accelerated properties do not stop the original transition
https://bugs.webkit.org/show_bug.cgi?id=204116
Summary [Web Animations] Retargeted transitions targeting accelerated properties do n...
Antoine Quint
Reported 2019-11-12 08:31:59 PST
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.
Attachments
Test (621 bytes, text/html)
2019-11-12 08:31 PST, Antoine Quint
no flags
Patch (16.28 KB, patch)
2019-11-13 01:41 PST, Antoine Quint
dino: review+
Radar WebKit Bug Importer
Comment 1 2019-11-12 08:32:17 PST
Antoine Quint
Comment 2 2019-11-12 08:34:59 PST
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
Comment 3 2019-11-13 01:41:14 PST
Antoine Quint
Comment 4 2019-11-13 06:07:43 PST
The test imported/w3c/web-platform-tests/dom/events/Event-dispatch-on-disabled-elements.html is failing on WK1 bots, investigating.
Antoine Quint
Comment 5 2019-11-13 06:25:54 PST
*** Bug 193088 has been marked as a duplicate of this bug. ***
Dean Jackson
Comment 6 2019-11-13 09:35:27 PST
Comment on attachment 383439 [details] Patch Can this be a new WPT?
Antoine Quint
Comment 7 2019-11-14 06:13:53 PST
The transitioncancel in the test "CSS Transitions transitioncancel event fires on disabled form elements" is not dispatched although it is queued.
Antoine Quint
Comment 8 2019-11-14 06:25:30 PST
Truitt Savell
Comment 9 2019-11-15 12:55:30 PST
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
Comment 10 2019-11-16 06:22:29 PST
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
Comment 11 2019-11-16 06:25:22 PST
Re-opened since this is blocked by bug 204272
Aakash Jain
Comment 12 2019-11-16 09:24:01 PST
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
Comment 13 2019-11-18 02:52:00 PST
Aakash Jain
Comment 14 2019-11-22 04:21:20 PST
(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
Comment 15 2019-11-22 11:15:25 PST
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
Comment 16 2019-11-22 11:16:46 PST
And most likely the follow up r252540.
Note You need to log in before you can comment on or make changes to this bug.