(In reply to Emilio Cobos Álvarez (:emilio) from comment #1) > I mean, the number of adjustments is not so relevant, it's how much it advances what's relevant right? I wonder if bug 1592474 allows us to just allow scroll anchor adjustments in scroll handlers... Yeah indeed. In the specific case of the infinite event bug, it's indeed 0 advances in scroll event handlers. I will figure out [DisablingHeuristic](https://searchfox.org/mozilla-central/rev/2ca95198a2a0806de358a0484d96d4354e3cbaab/layout/generic/ScrollAnchorContainer.h#147) can be applicable for scroll event handler cases. The big difference from the current DisablingHeuristic is scroll event handler cases involves user scrolling, thus [we don't reset the heuristic in UserScrolled()]https://searchfox.org/mozilla-central/rev/2ca95198a2a0806de358a0484d96d4354e3cbaab/layout/generic/ScrollAnchorContainer.cpp#313). Maybe we can have two DisablingHeuristics? > The other thing we should look into is at not generating a scroll event when scroll anchoring undoes the scrolling, that's effectively this piece of chromium work: https://github.com/w3c/csswg-drafts/issues/4239#issuecomment-575828404 > > I think that's probably a better avenue to fix this. Honestly I am not a big fan of the change, from a comment by David Bokan in one of the relevant changes; > This means a scroll that ends up where it started before a lifecycle doesn't dispatch an event. e.g: https://output.jsbin.com/rumuges. Why early out at all? > > OTOH, if the scroll interpretation really is "rendered a new scroll position" this makes sense but it might be an interop/compat issue.. I am also concerned it.
Bug 1833758 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #1) > I mean, the number of adjustments is not so relevant, it's how much it advances what's relevant right? I wonder if bug 1592474 allows us to just allow scroll anchor adjustments in scroll handlers... Yeah indeed. In the specific case of the infinite event bug, it's indeed 0 advances in scroll event handlers. I will figure out [DisablingHeuristic](https://searchfox.org/mozilla-central/rev/2ca95198a2a0806de358a0484d96d4354e3cbaab/layout/generic/ScrollAnchorContainer.h#147) can be applicable for scroll event handler cases. The big difference from the current DisablingHeuristic is scroll event handler cases involves user scrolling, thus [we don't reset the heuristic in UserScrolled()](https://searchfox.org/mozilla-central/rev/2ca95198a2a0806de358a0484d96d4354e3cbaab/layout/generic/ScrollAnchorContainer.cpp#313). Maybe we can have two DisablingHeuristics? > The other thing we should look into is at not generating a scroll event when scroll anchoring undoes the scrolling, that's effectively this piece of chromium work: https://github.com/w3c/csswg-drafts/issues/4239#issuecomment-575828404 > > I think that's probably a better avenue to fix this. Honestly I am not a big fan of the change, from a comment by David Bokan in one of the relevant changes; > This means a scroll that ends up where it started before a lifecycle doesn't dispatch an event. e.g: https://output.jsbin.com/rumuges. Why early out at all? > > OTOH, if the scroll interpretation really is "rendered a new scroll position" this makes sense but it might be an interop/compat issue.. I am also concerned it.