w3c / IntersectionObserver

Intersection Observer
https://www.w3.org/TR/intersection-observer/
Other
3.62k stars 523 forks source link

Define the implicit root better in presence of adoption to a different browsing-context tree. #456

Open emilio opened 4 years ago

emilio commented 4 years ago

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

emilio commented 4 years ago

cc @smfr

szager-chromium commented 4 years ago

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.

emilio commented 4 years ago

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.