Bugzilla

Thanks for the analysis, Petru! I agree that there are underlying issues here on the APZ side.

The reason for the `INPUT_RESULT_IGNORED` when panning upward during an existing downward fling is [this logic](https://searchfox.org/mozilla-central/rev/00ea1649b59d5f427979e2d6ba42be96f62d6e82/gfx/layers/apz/src/InputQueue.cpp#180-183) which causes the APZ status to be set to `eConsumeNoDefault`, which is then translated to `INPUT_RESULT_IGNORED` [here](https://searchfox.org/mozilla-central/rev/00ea1649b59d5f427979e2d6ba42be96f62d6e82/widget/android/nsWindow.cpp#874-881).

The motivation behind this code is that if the browser is currently flinging at a speed above a threshold, a touch in that state should not be delivered to page content because the intent of the touch is likely to be to interrupt the fling rather than to interact with whatever content happens to be under the finger. I think we want to keep the "touch event is not delivered to page content" part of the behaviour, but the "touch event cannot acitvate pull-to-refresh" part is an unintended side effect which we should disentangle.

I haven't evaluated the second scenario very deeply; if the first issue is fixed, this state ("page is scrolled to the top and toolbar is hidden") may not arise in the first place.

Thanks for the analysis, Petru! I agree that there are underlying issues here on the APZ side.

The reason for the `INPUT_RESULT_IGNORED` when panning upward during an existing downward fling is [this logic](https://searchfox.org/mozilla-central/rev/00ea1649b59d5f427979e2d6ba42be96f62d6e82/gfx/layers/apz/src/InputQueue.cpp#180-183) which causes the APZ status to be set to `eConsumeNoDefault`, which is then translated to `INPUT_RESULT_IGNORED` [here](https://searchfox.org/mozilla-central/rev/00ea1649b59d5f427979e2d6ba42be96f62d6e82/widget/android/nsWindow.cpp#874-881).

The motivation behind this code is that if the browser is currently flinging at a speed above a threshold, a touch in that state should not be delivered to page content because the intent of the touch is likely to be to interrupt the fling rather than to interact with whatever content happens to be under the finger. I think we want to keep the "touch event is not delivered to page content" part of the behaviour, but the "touch event cannot trigger dynamic toolbar movement" part is an unintended side effect which we should disentangle.

I haven't evaluated the second scenario very deeply; if the first issue is fixed, this state ("page is scrolled to the top and toolbar is hidden") may not arise in the first place.