Open emilio opened 4 years ago
cc @smfr
The comment in the WebKit code suggests that they intend to match chromium's behavior, which would be fine with me.
I think a case could be made for either behavior; but if I put myself in the shoes of the developer, I could imagine being surprised at not receiving an "intersecting" notification when I insert a target element into another window.
I think a case could be made for either behavior; but if I put myself in the shoes of the developer, I could imagine being surprised at not receiving an "intersecting" notification when I insert a target element into another window.
Yeah, on the other hand it seems weird/sketchy that only for the implicit case one IntersectionObserver can refer to multiple roots, depending on the observation target...
For now I aligned with Gecko with WebKit in https://bugzilla.mozilla.org/show_bug.cgi?id=1670327, because it was more on the lines of what the Gecko code was trying to do before that patch.
https://w3c.github.io/IntersectionObserver/#intersectionobserver-intersection-root says that the implicit root is the document node of the "top-level browsing context".
That makes sense, but if you're observing a node and adopt it into a new window, there are two potential candidates:
Both of those can have different viewports, as https://bugzilla.mozilla.org/attachment.cgi?id=9180905 shows. Which one should be chosen? If we choose the first, the target will presumably never intersect. If we choose the second, then we report intersections against the newly-opened window.
I think both of them would be reasonable. Gecko does something non-sensical in this case. WebKit seems to do the first, and Blink seems to do the second:
We should decide what is the right thing to do here and clarify the spec.
cc @szager-chromium