Bug 212303 - [IntersectionObserver] Wrong isIntersecting value when thresholds are involved
Summary: [IntersectionObserver] Wrong isIntersecting value when thresholds are involved
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2020-05-23 09:54 PDT by Emilio Cobos Álvarez (:emilio)
Modified: 2020-05-23 10:33 PDT (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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:


> 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.


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.