[webkit-changes] [WebKit/WebKit] 19c5bd: pral.com.pk - Double bounce animation compared to ...

[Antoine Quint]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 19c5bd914bfa1fb024e81ef201480315edd4bb7d
      https://github.com/WebKit/WebKit/commit/19c5bd914bfa1fb024e81ef201480315edd4bb7d
  Author: Antoine Quint <graouts at webkit.org>
  Date:   2024-04-29 (Mon, 29 Apr 2024)

  Changed paths:
    A LayoutTests/imported/w3c/web-platform-tests/css/css-transitions/shadow-root-insertion-expected.txt
    A LayoutTests/imported/w3c/web-platform-tests/css/css-transitions/shadow-root-insertion.html
    M Source/WebCore/dom/Element.cpp
    M Source/WebCore/rendering/updating/RenderTreeUpdater.cpp
    M Source/WebCore/rendering/updating/RenderTreeUpdater.h

  Log Message:
  -----------
  pral.com.pk - Double bounce animation compared to other browsers
https://bugs.webkit.org/show_bug.cgi?id=273364
rdar://127188948

Reviewed by Antti Koivisto.

The site pral.com.pk has a list of images under their "ISO CERTIFICATIONS" section that are badges with text
rendered within the raster image. Those images run a transition when hovered. After a short while, the transition
is restarted, and this only happens in Safari, and only the first time a given image is hovered.

WebKit in Safari supports text recognition within images, performed asynchronously, and when text is detected
a user-agent shadow root is inserted within the <img> element to show additional UI. The addition of a shadow root
triggers a full renderer rebuild and this has the side effect of canceling all running style-originated animations
on that element.

This explains why the transition appears to restart, because the initial transition is canceled once text recognition
succeeds, and since the cursor is still over the image, a new transition immediately starts. Since the user-agent
shadow root remains attached, hovering over the image a second time does not exhibit the behavior.

We fixed a similar issue in the past with 240582 at main to deal with a slot change while a transition is running on an
element and introduced a dedicated `TeardownType` value that distinguishes a full rebuild from a rebuild resulting
from a slot change.

We follow the same approach for the case where a shadow root is inserted, adding a new `tearDownRenderersForShadowRootInsertion()`
method which will call the same logic as `tearDownRenderersAfterSlotChange()`, with an inverse assertion as to whether
the provided element has a shadow root attached. This prompted some refactoring of `tearDownRenderers()` as well since
there is a lot of shared code with the aforementioned methods.

We test this with a new WPT test that would fail prior to this change but already works in Chrome and Firefox.

* LayoutTests/imported/w3c/web-platform-tests/css/css-transitions/shadow-root-insertion-expected.txt: Added.
* LayoutTests/imported/w3c/web-platform-tests/css/css-transitions/shadow-root-insertion.html: Added.
* Source/WebCore/dom/Element.cpp:
(WebCore::Element::addShadowRoot):
* Source/WebCore/rendering/updating/RenderTreeUpdater.cpp:
(WebCore::RenderTreeUpdater::tearDownRenderers):
(WebCore::RenderTreeUpdater::tearDownRenderersForShadowRootInsertion):
(WebCore::RenderTreeUpdater::tearDownRenderersAfterSlotChange):
* Source/WebCore/rendering/updating/RenderTreeUpdater.h:

Canonical link: https://commits.webkit.org/278156@main



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications