Created attachment 369885 [details] Test case After the rAF timing changes in bug 177484 (which are great news overall, bringing IntersectionObserver timing in-line with the spec and other browsers), an initial observation isn't fired after a call to IntersectionObserver::observe, until something else triggers rendering. It should be enough to add a call to Document::scheduleRenderingUpdate at the end of IntersectionObserver::observe (this would correspond to "Schedule an iteration of the event loop" in https://w3c.github.io/IntersectionObserver/#dom-intersectionobserver-observe).
Did we not have tests that detected this, or did we skip them?
(In reply to Simon Fraser (smfr) from comment #1) > Did we not have tests that detected this, or did we skip them? Most of our tests (or at least, most of the WPTs) use rAF to wait for observations (which triggers a rendering update), or seem to call |observe| early enough that a rendering update will be scheduled for the initial layout of the page. Speaking of skipped tests, the rAF changes seem to have fixed all of the flakiness we were seeing on the Mac Debug bots, so I'll go ahead and update those expectations.
It turns out that at least one of the reasons that no existing test caught this is that the speculative tiling timer and the tile size change timer trigger flushes (and rendering updates) even after the page is loaded and nothing is changing. So calls to IntersectionObserver::observe that happen within ~1 second of page load will work properly even though IntersectionObserver isn’t itself scheduling a rendering update.
Created attachment 369985 [details] Patch
Comment on attachment 369985 [details] Patch Clearing flags on attachment: 369985 Committed r245396: <https://trac.webkit.org/changeset/245396>
All reviewed patches have been landed. Closing bug.
<rdar://problem/50851236>