Panning down the map in babyintow.ca reloads the page
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
People
(Reporter: smaug, Unassigned)
Details
I was testing the performance of babyintow.ca and noticed that it is very easy accidentally reload the site by panning down.
Comment 1•5 years ago
|
||
I think pull to refresh is the problem here.
Comment 2•5 years ago
|
||
cc Hiro who has worked on the pull-to-refresh implementation on mobile
Comment 3•5 years ago
|
||
I don't see the pull-to-refresh is triggered on the site (I am assuming on maps in the site) on my Pixel 3, instead I saw a couple of times that the pull-to-refresh icon is appearing but gets stuck in the middle of the state (stuck at 1/3 of the icon appeared). pull-to-refresh is basically triggered as a result of where APZ didn't consume the swipe down gesture, but if the content listens touch-start events, things are a bit complicated, we have a timeout value to get response from the content's listeners, I don't recall exactly how we handle the case where the content didn't response within the timeout, but I guess Olli's device is much slower than Pixel3 then it often gets into the timeout situation? Then APZ wrongly report it to GeckoView?
| Reporter | ||
Comment 4•5 years ago
|
||
I was using Sony 10 II / Android 11 for testing. It should be a mid-range phone.
Updated•4 years ago
|
Comment 5•4 years ago
|
||
I see the same behaviour as Hiro (pull-to-refresh icon sometimes appears but stops before actually reloading the page).
Going to mark this as S3 for now as an issue that's we haven't received many bug reports about.
I think the possible actionable tasks here are:
- Consider increasing the time limit we give to the page to handle touch events before activating pull-to-refresh. As always, this is a tradeoff, as it makes pull-to-refresh less responsive.
- Investigate the performance of the JS on this page specifically to see why it sometimes fails to handle touch events within the existing time limit.
Description
•