Bug 212303

Summary: [IntersectionObserver] Wrong isIntersecting value when thresholds are involved
Product: WebKit Reporter: Emilio Cobos Álvarez (:emilio) <emilio>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED MOVED    
Severity: Normal CC: koivisto, rwlbuis
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   

Description Emilio Cobos Álvarez (:emilio) 2020-05-23 09:54:11 PDT
What steps will reproduce the problem?
1. Open https://bugzilla.mozilla.org/attachment.cgi?id=9151272. Note that the expectation of that test-case is wrong.
2. Scroll down until the element is fully in view. Yo should see "true, 1.0" in the console.
3. Scroll back up until the element is no longer fully in view. You should see "true, <some number less than one>", but you get "false, <some number less than one>" instead.

Per the spec, isIntersecting in that second notification should be true:

https://w3c.github.io/IntersectionObserver/#update-intersection-observations-algo:

> Let isIntersecting be true if targetRect and rootBounds intersect or are edge-adjacent, even if the intersection has zero area (because rootBounds or targetRect have zero area); otherwise, let isIntersecting be false.

Chromium and WebKit seem to use `isIntersecting = thresholdIndex > 0` or something of that sort.

https://webkit-search.igalia.com/webkit/rev/21a8aa0218f444efd453ffc7db766387d09b4200/Source/WebCore/dom/Document.cpp#7736

I think Firefox is right per spec on this one unless I'm missing something.

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1085938 for Chrome.
Comment 1 Emilio Cobos Álvarez (:emilio) 2020-05-23 10:14:42 PDT
So I dug a bit more and filed https://github.com/w3c/IntersectionObserver/issues/432. TLDR, no browser matches the spec, yay?
Comment 2 Emilio Cobos Álvarez (:emilio) 2020-05-23 10:33:34 PDT
I'm changing Firefox to match Chrome and WebKit here, though it's a bit sad of a feeling, because we all ended up implementing whatever was tested / implemented by chrome rather than the spec. Oh well.

Let's track this as a spec bug in https://github.com/w3c/IntersectionObserver/issues/432.