1807075 - Pull to refresh doesn't work on rakuten.com

Status: RESOLVED WORKSFORME

(Fenix :: General, defect)

Description

[Christian Sadilek [:csadilek]]

From github: https://github.com/mozilla-mobile/fenix/issues/16092.

Steps to reproduce

1. Navigate to rakuten.com
2. Use the pull to refresh gesture

Expected behavior

Pull to refresh works properly.

Actual behavior

Doesn't work

Device information

• Android device:
  • Google Pixel 3a (Android 11)
  • OnePlus A3 (Android 6.0.1)

• Fenix version: Nightly 201021

Notes

✔️ Works on Chrome
Related to #16054 and #9766

► Video

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Hiroyuki Ikezoe (:hiro)]

I can't reproduce the issue on my Pixel 6a. That's said the site I am seeing is slightly different from in the video in the original report. I don't see the CAPTCHA field on my end at all.

Christian are you able to reproduce the issue?

Comment 3

[Christian Sadilek [:csadilek]]

I can not reproduce this either, but looks like QA reproduced fairly recently last November.

Just for context: We're moving all open Fenix tickets to Bugzilla so it's possible you will see outdated tickets. Thank you for the ping, let's ask QA for help here.

Comment 4

[Lorand Janos]

I can still reproduce this issue on some devices with the latest Nightly 110.0a1 (2023-01-13) build.
Reproduced on:

• Oppo Find X5 (Android 12).
• Google Pixel 4 (Android 13).

Not reproducible on Samsung Galaxy Tab S3 (Android 9).
Couldn't reproduce this issue on Chrome with all devices above.

Comment 5

[Botond Ballo [:botond]]

While pull-to-refresh seems to work fine for me when I'm at the top of the page, I see another issue that's somewhat pull-to-refresh related:

When scrolled down on the page, if I try to scroll up with gestures such that I wait for the page to stop moving after one gesture before starting the next, then the results alternate between (1) successfully scrolling upward and (2) not scrolling. In the "not scrolling" case, I see a few pixels of the pull-to-refresh icon appear (even though I'm not at the top of the page) and then get stuck there until the next gesture.

Comment 6

[Botond Ballo [:botond]]

What seems to be happening in the "not scrolling" cases is that immediately after the touch-start, APZ gets a touch-cancel event from GeckoView.

cc Petru, perhaps you have some ideas about why that might be happening

Comment 7

[Petru-Mugurel Lingurar [:petru]]

I see a few pixels of the pull-to-refresh icon appear (even though I'm not at the top of the page) and then get stuck there until the next gesture

That sounds like an issue of the current implementation which I think has been discussed in the past but I cannot find it in a quick search.
The scenario which I think you're seeing:

• We are relying on Android's functionality for the pull to refresh throbber (through SwipeRefreshLayout).
• That SwipeRefreshLayout needs the complete stream of touch events - starting with ACTION_DOWN etc to function and it will act on them immediately.
• After SwipeRefreshLayout starts animating the throbber we get from GV through inputResultDetail that the gesture should not happen [1][2] and the functionality is cancelled. But it may happen that the throbber started showing already.

Hopefully this doesn't happen often and only a very small part of the throbber may linger a bit more on the screen as it doesn't seem easy to fix.
Still think the easiest (for us) would be to have GV inform us about the overscroll distance.

[1] https://searchfox.org/mozilla-mobile/rev/7c70c3df303e19acc69877821c3770fe85393005/firefox-android/android-components/components/feature/session/src/main/java/mozilla/components/feature/session/SwipeRefreshFeature.kt#78
[2] https://searchfox.org/mozilla-mobile/rev/7c70c3df303e19acc69877821c3770fe85393005/firefox-android/android-components/components/concept/engine/src/main/java/mozilla/components/concept/engine/InputResultDetail.kt#258-261

Comment 8

[Botond Ballo [:botond]]

Thanks, Petru, that makes sense as an explanation for the throbber's behaviour.

I don't think the issue of showing a few pixels of the throbber itself is very noticeable. The more noticeable issue is the fact that when scrolling upwards, every second gesture is cancelled by a touch-cancel event, which looks like it corresponds to MotionEvent.ACTION_CANCEL or MotionEvent.ACTION_OUTSIDE.

Do you have an idea of where those events are coming from? Are they also related to the throbber?

Comment 9

[Botond Ballo [:botond]]

Update: I realized the touch-cancel events are related to an Android OS accessibility feature ("tap to magnify") that I enabled while investigating another bug.

With that feature disabled, I can't reproduce any pull-to-refresh related misbehaviour on the site either.

Comment 10

[miralobontiu]

I was not able to reproduce this issue anymore on Fenix Nightly 124.0a1 from 1/31, and 2/1.
Tested with the following devices:

• Google Pixel 6 (Android 14),
• Lenovo tablet M10 (Android 10), and
• Samsung Galaxy A14 (Android 13).

I'll close this ticket as Worksforme.