Bug 273928 – IntersectionObserver callback for a visible sentinel node within a container with CSS transform animations is triggered multiple times, but should only be triggered once

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore JavaScript

[koolc]

We can reproduce this issue using this demo (https://codepen.io/S-L-the-lessful/pen/mdYdyKL). 

In the demo, when the page loads, you will see the first line of the log, indicating that the visible sentinel node has triggered the IntersectionObserver callback function. 

Then, after you click the test button, if more logs continue to appear, it means that there is a problem with the IntersectionObserver implementation logic in the current environment, and it does not meet expectations. Conversely, no matter how the viewport size is adjusted, the speed of clicking the button, or the height of the sentinel is changed, if no additional logs are output (only the first log), then it indicates that the IntersectionObserver implementation logic in the current environment is correct and meets expectations.


After testing the above demo in the following device environments, we have come to the following conclusion: 


1. In browsers such as Safari and iOS WKWebview on mobile and desktop/laptop devices that use the Webkit kernel, the visible sentinel node inside a container with CSS transform animations will trigger the IntersectionObserver callback function multiple times during the container animation process, even though it should only be triggered once.


2. However, in browsers like Chrome, Android App webview, UC etc. that use the Chromium kernel for both mobile and desktop/laptop devices, the visible sentinel node inside a container with CSS transform animations will only trigger the IntersectionObserver callback function once during the container animation process, which is as expected.


This means that in the Webkit environment the IntersectionObserver implementation logic does not meet expectations, therefore we hope that the Webkit community can address and resolve this issue. 

Thanks!

[Ahmad Saleem]

I am able to reproduce this in Safari Technology Preview 193, where after clicking 'test' (different name in demo) button, it logs more while Chrome Canary 126 and Firefox Nightly 127 works fine and same and don't log more like Safari / WebKit.\

Added 'BrowserCompat' tag.

[Radar WebKit Bug Importer]

<rdar://problem/127804335>

[Antoine Quint]

Using https://codepen.io/S-L-the-lessful/full/mdYdyKL, which hides the editors for the pen, I can see Safari log additional messages when pressing the button at a relatively fast pace, while the other browsers do not.

[Antoine Quint]

I think the issue here is that `IntersectionObserver::computeIntersectionState()` calls `targetRenderer->computeVisibleRectsInContainer()` and that this function simply uses for `RenderLayer::transform()` rather than `RenderLayer::currentTransform()`. I believe the former returns a transform as set by the RenderStyle last computed for the associated renderer, which will not contain animated transforms if animations targeting the renderer are accelerated, which will most often be the case for transform-related CSS properties.

Changing the call to `adjustedRects.transform()` in `RenderBox::computeVisibleRectsInContainer()` at least appears to fix this particular sample and does not show immediate regressions under either `LayoutTests/intersection-observer` or `LayoutTests/imported/w3c/web-platform-tests/intersection-observer`.

[Antoine Quint]

Pull request: https://github.com/WebKit/WebKit/pull/28537

[Antoine Quint]

Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/46255

[EWS]

Committed 278763@main (a2fe0bd677be): <https://commits.webkit.org/278763@main>

Reviewed commits have been landed. Closing PR #28537 and removing active labels.