IntersectionObserver w/ rootMargin within iframe is inconsistent with spec
Reported by
luis.mer...@researchgate.net,
May 16 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36 Steps to reproduce the problem: a) Outside iframe (working case): 1. Open the file IntersectionObserverRootMarginBug.html in the browser. 2. Scroll down at least 60px, so that the rootMargin bottom value of -60px applies to consider the box intersecting with the root. 3. Change the JS const ROOT_MARGIN's value in the source HTML from '0px 0px -60px' to '0px 0px 60px' 4. Reload to see the changes, and observe how the box is now considered intersecting (provided the viewport's scrollTop is 0) a) Inside iframe (failing case): 1. Open the file IntersectionObserverRootMarginBug_iframe.html in the browser. 2. Scroll down at least 60px, so that the rootMargin bottom value of -60px applies to consider the box intersecting with the root. 3. Change the JS const ROOT_MARGIN's value in the source HTML from '0px 0px -60px' to '0px 0px 60px' 4. Reload to see the changes, and observe how the box is NOT considered intersecting (provided the viewport's scrollTop is 0) What is the expected behavior? b) According to the expect, the case inside the iframe should NOT apply negative rootMargins on the calculation of "IntersectionObserverEntry.isIntersecting". What went wrong? b) Inside iframe: Behavior does NOT match the spec -> https://w3c.github.io/IntersectionObserver/#dom-intersectionobserver-rootmargin Did this work before? N/A Does this work in other browsers? No - Latest stable Firefox exhibits the same behavior. - Edge 16 does not, rootMargin applies in and outside iframes. - With polyfill (using Safari in my case): https://github.com/w3c/IntersectionObserver behaves as Edge 16, working in and outside iframes. Chrome version: 66.0.3359.139 Channel: stable OS Version: OS X 10.13.4 Flash Version: Even though the spec says that rootMargin shouldn't work within iframes, Edge and the polyfill skip this requirement. Ideally I would like to have isIntersecting/intersectionRatio feedback on the first event, even within iframes. That way one could always use rootMargin=-1px 0px to avoid accounting for edge-adjacent intersections on cases where elements have height: 100vh on initial load. At the very least, browsers should agree on the spec. implementation to avoid false positives. Related issues and cases: - https://github.com/w3c/IntersectionObserver/issues/283#issuecomment-389153942 - https://github.com/researchgate/react-intersection-observer/issues/32
,
May 16 2018
,
May 17 2018
Tested the issue on chrome reported version 66.0.3359.139 using Mac 10.13.1 with steps mentioned below: 1) Launched chrome reported version, dragged and dropped the '.html' files provided in comment#0 and observations are as follows => For IntersectionObserverRootMarginBug.html file: a) Placed the IntersectionObserverRootMarginBug.html in the browser and scrolled the page to bottom b) Opened Devtools > Elements and changed const ROOT_MARGIN's value in the source HTML from '0px 0px -60px' to '0px 0px 60px' c) Reloaded the page, didn't observed any change in the behaviour on the page => For IntersectionObserverRootMarginBug_iframe.html file: a) Placed the IntersectionObserverRootMarginBug.html in the browser and scrolled the page to bottom b) Opened Devtools > Elements and changed const ROOT_MARGIN's value in the source HTML from '0px 0px -60px' to '0px 0px 60px' c) Reloaded the page, page got jumped to the top of the page @Reporter: Please find the attached screencast for your reference and provide your feedback on it which help in further triaging it, as mentioned in 'Excepted behaviour' in comment#0, we are not sure about the excepted behaviour of the issue, if possible could you please provide screencast of the issue which help in better understanding. Thanks!
,
May 17 2018
Given IntersectionObserverRootMarginBug.html in the video, when you change the value in DevTools from -60px to 60px and refresh the page it goes back to -60px... Is it saved? The behavior doesn't change for you. Use a code editor to modify it and then reload (make sure the scroll position is zero before you reload, so that is not anchored). This is just to prove how rootMargin should work on this example case. Now, to the problem in question; on the second file IntersectionObserverRootMarginBug_iframe.html, the negative rootMargin with -60px initially DOES intersect when you scroll the iframe's body 60px, and it SHOULD NOT be intersecting according to the spec. When you change the value to 60px and reload, the iframe does NOT intersect automatically. So why is (within the iframe) a positive value (60px) following the spec and thus ignoring rootMargin, while a negative one does not? Assuming the iframe's "viewport" is window.self (kind of) because of root=null, it shouldn't be obeying rootMargin as if the parent's viewport was its root. I hope that helps, let me know if you've got further questions. Cheers!
,
May 17 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 17 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by erikc...@chromium.org
, May 16 2018