1830805 - Swiping to scroll up is often ineffective at https://io.google , in Firefox on Android with pull-to-refresh enabled

Status: RESOLVED FIXED

(Firefox for Android :: General, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Visit https://io.google/2023/program/ in Firefox on Android.
2. (optional) Click "OK, got it" on the cookie prompt. (Or you can leave it in place and proceed with the next step.)
3. Swipe to scroll down the page.
4. Swipe to scroll back up the page (i.e. touch your screen and drag your finger towards the bottom). Wait about 0.5s - 1s and do it again.

ACTUAL RESULTS:
Roughly half of my swipes seem to have no effect -- often one will work, the next has no effect, the next will work, the next has no effect, etc. This specifically seems to affect swipes where you're attempting to scroll upwards on the page (the ones in step 4)

EXPECTED RESULTS:
Swipes should scroll the page.

Screencast coming shortly. I'm using a Pixel 6a with Firefox Nightly 114. I can also reproduce in Firefox release 112.2

I think this is associated with "pull-to-refresh" detection -- if I disable Pull to Refresh in Firefox Settings, then I can't reproduce.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast

Comment 2

[Daniel Holbert [:dholbert]]

botond, I wonder if you know what's going on here? I see you've done some recent work in this area (pull-to-refresh) in e.g. bug 1785754.

I should note, I'm unable to reproduce the bug in Chrome on the same device (though pull-to-refresh does work for this site in Chrome, if I scroll to the very top and then try to swipe to scroll further than that).

Comment 3

[Hiroyuki Ikezoe (:hiro)]

This is probably caused by the same underlying issue of bug 1724755. There's a touchstart event listener (there's also a wheel event listener which is probably relevant with this issue), so Fenix's pull-to-refresh machinery needs to wait for a response from the event listener, but doesn't. I confirmed a naive workaround in bug 1724755 comment 10 fixes this issue.

Comment 4

[Botond Ballo [:botond]]

Thank you Hiro for investigating. I did additionally confirm that APZ is providing the correct InputResult value to the application for each touch, including the ones that don't end up scrolling.

I'm going to move this to the same component as bug 1724755.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

No longer reproducible. I believe this was also fixed by bug 1847305.