haikuwebkit/LayoutTests/animations/animation-followed-by-two-t...

13 lines
399 B
Plaintext
Raw Permalink Normal View History

REGRESSION (r263729): Carousel freezes on "fourth page"/fourth click on right arrow on netflix.com https://bugs.webkit.org/show_bug.cgi?id=215655 <rdar://problem/65845979> Reviewed by Dean Jackson. Source/WebCore: On netflix.com, when clicking on the left and right arrows in each movie or TV show carousel, the page attempts to animate to the next page of the carousel using a CSS transform transition. The logic applies `transform` and `transition` CSS properties to a container `div`, and adds a `transitionend` event listener which the page expects to be invoked when the animation is complete. While waiting for this `transitionend` event, the script also sets a boolean flag that prevents the carousel from being advanced to any other page. However, after the changes in r263729, the carousel gets into a state where `transition` and `transform` styles are set, but the animation never begins, and thus, no subsequent `transitionend` event is observed. This causes the page to believe that the carousel is indefinitely animating, so it never unsets the boolean flag, which results in the carousel being permanently stuck. This occurs because we now have logic in `AnimationTimeline::updateCSSTransitionsForElementAndProperty` that moves the `CSSTransition` from the element's map of running transitions to the map of completed transitions in the case where the corresponding `WebAnimation` is already in `Finished` state. However, consider the case where there is no matching backing animation (i.e. `matchingBackingAnimation` is `nullptr`); for instance, this can happen if the transition CSS property is set to none in the middle of the `transitionend` event, as demonstrated in the new layout test. Before the change, we would've removed the `CSSTransition` from the map of running transitions and canceled it, but now, we instead move it to the map of completed transitions, where it remains until the next CSS transition update is triggered (which would potentially be indefinitely long!). On netflix.com, this next CSS transition update happens the page attempts to advance the carousel. Since the old `CSSTransition` is still in the "completed" transitions map, we end up returning `true` when checking `propertyInStyleMatchesValueForTransitionInMap`, and consequently never attempt to create a new `CSSTransition` and add it to the map of running transitions in step 1 of the algorithm. As described above, this causes the carousel to get stuck in a bad state. To fix this, we simply revert to pre-r263729 behavior in the case where the matching backing animation was already removed, and allow step 3 of the algorithm to cancel the running animation and remove it altogether instead of moving it into the element's completed transitions map. Test: animations/animation-followed-by-two-transitions.html * animation/AnimationTimeline.cpp: (WebCore::AnimationTimeline::updateCSSTransitionsForElementAndProperty): LayoutTests: Adds a layout test inspired by animation logic used in the broken carousel UI on netflix.com. This test can be manually run by opening the test in a browser and verifying that the green square quickly slides across the screen twice, and two `transitionend` events are observed in the process. * animations/animation-followed-by-two-transitions-expected.txt: Added. * animations/animation-followed-by-two-transitions.html: Added. Canonical link: https://commits.webkit.org/228472@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@265985 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2020-08-21 00:12:05 +00:00
The test passes if the animationend event is followed by two transitionend events.
On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE".
PASS Observed 'animationend' event. Starting first transition...
PASS Observed first 'transitionend' event. Starting second transition...
PASS Observed second 'transitionend' event.
PASS successfullyParsed is true
TEST COMPLETE