-
Notifications
You must be signed in to change notification settings - Fork 522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define the implicit root better in presence of adoption to a different browsing-context tree. #456
Comments
cc @smfr |
Two spec issues here. w3c/IntersectionObserver#457: I think this is just a spec bug and I've made us match other browsers, but since the tests don't match the spec for now I've added them as .tentative.html w3c/IntersectionObserver#456: I've aligned with WebKit here. There was a (disabled) test for this which tests chrome behavior and which after this patch shouldn't be flaky. This is what was causing the assertion. Differential Revision: https://phabricator.services.mozilla.com/D93166
Two spec issues here. w3c/IntersectionObserver#457: I think this is just a spec bug and I've made us match other browsers, but since the tests don't match the spec for now I've added them as .tentative.html w3c/IntersectionObserver#456: I've aligned with WebKit here. There was a (disabled) test for this which tests chrome behavior and which after this patch shouldn't be flaky. This is what was causing the assertion. Differential Revision: https://phabricator.services.mozilla.com/D93166
Two spec issues here. w3c/IntersectionObserver#457: I think this is just a spec bug and I've made us match other browsers, but since the tests don't match the spec for now I've added them as .tentative.html w3c/IntersectionObserver#456: I've aligned with WebKit here. There was a (disabled) test for this which tests chrome behavior and which after this patch shouldn't be flaky. This is what was causing the assertion. Differential Revision: https://phabricator.services.mozilla.com/D93166
Two spec issues here. w3c/IntersectionObserver#457: I think this is just a spec bug and I've made us match other browsers, but since the tests don't match the spec for now I've added them as .tentative.html w3c/IntersectionObserver#456: I've aligned with WebKit here. There was a (disabled) test for this which tests chrome behavior and which after this patch shouldn't be flaky. This is what was causing the assertion. Differential Revision: https://phabricator.services.mozilla.com/D93166
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. |
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. |
Two spec issues here. w3c/IntersectionObserver#457: I think this is just a spec bug and I've made us match other browsers, but since the tests don't match the spec for now I've added them as .tentative.html w3c/IntersectionObserver#456: I've aligned with WebKit here. There was a (disabled) test for this which tests chrome behavior and which after this patch shouldn't be flaky. This is what was causing the assertion. Differential Revision: https://phabricator.services.mozilla.com/D93166 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1670327 gecko-commit: 2906a77771b3abcc15c2859052c0d170b263133d gecko-reviewers: hiro
Two spec issues here. w3c/IntersectionObserver#457: I think this is just a spec bug and I've made us match other browsers, but since the tests don't match the spec for now I've added them as .tentative.html w3c/IntersectionObserver#456: I've aligned with WebKit here. There was a (disabled) test for this which tests chrome behavior and which after this patch shouldn't be flaky. This is what was causing the assertion. Differential Revision: https://phabricator.services.mozilla.com/D93166 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1670327 gecko-commit: 2906a77771b3abcc15c2859052c0d170b263133d gecko-reviewers: hiro
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
The text was updated successfully, but these errors were encountered: