Closed Bug 1400971 Opened 4 years ago Closed 1 year ago
Intersection Observer does not send an initial notification after .observe() is called by late-executing scripts
369 bytes, text/html
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36 Steps to reproduce: 1. Create a simple web page with an element and script that executes some time after page load (e.g. via setTimeout, async script load). 2. In the late-executing script, create an intersection observer and call observe on the element. 3. Open the page in Firefox 55 (Windows or Linux, OSX has the expected behavior). 4. Do not interact with the page after opening (e.g. no mouse movement, typing, etc). Actual results: Intersection Observer's callback is not called until some interaction with the page occurs, regardless of whether the element is within the viewport. Expected results: Intersection Observer's callback should be called in a timely manner, regardless of interaction with the page.
Moving to core::DOM as it seems to be a better component.
Component: Untriaged → DOM
Product: Firefox → Core
Assignee: nobody → tschneider
This seam to happen on MacOS too for me. Investigating....
No longer blocks: intersection-observer
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: P2 → --
Not able to reproduce anymore in FF 58.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Maire, do you know who's covering Intersection Observer bugs these days? I *think* I can still reproduce it.
Assignee: tschneider → nobody
Hi Andrew -- I haven't needed to touch Intersection Observer yet (as a dev or as a manager). If you need my help tracking down the right owner, just needinfo me back. Thanks.
Maybe Sean knows who on the layout team can take a look?
So why is this even a valid bug? If anything hasn't changed in the page, per HTML spec https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model the document maybe removed from docs in 'Update the rendering' and then observer isn't called. Does Chrome do extra paints?
I think smaug is right here. That said, Hiro might be best contact on layout side to confirm. Hiro - Any thoughts here? I saw you did some work last on this in `nsRefreshDriver::UpdateIntersectionObservations`. Is this our intended behavior?
Flags: needinfo?(svoisen) → needinfo?(hikezoe)
I agree with Olli. Chrome triggers the callback for some reasons. In the test case in comment 0, the observed entry's timestamp is around 1014 on my environment (chromium 68.0.3440.75 on Linux), that means that the entry happened after the callback for setTimeout(1000). calhounsm, would you mind checking whether chrome behavior is correct or not? What I am still concerned is that Tobias who implemented Intersection Observer in Firefox seemed to think this is a valid bug (as per comment 2). So there may be some other test cases without setTimeout calls. (Even with setTimeout calls, it depends on paint timing whether some entries are observed or not, I believe)
Flags: needinfo?(hikezoe) → needinfo?(calhounsm)
Degrading priority for now, I think this is not a valid bug.
Priority: P2 → P3
Component: DOM → DOM: Core & HTML
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.