212303 2020-05-23 09:54:11 -0700 [IntersectionObserver] Wrong isIntersecting value when thresholds are involved 2020-05-23 10:33:34 -0700 1 1 1 Unclassified WebKit DOM WebKit Nightly Build Unspecified Unspecified RESOLVED MOVED P2 Normal --- 1 emilio webkit-unassigned koivisto rwlbuis oldest_to_newest 1655623 0 emilio 2020-05-23 09:54:11 -0700 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. 1655629 1 emilio 2020-05-23 10:14:42 -0700 So I dug a bit more and filed https://github.com/w3c/IntersectionObserver/issues/432. TLDR, no browser matches the spec, yay? 1655630 2 emilio 2020-05-23 10:33:34 -0700 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.