Bugzilla

Adding one detail: it's important for the touchmove/touchstart listener to be `passive: false` to trigger the bug.

I did rule out issues on the APZ side. (The `passive: false` event listener means that APZ provides the `InputResult` to GeckoView using the "delayed result" codepath rather than the "eager result" codepath, but the provided value is correct.)

The mechanism of failure is that for the scroll gestures that have no effect, APZ receives a touch-cancel event from GeckoView which cancels the gesture. (This is the same thing I observed in bug 1807075 comment 6, though in that case the touch-cancel events were related to Android's "tap to magnify" feature; that's not the case here, the issue occurs with "tap to magnify" disabled as well.)

An example of a production website affected by this bug is https://diverace.com/. This is likely to affect a variety of sites because the condition for triggering the bug (having a `passive: false` event listener) is a common pattern.

Adding one detail: it's important for the touchmove/touchstart listener to be `passive: false` to trigger the bug.

I did rule out issues on the APZ side. (The `passive: false` event listener means that APZ provides the `InputResult` to GeckoView using the "delayed result" codepath rather than the "eager result" codepath, but the provided value is correct.)

The mechanism of failure is that for the scroll gestures that have no effect, APZ receives a touch-cancel event from GeckoView which cancels the gesture. (This is the same thing I observed in bug 1807075 comment 6, though in that case the touch-cancel events were related to Android's "tap to magnify" feature; that's not the case here, the issue occurs with "tap to magnify" disabled as well.)

An example of a production website affected by this bug is https://diverace.com/. This is likely to affect a variety of sites because the condition for triggering the bug (having a `passive: false` touchstart/touchmove event listener) is a common pattern.