Fenix: [Feature request] Add preference to enable/disable toolbar autohide

[yoasif]

As seen on: https://www.reddit.com/r/firefox/comments/f9yrtg/help_firefox_preview_nightly_for_developers_early/

Why/User Benefit/User Problem

As a user, I would like to configure whether I always see the toolbar when scrolling pages.

What/Requirements

Add a preference to enable or disable toolbar autohide.

Acceptance Criteria (how do I know when I’m done?)

I can disable or enable toolbar autohide.

This feature previously existed in Fennec as "Full screen browsing" - Hide the Firefox toolbar when scrolling down a page.

[reukiodo]

even an about:config item would make this more bearable

try to use an online editing tool like http://remove.bg/ while this bar hides an unhides with each finger movement

[cyatarow]

By the way, "browser.chrome.dynamictoolbar" in about:config is not working.

[kbrosnan]

about:config is not a good fit here. This is UI and should be handled completely in the Kotlin Fenix or Android Components code rather than the GeckoView and about:config.

[DetlevCM]

One more disadvantage of the auto-hiding toolbar: It interferes with website usage.
I was thinking that google turned the YouTube interface into a mess, but it turns out that the non-responsiveness of the Comments-button is due to the toolbar. So one scrolls down, then has to scroll up and down again to be able to click on a bottom element...

Please imagine a little explosive rant here about this "feature" ... (Why was it introduced as a non-optional feature anyway?)

[lukestateson]

Is it possible to add this at least in about:config?

[cadeyrn]

Is it possible to add this at least in about:config?

Two comments above yours:

about:config is not a good fit here. This is UI and should be handled completely in the Kotlin Fenix or Android Components code rather than the GeckoView and about:config.

[cartr]

A few other reasons to support this, and maybe even make "don't autohide" the default:

• Auto-hiding URL bars present a phishing risk, since websites can draw their own fake UI in the same location: https://jameshfisher.com/2019/04/27/the-inception-bar-a-new-phishing-method/ . (This example's "stop the browser from catching the drag event" code doesn't seem to work in Fenix, but it's easy to imagine scenarios where e.g. the user scrolls down on one page, then a malicious phishing ad draws fake UI to make it look like the user's navigated to a new page where they can't scroll.)
• Mobile phone screens are taller than they used to be, and they often have rounded corners that websites aren't designed to avoid
• In the default toolbar-on-the-bottom configuration, autohiding the toolbar when you scroll down doesn't make much physical sense. The user's finger is dragging the content upward, but the toolbar is moving downward.

[hiikezoe]

One thing I should call out here (as well) is that 100vh is not equal to 100% height on the root element if the toolbar is dynamic. I.e. they are basically different on Chrome, Safari and Firefox. If the toolbar is static, both values are the same.

So, I am concerned that making the toolbar static might force web developers to do extra work, (thus it might lead us to decline our share).

Please don't get me wrong, I am not saying I am objecting against adding the preference.

Also note that there is an on-going discussion to add a CSS units to as contrast with vh units, and the CSSWG has decided to add it, see https://github.com/w3c/csswg-drafts/issues/4329.

[yoasif]

Seeing this on play store reviews:

where's the option to lock the address bar?

[s-ankur]

Duplicate of #8847?

[cadeyrn]

Since there is already a discussion and mockups it should be "forward duped" to #10240 (and #8847 as well).

[DetlevCM]

@s-ankur Based on the date of the first post, this thread was started first on the 27th of February. #8847 was started on the 28th of February, so it would seem that #8847 is the duplicate.

[cadeyrn]

See previous comment: Both should be duped to #10240 even if it was created later because there is already work ongoing.

[s-ankur]

@DetlevCM im saying these are both duplicates of each other. It is up to the devs which one to close.

Edit: I agree with @cadeyrn

[clientenq]

One thing I should call out here (as well) is that 100vh is not equal to 100% height on the root element if the toolbar is dynamic. I.e. they are basically different on Chrome, Safari and Firefox. If the toolbar is static, both values are the same.

So, I am concerned that making the toolbar static might force web developers to do extra work, (thus it might lead us to decline our share).

I don't see why all web developers have to do extra coding when browser developers can provide a solution. The w3c defines web developers can follow initial settings. Thus the browser has to adjust when the browser redefines those settings by adjusting a browser element such as toolbar. And since we already started following that adjusting path by choosing to implement auto hide toolbar there is no reason to not re implement this much wanted feature while also preventing all web developers to do extra coding.

[hwinnemoe]

This has been implemented by #10240.

[DrLightman]

Please add such option or rather disable autohide completely, since this feature offers more trouble than benefits. I thought that it would be evident after a couple of weeks after the release and a following update would have cancelled that but it's still there. I mitigated the issue by moving the toolbar to the bottom, for that an option was added at least.

But please, add an option to disable autohide or keep it always shown.

[cadeyrn]

@DrLightman Please see the previous comment, it is already implemented. You can already test the new option in Firefox Beta.

[hwinnemoe]

@yoasif I think you can close this issue, unless you want to wait for the feature to land in release/production.