1894316 - Consider hiding Android's system status bar when the user scrolls a web page and Fenix hides its address bar. (full screen mode)

Status: ASSIGNED

(Firefox for Android :: Toolbar, enhancement, P3)

Description

[Chris Peterson [:cpeterson]]

Users on Mozilla Connect have requested a "tablet full screen mode":

https://connect.mozilla.org/t5/ideas/full-screen-mode-in-android/idi-p/18197

Instead of adding a new full screen button or setting, maybe we could just hide the system status bar when the user scrolls the page, like we do for Firefox's own address bar. In fact, Safari on iPhone (but not iPad) and Samsung's browser ("Internet") on some Android devices (my Samsung Galaxy A32, but not my Moto G5) do exactly that, but only in landscape orientation.

There is a risk that malicious web pages might mimic the system status bar without needing to trick the user into clicking Firefox's full screen prompt.

We would need to make sure that users could escape the "system status bar is hidden" mode if a web page prevents the user from scrolling (maliciously or otherwise). That might be way Safari and Samsung Internet only hide the system status bar in landscape orientation.

Comment 1

[nathan95]

Another user reported this feedback de on the Play Store would be useful to have a feature like this in fact.

See: https://app.conversocial.com/queues/hold/66fadea0c02c3393031fdeae

Comment 2

[Christopher Ottesen]

I've written a patch implementing the approach from comment 0: when the dynamic toolbar is scrolled fully out of view, the Android status bar is hidden too, and it comes back once the toolbar is revealed at least halfway. A swipe from the top edge shows it transiently (BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE), so a page that blocks scrolling can't trap the user. Web fullscreen keeps its existing immersive handling, Custom Tabs are unaffected, and users with TalkBack/Switch Access keep the fixed toolbar, so it never triggers for them.

For now it's behind a secret setting, off by default. The goal is a user-facing option (see bug 1808751 and its duplicates), and I'm happy to follow UX guidance on how to expose it.

Motivation: on devices with a small screen and a large camera cutout this matters a lot. On the Unihertz Titan 2 Elite (a small 4-inch, square 1076x1200 screen) the status bar is about 10% of the screen height. Attached is a recording from that device.

Comment 3

[Christopher Ottesen]

Attachment: Screen recording on Unihertz Titan 2 Elite (debug build with the patch)

Comment 4

[Christopher Ottesen]

Attachment: Bug 1894316 - Hide the status bar together with the dynamic toolbar. r?#android-reviewers

When the dynamic toolbars are scrolled fully out of view, also hide the
status bar, and show it again once they are revealed at least halfway.
A swipe from the top edge shows it transiently, so a page blocking
scrolling cannot trap the user. Behind a secret setting, off by default,
until it is decided how to expose it (see bug 1808751).

The top display cutout is no longer padded while the status bar is
hidden, otherwise no space is gained on most devices. Toolbar gestures
are measured in screen coordinates, because the layout moving when the
status bar hides was mistaken for a scroll and made it flicker.

Comment 5

[Christopher Ottesen]

Attachment: Bug 1894316 - Measure dynamic toolbar gestures in screen coordinates. r?#android-reviewers

Gestures were measured relative to the CoordinatorLayout, so when the
layout moved on screen during a gesture, a finger that had not moved was
read as a scroll. Hiding the status bar while the toolbar collapses moves
the layout this way and made the toolbar bounce back.

Comment 6

[Christopher Ottesen]

Attachment: Bug 1894316 - Do not pad below a top display cutout while the status bar is hidden. r?#android-reviewers

On most devices the status bar is as tall as the top cutout, so keeping
the cutout padding would leave the space freed by a hidden status bar
empty.

This does not change existing behavior: the only other case hiding the
status bar is immersive mode, where FLAG_LAYOUT_NO_LIMITS already
removes all of the padding.

Comment 7

[Christopher Ottesen]

Attachment: Bug 1894316 - Notify when the dynamic toolbars are collapsed or expanded. r?#android-reviewers

EngineViewClippingBehavior already knows when all toolbars are fully
hidden. The state only switches back to expanded once the toolbars are
revealed at least halfway, so slow scrolls around the hidden position do
not keep toggling it.

Comment 8

[Petru-Mugurel Lingurar [:petru]]

Attachment: Wanted: smooth hiding of the status bar shown here in Samsung Browser

Thank you for looking at this @chriotte!
Seems like what's requested here is something similar to the UX of Samsung Browser - a smooth animation of the top toolbar & status bar to the outside of the screen together with the content (attached).
This does align with our long term plans and we are actively working on supporting this and more.

Unfortunately the currently proposed approach has 2 important issues stemming from now resizing the engine view:

• this causes reflowing the entire web content and changes to the *vh values which is not permitted according to csswg.
• the web content behind the finger changes

Seems like Samsung Browser can smoothly move the system status bar only on Samsung devices and only because they have access there to privileged OS level APIs.

I am currently working on refactoring how all bars behave while browsing and could take this request in also as it seems to require deeper work/support.

Comment 9

[Christopher Ottesen]

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

Created attachment 9657608 [details]
Wanted: smooth hiding of the status bar shown here in Samsung Browser

Thank you for looking at this @chriotte!
Seems like what's requested here is something similar to the UX of Samsung Browser - a smooth animation of the top toolbar & status bar to the outside of the screen together with the content (attached).
This does align with our long term plans and we are actively working on supporting this and more.

Unfortunately the currently proposed approach has 2 important issues stemming from now resizing the engine view:

• this causes reflowing the entire web content and changes to the *vh values which is not permitted according to csswg.
• the web content behind the finger changes

Seems like Samsung Browser can smoothly move the system status bar only on Samsung devices and only because they have access there to privileged OS level APIs.

I am currently working on refactoring how all bars behave while browsing and could take this request in also as it seems to require deeper work/support.

Hi Petru! Thank you very much for reviewing the code and giving feedback!
I agree with you, it would be much smoother to implement it the same way Samsung handles the UX.

I have been using my dev build for a few days, and I've noticed the page jumping when the status bar comes back while scrolling up, so it would need more work on my side. Very happy for you to take over this, and I will close my patches.

Comment 10

[Petru-Mugurel Lingurar [:petru]]

(In reply to Christopher Ottesen from comment #9)

Hi Petru! Thank you very much for reviewing the code and giving feedback!
I agree with you, it would be much smoother to implement it the same way Samsung handles the UX.

I have been using my dev build for a few days, and I've noticed the page jumping when the status bar comes back while scrolling up, so it would need more work on my side. Very happy for you to take over this, and I will close my patches.

Thank you for looking into this and the understanding!
Will mark this ticket as depending on the new meta we're building to refactor our support for all bars framing the web content - bug 2082522.