Closed Bug 1909305 Opened 4 months ago Closed 3 months ago

Toolbar does not hide consistently when scrolling on amazon.com pages

Categories

(Fenix :: Toolbar, defect, P2)

All
Android
defect

Tracking

(firefox128 affected, firefox129 affected, firefox130 affected)

RESOLVED FIXED
Tracking Status
firefox128 --- affected
firefox129 --- affected
firefox130 --- affected

People

(Reporter: cpeterson, Unassigned)

References

Details

Attachments

(1 file)

Steps to reproduce

  1. Load the Amazon home page https://amazon.com or any Amazon product page.
  2. Scroll down the page to hide the toolbar.
  3. Scroll back up the page to open the toolbar.

Expected behavior

The toolbar should start to hide immediately as you scroll (like Chrome's toolbar).

Actual behavior

The toolbar does not immediately start to hide. Sometimes the toolbar will hide after I scroll the height of one or two screens. Sometimes the toolbar never hides.

Device information

  • Firefox version: I've tested 128, 129, and 130. I haven't tested any older versions.
  • Android device model and OS version: Moto G5 running Android 8.1 and Samsung Galaxy A32 running Android 13

Any additional information?

This problem doesn't happen on all websites. For example, the toolbar hides as expected when scrolling Wikipedia or t-mobile.com.

Severity: -- → S3
Priority: -- → P3

Roger says fixing these type of issues will be a big project. We'll need to move more dynamic toolbar logic from Fenix into Gecko/GeckoView. GeckoView should tell Fenix when to hide the toolbar, not Fenix telling GeckoView.

See Also: → 1909139
Priority: P3 → P2

@Chris do you know if this kind of issues happen without the navbar also?
Or are they more prevalent when using the navbar?

Flags: needinfo?(cpeterson)

I seem to reproduce the bug exactly the same with or without navbar.
It seems to me that there's a kind of threshold. You have to wait for some time (maybe 1 second?) before starting a new gesture that will be taken into account by the navbar, to show/hide it.

I think it's a known issue that receiving an InputResultDetail from GV could take even half of a second - the time needed to infer what the touch really did and pass that information to Fenix.
This is highly dependent on the website and might explain some of the edgecases we see with various websites - the scroll inference works okay but may bee to slow.

Testing this scenario on Amazon without the navbar there are indeed cases where the page is scrolled but the toolbar is not.
Chris, is this the issue you were seeing?

(In reply to Petru-Mugurel Lingurar [:petru] from comment #2)

@Chris do you know if this kind of issues happen without the navbar also?
Or are they more prevalent when using the navbar?

I can reproduce this problem in Fx 128 without the navbar. In fact, the problem is easier to reproduce without the navbar than with it. :)

In Fx 128 without the navbar, I can usually reproduce by simply scrolling the amazon.com homepage.

In Fx 130 with the navbar, I can usually reproduce the problem by:

  1. Scroll down the page. The navbar will hide.
  2. Use a fling down gesture to quickly scroll up the page. The navbar will open.
  3. Before the page stops scrolling, touch the page and scroll down. The navbar will stay open instead of hiding.
Flags: needinfo?(cpeterson)

Tried this apk with a proposed fix from :hiro but I see the issue is still there - opposite direction flings on Amazon still result in InputResultDetail returning unknown - while visually the page is scrolled as expected and the reported scroll distance has the expected values.

(In reply to Chris Peterson [:cpeterson] from comment #5)

(In reply to Petru-Mugurel Lingurar [:petru] from comment #2)

@Chris do you know if this kind of issues happen without the navbar also?
Or are they more prevalent when using the navbar?

I can reproduce this problem in Fx 128 without the navbar. In fact, the problem is easier to reproduce without the navbar than with it. :)

In Fx 128 without the navbar, I can usually reproduce by simply scrolling the amazon.com homepage.

In Fx 130 with the navbar, I can usually reproduce the problem by:

  1. Scroll down the page. The navbar will hide.
  2. Use a fling down gesture to quickly scroll up the page. The navbar will open.
  3. Before the page stops scrolling, touch the page and scroll down. The navbar will stay open instead of hiding.

I can't reproduce this bug with the fix bug 1912358 (which is included in the Petru's apk) with this STR.

Is there any other ways to trigger this bug? I am testing on Android Emulator 7.0 so things might be different from you guys' environments.

Seems like this has been solved by bug 1912358 🚀.
Both me and Aarjav can reproduce the bug on amazon's homepage with latest beta (130) but cannot reproduce with latest Nightly.
Chris, as the reporter can you also try on the latest Nightly to see if this seem fixed for you also?

Flags: needinfo?(cpeterson)

Yes, this issue seems to be fixed for me in Nightly, too. I resolve this bug as fixed by bug 1912358.

Status: NEW → RESOLVED
Closed: 3 months ago
Depends on: 1912358
Flags: needinfo?(cpeterson)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: