IntersectionObserver triggers too early when thresholds=[0] (?) |
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36 Steps to reproduce the problem: 1. Setup an IntersectionObserver with thresholds=[0] where the root and target aren't initially intersecting. 2. Slowly scroll (or otherwise adjust the elements' positions) such that they gradually intersect. What is the expected behavior? In this case, when the intersectionRatio is exactly 0, Chrome should not enqueue a change record. What went wrong? According to @rjgotten in https://github.com/Fyrd/caniuse/issues/2425#issuecomment-230734694 , quote: > According to spec, a change record is supposed to be enqueued when the active threshold changes. > The active threshold is computed as follows: > > * when intersection ratio is 0, the threshold is 0 > * when intersection ratio is 1, the threshold is the length of the thresholds array (i.e. one index greater than the number of thresholds) > * otherwise, the threshold is the index of the first threshold with a value greater than the intersection ratio. > > [Source: step 2.2.8 of https://wicg.github.io/IntersectionObserver/#update-intersection-observations-algo ] > > For the default { thresholds: [0] } setting, Chrome currently already enqueues a change record when the intersectionRatio is exactly 0. This makes it impossible to use a intersectionRatio > 0 condition to reliably test if an element just became visible or invisible. The case where there is an intersection consisting of a coincident edge can not be discriminated from the case where there is no intersection, since in both cases the intersection ratio will be 0. Did this work before? No Chrome version: 53.0.2783.2 Channel: stable OS Version: Flash Version: Shockwave Flash 23.0 r0 Haven't personally verified the bug; just forwarding the user report from the CanIUse issue tracker to the Chrome tracker for a proper evaluation.
,
Sep 16 2016
,
Sep 17 2016
,
Oct 5 2016
Is the following repro an example of this? Load https://bayden.com/test/intersection/viewport.html Shrink the window vertically until the password field disappears. Slowly drag the window taller pixel by pixel until the password field appears. Note that the background color does not change as expected because the Intersection Observer only fires with a ratio of "0" because the intersected rectangle is 0x173 pixels. "IntersectionObserver fired for txtPassword Dimensions: 0h by 173w Ratio: 0"
,
Oct 11 2016
This is working as intended. If you want to trigger a notification on the "smallest possible non-zero intersection area", you can use a threshold value of Number.MIN_VALUE. |
||||
►
Sign in to add a comment |
||||
Comment 1 by sheriffbot@chromium.org
, Sep 13 2016