RESOLVED FIXED Bug 273364
pral.com.pk - Double bounce animation compared to other browsers
https://bugs.webkit.org/show_bug.cgi?id=273364
Summary pral.com.pk - Double bounce animation compared to other browsers
Ahmad Saleem
Reported 2024-04-27 16:53:21 PDT
Hi Team, While going through random websites, I noticed that Safari / WebKit (STP193 test) had double bounce animations compared to other browsers. Steps to Reproduce: 1) Go to following - https://pral.com.pk 2) From 'About Us', select 'ISO Certification' 3) Hover on following 'ISO Certification' Expected Results: No double bounce in Chrome Canary 126 and Firefox Nightly 127 Actual Results: Double bounce __________ Just wanted to raise to get this fixed. Thanks!
Attachments
Video Recording (Issue) (47.44 MB, video/quicktime)
2024-04-27 16:55 PDT, Ahmad Saleem
no flags
Reduction (310 bytes, text/html)
2024-04-29 03:39 PDT, Antoine Quint
no flags
Ahmad Saleem
Comment 1 2024-04-27 16:55:46 PDT
Created attachment 471185 [details] Video Recording (Issue) Reference Video
Radar WebKit Bug Importer
Comment 2 2024-04-28 01:02:37 PDT
Antoine Quint
Comment 3 2024-04-29 02:50:20 PDT
This only reproduces once per certification badge.
Antoine Quint
Comment 4 2024-04-29 03:02:29 PDT
Not a recent issue, this reproduces in Safari 16.6.
Antoine Quint
Comment 5 2024-04-29 03:08:54 PDT
While there is both a CSS Animation and a CSS Transition specified on those certification images, commenting out the CSS Animation reproduces the issue still, so this seems to be solely an issue triggered by the CSS Transition for the `transform` property.
Antoine Quint
Comment 6 2024-04-29 03:39:47 PDT
Created attachment 471189 [details] Reduction I can reduce it with a single <img> element with a transform transition. That's pretty wild.
Antoine Quint
Comment 7 2024-04-29 08:15:58 PDT
This reproduces with a non-accelerated property and logging CSS Transition events clearly shows the transition running twice. So there's something wrong, specific to images, at the CSS Transitions processing level most likely.
Antoine Quint
Comment 8 2024-04-29 08:23:39 PDT
Doesn't reproduce if the transition is triggered via a style change through script. Could be somehow specific to a :hover-initiated transition.
Antoine Quint
Comment 9 2024-04-29 08:27:49 PDT
Making the transition run longer reveals that, about 1 second after the first transition starts, the first transition gets canceled and a new transition starts.
Antoine Quint
Comment 10 2024-04-29 08:54:27 PDT
This is the stack when the `transitioncancel` event gets triggered: #0 0x000000014ed4dc70 in WebCore::StyleOriginatedAnimation::cancelFromStyle(WebCore::WebAnimation::Silently) at ~/Source/WebCore/animation/StyleOriginatedAnimation.cpp:223 #1 0x0000000151aac230 in WebCore::Styleable::cancelStyleOriginatedAnimations(WTF::Vector<WTF::WeakPtr<WebCore::StyleOriginatedAnimation, WebCore::WeakPtrImplWithEventTargetData, WTF::RawPtrTraits<WebCore::WeakPtrImplWithEventTargetData>>, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc> const&) const at ~/Source/WebCore/style/Styleable.cpp:311 #2 0x00000001519d138c in WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&, WebCore::RenderTreeUpdater::TeardownType, WebCore::RenderTreeBuilder&)::$_1::operator()(unsigned int) const at ~/Source/WebCore/rendering/updating/RenderTreeUpdater.cpp:726 #3 0x00000001519cfd84 in WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&, WebCore::RenderTreeUpdater::TeardownType, WebCore::RenderTreeBuilder&) at ~/Source/WebCore/rendering/updating/RenderTreeUpdater.cpp:774 #4 0x00000001519d0fac in WebCore::RenderTreeUpdater::tearDownRenderers(WebCore::Element&) at ~/Source/WebCore/rendering/updating/RenderTreeUpdater.cpp:667 #5 0x000000014f86f0b4 in WebCore::Element::addShadowRoot(WTF::Ref<WebCore::ShadowRoot, WTF::RawPtrTraits<WebCore::ShadowRoot>, WTF::DefaultRefDerefTraits<WebCore::ShadowRoot>>&&) at ~/Source/WebCore/dom/Element.cpp:2870 #6 0x000000014f881af4 in WebCore::Element::createUserAgentShadowRoot() at ~/Source/WebCore/dom/Element.cpp:3028 #7 0x000000014f881a0c in WebCore::Element::ensureUserAgentShadowRoot() at ~/Source/WebCore/dom/Element.cpp:3020 #8 0x000000014f927b7c in WebCore::ImageOverlay::updateSubtree(WebCore::HTMLElement&, WebCore::TextRecognitionResult const&) at ~/Source/WebCore/dom/ImageOverlay.cpp:377 #9 0x000000014f926404 in WebCore::ImageOverlay::updateWithTextRecognitionResult(WebCore::HTMLElement&, WebCore::TextRecognitionResult const&, WebCore::ImageOverlay::CacheTextRecognitionResults) at ~/Source/WebCore/dom/ImageOverlay.cpp:493 #10 0x0000000119ca0a24 in auto WebKit::WebPage::requestTextRecognition(WebCore::Element&, WebCore::TextRecognitionOptions&&, WTF::CompletionHandler<void (WTF::RefPtr<WebCore::Element, WTF::RawPtrTraits<WebCore::Element>, WTF::DefaultRefDerefTraits<WebCore::Element>>&&)>&&)::$_1::operator()<WebCore::TextRecognitionResult>(WebCore::TextRecognitionResult&&) const at ~/Source/WebKit/WebProcess/WebPage/WebPage.cpp:8848 So that's why this is specific to <img>, we're adding a shadow root to that element when text is recognized within that image. I presume this only happens when the cursor is over that image.
Antoine Quint
Comment 11 2024-04-29 10:19:53 PDT
Antoine Quint
Comment 12 2024-04-29 10:28:07 PDT
Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/45958
EWS
Comment 13 2024-04-29 22:41:21 PDT
Committed 278156@main (19c5bd914bfa): <https://commits.webkit.org/278156@main> Reviewed commits have been landed. Closing PR #27881 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.