1921339 - Make 100lvh pages scrollable and don't hide the dynamic toolbars on them, specifically when the toolbar is on the bottom

Status: NEW

(Core :: Panning and Zooming, task, P2)

Description

[Markus Stange [:mstange]]

This bug is tracking a rework of how Firefox should behave when the dynamic toolbar is on the bottom.
The proposed behavior would be more closely aligned with Safari on iOS, which also has a bottom toolbar. (Chrome on Android does not have a bottom toolbar.)

Today, in Firefox on Android when the toolbar is on the bottom, the only way to see the bottom of a website is to do a "scroll-down" touch gesture which hides the bottom toolbar. As long as the bottom toolbar is visible, the bottom of the website is always covered by it. To see what's at the bottom of the page, the bottom toolbar must be hidden.

This has the following disadvantages:

• The hiding of the bottom toolbar is not always in sync with the page scrolling on the screen: On pages with certain heights, the swipe gesture can hide the bottom toolbar without moving the page. See attachment 9424305 [details] for an example. This behavior feels rather strange: you're scrolling but you're not really scrolling.
• During text input, the bottom toolbar can sometimes hide the field that you're typing into, and Gecko cannot scroll the field into view while the toolbar is visible.

Specifically, the current situation means that we cannot fix bug 1914119 properly in the case where the toolbar is on the bottom: If we only hide the bottom toolbar in response to the page moving on the screen, and if we cannot scroll pages with certain heights (we can only "uncover" them), then the approach in bug 1914119 would mean that you would not be able "uncover" these pages. If they don't move, then the toolbar does not hide. And the bottom part of such pages would be inaccessible.

---

Safari on iOS has a better approach for these cases: When the dynamic toolbar is visible, pages can always be scrolled far enough so that their bottom end can move past the top edge of the bottom toolbar.
I think we should adopt Safari's approach.

When a page is scrolled all the way to the bottom, and the bottom toolbar is visible, this means that we need to allow a "gap" between the bottom of the page and the bottom of the GeckoView. But that's fine - this gap is covered by the toolbar.

Of course, as you scroll down, the bottom toolbar usually moves away. So there is a danger that the "gap" would be revealed as the bottom toolbar moves away. Safari avoids this case by keeping the bottom toolbar visible whenever there would be a danger of revealing that gap.
More specifically: Let H be the height of the bottom toolbar, and let the bottom toolbar be fully visible. At the start of each scroll gesture, we can determine whether we want case A or case B to happen. Case A is: hide the bottom toolbar during scrolling, and don't allow scrolling past the end of the screen. Case B is: Don't hide the toolbar during scrolling, and do allow scrolling past the end of the screen, far enough to create the H-sized "gap" between the bottom of the page and the bottom of the screen. This is fine because the bottom toolbar remains visible and covers that gap. And then the rule is: At the start of each scroll gesture, if the bottom of the page extends at least H pixels past the bottom of the screen, do case A, otherwise do case B.

Comment 2

[Markus Stange [:mstange]]

Bug 1921331 needs a similar mechanism for a "gap" at the top.