Closed Bug 740148 Opened 12 years ago Closed 3 years ago

Allow hiding toolbars for presentations

Categories

(Firefox :: Toolbars and Customization, defect)

Product:
Firefox
Component:
Toolbars and Customization
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal
Points:
1

Tracking

()

Status:
RESOLVED FIXED
Milestone:
89 Branch
Iteration:
89.1 - Mar 22 - Apr 4
Tracking Flags:
Tracking Status
firefox-esr78 --- wontfix
firefox57 - wontfix
firefox87 --- wontfix
firefox88 --- wontfix
firefox89 --- fixed

People

(Reporter: rik, Assigned: bugzilla)

References

(Depends on 2 open bugs, Blocks 3 open bugs)

Details

(Keywords: regression, Whiteboard: [mac:fullscreen])

Attachments

(5 files)

Obey browser.fullscreen.autohide in Lion fullscreen mode (for testing, not a fix)
3.90 KB, patch
Details | Diff | Splinter Review
patch to allow toolbar autohide on Lion+ fullscreen (FOR TESTING ONLY)
967 bytes, patch
Details | Diff | Splinter Review
Firefox Full Screen bug on fresh install.mp4
5.42 MB, video/mp4
Details
Bug 740148 - Allow toolbar autohide in fullscreen on macOS, but disable it by default. r?#mac-reviewers
48 bytes, text/x-phabricator-request
Details | Review
Screen Recording 2021-04-02 at 16.41.46.mov
6.93 MB, video/quicktime
Details 
With the new fullscreen behaviour, it is not possible to hide the tab bar. This was very useful for presentations.

(Or maybe it is possible but I don't know how)

I can hide most of the toolbars from the view menu (but that's a bit annoying cause you need to reset everything when leaving fullscreen). I suggest adding a menu item while in full mode to allow top toolbars to hide and only show when you hover the top of the browser.
Blocks: 639705
Component: Widget: Cocoa → Toolbars
No longer depends on: 639705
Keywords: regression
Product: Core → Firefox
QA Contact: cocoa → toolbars
We're ignoring the browser.fullscreen.autohide preference on 10.7 now, which is what controlled the previous behavior. We can't reasonably overload that preference for Lion, so maybe we should have a new preference for Lion only? It would default to false but could be enabled through about:config. I'll give it a go.

I know Chrome has a separate "Presentation Mode" which hides the toolbar. If I had to guess though, they're doing that at the Cocoa layer (I think there's an option for that) though I could be wrong.
My questions are mostly curiosity, I'm not implying you're wrong:

(In reply to Paul O'Shannessy [:zpao] (no longer moco, slower to respond) from comment #1)
> We're ignoring the browser.fullscreen.autohide preference on 10.7 now, which
> is what controlled the previous behavior. 
Why ignoring the preference ? Couldn't have it been possible to set this preference key to "false" at update time on Lion?

> We can't reasonably overload that preference for Lion, 
I don't really understand the concept of "overloading a preference", can you be more explicit.

> so maybe we should have a new preference for Lion only?
> It would default to false but could be enabled through about:config. I'll
> give it a go.
That would be awesome!

François.
Summary: Allow hiding toolbars for presentations → [10.7] Allow hiding toolbars for presentations
There are two ways to fix this bug quickly:

1) Provide a non-default option to use the "old" (non-Lion) fullscreen mode on
   OS X Lion and above.

2) Provide a non-default option to obey the browser.fullscreen.autohide setting
   even on OS X Lion and above.

I currently prefer #1, because I'm afraid #2 is a Frankenstein's monster (that it mixes UI elements that don't really belong together).  But it's hard to choose unless you have some kind of testcase to play with.  So I've created a patch that just stops our Lion fullscreen mode from ignoring browser.fullscreen.autohide.  I'll start a tryserver build, which should be available by tomorrow morning.

This is *not* a finished work.  At the very least we'll need to add another setting that governs this behavior.  But I hope it will give people who think they prefer choice #2 above a better idea of whether or not this is what they really want.

(I'll post the patch when I post the tryserver build.)
(Following up comment #4)

Anything besides (or between) these two choices will be more work (perhaps a *lot* more work).  Which means that it (probably) won't be finished anytime soon.
Hi,

Thanks for you work, I'll give it a try when it's ready.

I suppose that 774685 may be a blocker if we want it to work correctly "Lion style". What would be nice (if not too Frankenstein-ish) would be to have the same kind of behaviour as in Apple Preview : both the application menu and the toolbars drop down at the same time.

Cheers.
Here's the patch I promised in comment #4.  As I said there it's not finished -- it's just for people to test option #2 from comment #4.

I already know it's not ideal -- so you needn't bother telling us that it isn't.  The questions that need answering for both options from comment #4 are:

1) Is it better than what we have now?

2) Is it worth landing now as an interim patch?
I tried your build in comment #8.

From a user point of view, and apart from bug #738335 getting in the way a little bit, it's perfect and I don't see what's wrong with that.
Again, still from my user point of view, I think it's better than what we have now (to answer your question in comment #7), and I really don't see what is so evil about it (comment #4).

Thanks.
An additional benefit of a "presentation mode" would be to defeat the current Lion behavior of blanking (with the linen pattern) displays on the second monitor when in full screen mode.

This breaks the current set-up on Air Mozilla where we used Firefox in full screen mode on a mini in the rack to display slides, and used the second monitor display to drive the background of the Extron MGP windower that does compositing of video feed.
The tryserver build in comment 8 only solves half the Air Mozilla problem described in comment 10.
(In reply to comment #10 and comment #11)

Sounds like what you mean by "presentation mode" is choice #1 from comment #4 (the "old", non-Lion-specific fullscreen mode).

My tryserver build (partially) implements choice #2.
(In reply to Richard A Milewski[:richard] from comment #10)
> An additional benefit of a "presentation mode" would be to defeat the
> current Lion behavior of blanking (with the linen pattern) displays on the
> second monitor when in full screen mode.
> 
> This breaks the current set-up on Air Mozilla where we used Firefox in full
> screen mode on a mini in the rack to display slides, and used the second
> monitor display to drive the background of the Extron MGP windower that does
> compositing of video feed.
Mountain Lion will solve this by allowing one fullscreen apps per screen.
> An additional benefit of a "presentation mode" would be to defeat
> the current Lion behavior of blanking (with the linen pattern)
> displays on the second monitor when in full screen mode.

Anthony and Richard:

I don't think we have a bug on this yet.  Please open one. 

In it please address the issue on both Lion and Mountain Lion.

I'm on vacation next week.  But I should have a chance to look at it
when I get back.
(In reply to Steven Michaud from comment #14)
> > An additional benefit of a "presentation mode" would be to defeat
> > the current Lion behavior of blanking (with the linen pattern)
> > displays on the second monitor when in full screen mode.
> 
> Anthony and Richard:
> 
> I don't think we have a bug on this yet.  Please open one. 

Please note that all applications in fullscreen will behave like this. It is Lion specific behavior.
Keynote seems to be able to manage something that at least looks like full-screen dual-display behavior on Lion.
What's possible in the near future is described in comment #4.

Anything more should be the subject of other bugs (like bug 738335).
I am very anxious to restore the true full screen functionality in Lion 10.7.4 lost with today's upgrade to Firefox 14.0.1. 

I have wasted this whole day trying to find a way to do this until I came across this bug thread. As a user, how can I download and install the patch (temporary fix or not) in Comment #7? 

Alternately, how can I get rid of today's upgrade and download the previous version of Firefox? My Mac worked exactly the way I wanted it to yesterday, but since this morning it no longer does.
Tom,

The link in comment #8 is the version with the temporary fix.   You can find older versions of firefox at: http://support.mozilla.org/en-US/kb/install-older-version-of-firefox  (Along with information on why using them might be a really bad idea).
Tom, also note that I've been asking people to make a choice between the two options listed in comment #4.

I assume you'd choose option #1 (provide a non-default option to use the "old" (non-Lion) fullscreen mode on OS X Lion and above).

It's always a good idea to read the whole bug before commenting :-)
I'm going to be on vacation (and mostly away from the internet) all of next week.
Steven,

I've spent over two hours reading the bug, and you're right, option #1 is the one I would choose.

I downloaded and installed the patch in Comment #8, but I can't find the triggering option, so it has no effect. Help please?

Tom
> I can't find the triggering option

I don't understand.

With the tryserver build from comment #8 (which *partially* implements option #2 from comment #4), the only "trigger" you need (once you're in fullscreen mode) is to mouse up to the top of the page.  That should make Firefox's toolbars and menus appear, both at the same time.  (Though the menus do overlap the tab bar, which is the uppermost toolbar -- that's bug 738335.)

Note that this build is for testing, not for everyday use.  For example it doesn't give you the option to go back to the previous Lion-style fullscreen mode (which didn't hide any of FF's toolbars).

(I assume you haven't used about:config to change browser.fullscreen.autohide to "false" from its default setting of "true".)
You're right, I didn't use about:config to change browser.fullscreen.autohide to "false" from its default setting of "true" because I can't find it. About Firefox in my Firefox menu is apparently the wrong place to look. Remember, I am just a user.

My objective is to restore the Lion full screen display to a pure image almost identical to the screen saver image.
> My objective is to restore the Lion full screen display to a pure
> image almost identical to the screen saver image.

I don't understand this, either.

This bug is a real bug, but we can't fix it instantly.

For now your only options (if you're running on OS X 10.7 or above)
are to a) go back to FF 13.0.1 (not recommended because FF 14.0.1
contains security fixes) or b) use my tryserver build from comment #8.

The tryserver build from comment #8 should "just work".  If it
doesn't, we're probably not going to be able to figure out why.
Sorry, I didn't understand either. I thought the FirefoxNightly download was a patch or upgrade to Firefox, which was installed when I dragged the icon into the Applications folder as with other upgrades. Therefore, I expected Firefox to "just work" as you say after restarting it. After I finally figured out that FirefoxNightly is a stand alone application, I found that it works exactly as I expected it to.

Thank you! 

But I would suggest that you consider adding some minimal instructions to future "non-standard" Mac downloads.
Tom,

The other thing I think you missed is how to use about:config.  Type that into the address bar.   CAUTION: It's generally safer to look but not touch.
Richard,

Thanks, I'll tuck that away for future reference. I have my Mac working the way I want it to now, so I think I'll just leave well enough alone for the time being.

Tom
Upgrading to OS X 10.8 Mountain Lion makes Firefox 14.0.1 revert to the (good & desired) behavior of Firefox 13. Not sure why that makes any sense, but I'm happy. However, comment 135 of bug 639705 seems to imply that this is unintended, which is too bad.
Here's another tryserver build made from my (testing) patch from comment #7:

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-654205971c99/try-macosx64/firefox-17.0a1.en-US.mac.dmg

Someone asked for it.

Note that tryserver builds are only available for a week or two.
Thanks for reposting a build.

So when trying this, I feel like it's not something you'd like on a setting. People using their browser fullscreen want toolbars to always be visible. But sometimes you need a presentation mode. It just depends on the context. So I think two entries in the View menu is the best option.
I disagree with Anthony Ricaud. When I use my browser in fullscreen I do not want any toolbars to be visible. I consider fullscreen and presentation mode to be the same thing.

I am still using the Nightly build with the original (testing) patch from comment #7, and will continue to do so until Firefox is upgraded with the identical behavior. If some users want a partial fullscreen with toolbars (name it what you like), I agree it should be a separate option. I suspect that such an arrangement would be difficult to implement.
Obeying browser.fullscreen.autohide and showing the a context menu for toggling it should be flexible enough for those who want to permanently hide toolbars and those who want it temporarily.
(In reply to tom.etheridge from comment #32)
> I disagree with Anthony Ricaud. When I use my browser in fullscreen I do not
> want any toolbars to be visible. I consider fullscreen and presentation mode
> to be the same thing.

Yeah, I really would like to know where this assertion of "People using their browser fullscreen want toolbars to always be visible" comes from. Especially since with the toolbars visible, one is almost not gaining any space on the screen, which is the point of running full screen!
Especially, I don't understand the point of disabling the functionality allowing to hide toolbars. If people want to keep their toolbars on, even by default, fair enough. But why would one remove the possibility completely?

Maybe it's just me presenting it in a negative way, but I'm yet to find someone who finds the new full screen mode better than the old one (apart from OS integration).
Tom: I think your use-case would still be possible with two options in the view menu. You'll just use presentation mode all the time.

What I tried to (poorly) say in comment 31 is that it's not only a matter of a user preference. It's also a matter of context. I don't prefer "tabs visible" or "tabs hidden", I prefer the mode that makes more sense depending on the context. When doing presentations or running WebGL demos, I'll certainly use the "presentation mode". But then when I'm at my desk, maybe I prefer tabs to be visible or not.
With the "fixing" of bug 639705 in 15.0, we're now back at a stage when a full-on presentation mode is impossible in the main release of Firefox. Any chance of fixing that.

Now that the keystroke has been standardized to the usual OS X cmd-control-F, I think the best way to handle presentation mode is to mimic Preview.app. It has Enter Full Screen at cmd-control-F and Slideshow at cmd-shift-F. We can add Presentation Mode at cmt-shift-F by analogy.
the absence of a presentation mode render firefox useless for HTML(5) based presentations and also slideshows. :-(

(In reply to Anthony Ricaud (:rik) from comment #13)

> Mountain Lion will solve this by allowing one fullscreen apps per screen.

...doesn't seem to.  A Firefox CMD-SHIFT-F  on one monitor replaces the wallpaper on the second monitor with the linen pattern.
Hello,

Could we please have an update on Mozilla's *intentions* on the matter?

It's really irritating that we've lost a functionality and that it's taking months to make a decision about how to re-implement it. Whichever way you do it, I don't care any more, please just do it...

Cheers,
Firefox is so poor on OS X. I prefer Gecko and I like FF but it's bugs like this that make it hard to use on OS X.

I can't believe that anybody desires the functionality how it is now. In full screen mode the tabs (at least) should auto hide. It's the only functionality that makes sense.
recent Opera, Safari and Chrome all provide fullscreen aka presentation mode in Mountain Lion, with no UI toolbars showing.

What is the holdup on fixing this regression bug?
Does anyone know of an add-on that can solve it while this bug is still open? Having to run full-screen presentations in Chrome when talking on Firefox/Mozilla topics is pretty hilarious.
tried that, doesn't work for me on ML and latest FF :-(
First of all, the name of this bug should not be "Allow hiding toolbars for presentations." It should be "Restore fullscreen mode," which was the original intention. Fullscreen mode is useful in far more situations than merely presentations. For example, reading on-line magazines, maximizing the size of on-line artwork, and watching HD videos. Words mean things, and implying that this problem only affects presentations diminishes its importance.

I just installed Firefox 19.0.2 (the latest version) and the problem is still there. That is inexcusable. This problem was completely fixed in Nightly 17.0a1 (2012-07-18), which I am still using, and will continue to use until the obstinate developers at Mozilla get off their stubborn butts and fix it in Firefox. They obviously know how, they just won't.
Here's a working add-on that reverts to the old custom-built fullscreen mode:
https://addons.mozilla.org/en-US/firefox/addon/nofs/
Looking under the covers it's astonishingly simple...
when fix it ???
The addons: https://addons.mozilla.org/en-US/firefox/addon/nofs/ 
and https://addons.mozilla.org/en-us/firefox/addon/old-lion-fullscreen/
provide a full screen, but can be considered a PARTIAL FIX. Because using these we cannot access the menu bar while in full screen.

Anyway, is better than without them.
NOFS addon don't show the navigation bar when hoovering the mouse on top, so I recommend using Old Lion FS addon.
The original intent can be fixed by using the DOM Fullscreen API. 

Now, I do think that having the option to (A) autohide the browser chrome in (browser, not DOM API) fullscreen mode is something many people (myself included) might like (when moving the mouse to the top, the chrome should slide in like, and with the menu bar). There's also the "mobile" solution (B) which slides out the chrome while scrolling down (and sliding back in when scrolling up, not necessarily only when scrolling all the way to the top), so that's another option to solve this problem. 

As I understand, solution (A) is what this bug is about. Or how about investigating solution (B)? Either way, can somebody please clarify the title, then?
This problem has not been fixed for almost two years now, why is it still not possible to have a working full-screen mode with Firefox v24? I can see where the problem is, however one would expect that the Mozilla developers can come up with a solution within two years - yes, the OSX full-screen mode intends to only hide the system UI elements like menu bar and notifications, nevertheless Mozilla can still change the way Firefox behaves in that mode. Seeing how this ridiculous bug has not been fixed yet I do believe that this won't change in the future. Well done.
I have to use Chrome and Firefox simultaneously for web app compatibility reasons and I feel as though my Firefox user experience is lessened by the amount of screen I can use. Seems like an easy fix and weird that it has gone unfixed for so long.
I thought maybe they were saving this fix for Australis, but I just tried the nightly and fullscreen still doesn't hide the bars.  Very disappointing...
Running Nightly 29.0a1 (2014-01-03) on 10.9 Maverick and experiencing the same issue.  Would love to see a fix for this as well.
Confirm.

Still not working with Firefox 26.0 under MacOS X 10.9.1 Mavericks.

There is no option in Firefox to get a real Firefox-Fullscreen (no bars or Menue) any more since Apple introduced "Fullscreen-Function"?
If anyone is interested, I wrote a very simple fix using Stylish. This hides specific toolbars (in my case, the Personal Toolbar, the Web Developer Toolbar and Googlebar Lite), but re-shows them if you mouse over the toolbar area. It also removes the ~11px of padding at the top that exists for no reason that I can see.

It's easy to add other toolbars, but you need to use the DOM Inspector to inspect the chrome and find their IDs.


@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);

#main-window[inFullscreen=true] {
    padding-top: 0px !important;
}

#navigator-toolbox[inFullscreen=true]:not(:hover) #PersonalToolbar,
#navigator-toolbox[inFullscreen=true]:not(:hover) #GBL-Toolbar,
#navigator-toolbox[inFullscreen=true]:not(:hover) #web-developer-toolbar,
#navigator-toolbox[inFullscreen=true]:not(:hover) .web-developer-toolbar {
    visibility: collapse;
}
This add-on has been working great for me to get fullscreen back: https://addons.mozilla.org/en-US/firefox/addon/old-lion-fullscreen/?src=userprofile

(it was buried up above in this thread but lost in the sands of time by now)
I still using the old-lion-fullscreen addon but it has some bugs.

If i move the mouse up to the top of the screen it often doesn't show the menu or bars.
Flags: firefox-backlog?
Hardware: x86 → All
Flags: firefox-backlog? → firefox-backlog+
Whiteboard: p=0
Confirming this -- using Mavericks 10.9.2 and Firefox 28. When one goes into full-screen mode, the tabs and navigation bar are still visible. 

(NB: browser.fullscreen.autohide is set to true. Also, I use the firefox menu rather than the OS X control to go into full-screen, if that makes a difference.)

(I see there's an add-on to get round this but it seems better not to need an add-on, especially if the latter is buggy.)
Whiteboard: p=0 → p=3
Depends on: 1016361
Depends on: 1066282
Points: --- → 3
Flags: qe-verify?
Whiteboard: p=3
Will this ever be fixed? Chrome is able to provide a presentation mode in OS X native fullscreen that works, for a long time already.
It has been years of this regression. Why no mozilla developer cares to fix such useful feature?
I've been just sitting here using old-lion-fullscreen for Firefox, which requires its own desktop to work, for years, hoping this would get fixed. It wasn't.
I'm currently using Chrome to public talks about Mozilla. That's kind of contradictory but that's what we have. I agree with Francisco. This bug deserves better attention.
(In reply to Sergio Oliveira Campos from comment #65)
> I'm currently using Chrome to public talks about Mozilla. That's kind of
> contradictory but that's what we have. I agree with Francisco. This bug
> deserves better attention.

Hi Sergio, please keep doing that, if people get to ask why you're doing that, it's one more way to explain and complain about it =)
Like the other posters have commented, it is crazy that this is still a bug, and drives me insane when I use fullscreen mode. Again the fact that there is even a setting - browser.fullscreen.autohide - but it is just ignored seems nuts.

I don't have enough FF internal knowledge to understand why it simply can't just be set to default to false on Mac OS X, and then allow the user to change the value when desired?

Why would that be a problem?
I'm using the following userChrome.css to work around this bug:

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

#main-window[inFullscreen="true"] #nav-bar,
#main-window[inFullscreen="true"] #TabsToolbar {
    display: none !important
}

It could use some more work, e.g. there's no popup for CMD-L, but it's enough for me.
(In reply to kAton from comment #48)
> The addons: https://addons.mozilla.org/en-US/firefox/addon/nofs/ 
> and https://addons.mozilla.org/en-us/firefox/addon/old-lion-fullscreen/
> provide a full screen, but can be considered a PARTIAL FIX. Because using
> these we cannot access the menu bar while in full screen.

Recently bought a new laptop, so I moved from 10.4 to 10.10.4, and now I'm being effected by this bug, too (was using TenFourFox on the old laptop).

Have you tried this extension?
https://addons.mozilla.org/en-US/firefox/addon/fullscreen-toolbar-hover/

Seems to be working for me. Removes the toolbars that Firefox's fullsceen mode is not, and I can still access the menubar if I mouse to the top, along with the address bar, tab bar, and bookmarks bar.
For those landing on this bug who are looking for a workaround that will hide everything in full-screen mode on Mac OS X, including the address and tab bars, here is an extension I have found to work reasonably well. https://addons.mozilla.org/en-US/firefox/addon/old-lion-fullscreen/

The extension mentioned in comment #69 is no longer available.
So it's been two years since the last comment on this bug.

I just created a new profile on the current Firefox (54.0).
Going to full-screen mode leaves the tab bar and main toolbar still. The only thing that's really being hidden is the menu bar and window control buttons in the upper-left.

While we have some extensions that work *right now* for getting a true full screen mode, will any of those still work after Firefox 57 or whenever you change to the WebExtensions API? I'm still using the extension I mentioned in Comment #69, and the "Old Lion Fullscreen" extension appears abandoned since its GitHub hasn't seen changes since 2012.

It's been a long time since OSX Lion (10.7). Isn't it about time for a real solution on this?
At least I've moved to Linux for good and don't suffer from this anymore.
[Tracking Requested - why for this release]:
Because it is a known issue that is being worked around with extensions that will cease to function in FF57.

I can't set the "status" flag the way the GIF wants me to -- there is no "affected" option. Bug in Bugzilla? <g>
status-firefox57: --- → ?
tracking-firefox57: --- → ?
See Also: → 1424955
I explain here how I fix this issue: https://apple.stackexchange.com/a/313150/24974
See Also: 1424955 → 
So I went up and dug the current source here: https://hg.mozilla.org/mozilla-central/file/tip/browser/base/content/browser-fullScreenAndPointerLock.js#l528

>  _safeToCollapse() {
>    if (!Services.prefs.getBoolPref("browser.fullscreen.autohide"))
>      return false;
> ...
>    // On OS X Lion we don't want to hide toolbars.
>    if (this.useLionFullScreen)
>      return false;


I haven't grabbed the source yet, but could anyone try strip that two lines off and see how things go? Fullscreen implementation had been rewritten since :smichaud made the patch from comment #4, and all apps are supposed to support Lion-style fullscreen for now.
(In reply to Poren Chiang from comment #82)
> could anyone try strip that two lines off and see how things go?

Just tried it on aurora @ 03bea733be33 because that's what I had lying around. When I first enter fullscreen the toolbars hide themselves (with animation). When I move the mouse to the top they show themselves but then _never hide themselves again_ unless I exit fullscreen and re-enter it.
(In reply to Sam Hathaway from comment #83)
> (In reply to Poren Chiang from comment #82)
> > could anyone try strip that two lines off and see how things go?
> 
> Just tried it on aurora @ 03bea733be33 because that's what I had lying
> around. When I first enter fullscreen the toolbars hide themselves (with
> animation). When I move the mouse to the top they show themselves but then
> _never hide themselves again_ unless I exit fullscreen and re-enter it.

Then it might also depends on OS X version: I'm on 10.9 and even when I enter full-screen, the whole toolbar stays in place.
(In reply to Clément Lefèvre from comment #84)
> (In reply to Sam Hathaway from comment #83)
> > (In reply to Poren Chiang from comment #82)
> > > could anyone try strip that two lines off and see how things go?
> > 
> > Just tried it on aurora @ 03bea733be33 because that's what I had lying
> > around. When I first enter fullscreen the toolbars hide themselves (with
> > animation). When I move the mouse to the top they show themselves but then
> > _never hide themselves again_ unless I exit fullscreen and re-enter it.
> 
> Then it might also depends on OS X version: I'm on 10.9 and even when I
> enter full-screen, the whole toolbar stays in place.

Without stripping off the two lines that Poren Chiang mentioned in comment #82, I get the same behavior as you. Once I remove those two lines, I get the behavior I described.
(In reply to Sam Hathaway from comment #85)
> (In reply to Clément Lefèvre from comment #84)
> > (In reply to Sam Hathaway from comment #83)
> > > (In reply to Poren Chiang from comment #82)
> > > > could anyone try strip that two lines off and see how things go?
> > > 
> > > Just tried it on aurora @ 03bea733be33 because that's what I had lying
> > > around. When I first enter fullscreen the toolbars hide themselves (with
> > > animation). When I move the mouse to the top they show themselves but then
> > > _never hide themselves again_ unless I exit fullscreen and re-enter it.
> > 
> > Then it might also depends on OS X version: I'm on 10.9 and even when I
> > enter full-screen, the whole toolbar stays in place.
> 
> Without stripping off the two lines that Poren Chiang mentioned in comment
> #82, I get the same behavior as you. Once I remove those two lines, I get
> the behavior I described.

Oh, my bad then, read it too quickly, didn't thought it was with this small patch.
Can't test it myself then, it would require to compile it.
I am getting somewhat better results than Clément by also removing the check for !this.useLionFullScreen in showNavToolbox(). See attachment bug740148.patch.

Working:
- toolbars are hidden when entering fullscreen and shown when leaving fullscreen
- toolbars are shown when pointer approaches top of screen and hidden when pointer moves away
- toolbars are shown when ⌘L is typed (and address bar is selected)

Not working:
- after ⌘L, typing a URL, and pressing return, the toolbars stay shown, even if the mouse is nowhere near the toolbars. this will persist until you move the mouse to the top and away again.
- after ⌘L and using the tab key to move the keyboard focus back to the page content (so that the toolbars are no longer in focus), the toolbars stay shown. this will persist until you move the mouse to the top and away again.
- if you move the mouse to the top of the screen to show the toolbars and then leave it there, the macOS menubar and window title bar will also be shown, covering the top of the toolbars.
- if the address bar is focused when entering fullscreen, then the toolbars will always stay visible, until leaving/re-entering fullscreen.

So it's a start I guess...
I approximate a fix for this in my userChrome.css, which I've added as attachment 9031750 [details] to bug 1016361. Download this file into the "chrome" directory of your Firefox profile and restart the browser. The behavior is much as described in comment 87 with respect to what works and doesn't work, but at least you don't have to edit the browser chrome files after every nightly update.
Does any of these userChrome.css fixes handle this issue: https://apple.stackexchange.com/questions/70985/?

Serious question.

My response does: https://apple.stackexchange.com/a/313628/24974.
I use a userChrome.css myself as part of the fix (https://apple.stackexchange.com/a/313241/24974), but without the rest to fix the macOS fullscreen top menu, it's simply a pain to use with Firefox, experience is worse than Chrome.
I'm hoping for a fix in Firefox itself rather than having to kludge around it in AppleScript or userChrome patches.

I think we should be looking at Safari for our model. When View > "Always Show Toolbar in Full Screen" is off, the macOS menubar and the Safari toolbar behave as one unit; they slide in and out together. (Compare to the somewhat glitchier slide that Chrome does.) I'm hopeful that we can get this behavior, but it might be tricky since Firefox doesn't use the native macOS toolbar widget.
I got tired of hoping (7 years) so I kludged around and found a fix that works for me, and also applies to other applications. It's not entirely Firefox fault, I remember how full screen worked before and what mess they introduced with the new (already old by now) full screen, because of the hardcoded auto-unhide menubar that conflicts with applications toolbars themselves, it's simply bad design. I don't use macOS as my main platform myself anymore, so just commenting on my previous experience there. At least when I have to use it I have this fix, and I don't have to bother fighting with mouse hovering on top screen edge anymore.

If someone is looking for a better workaround

https://pastebin.com/YT0TCzPe

https://i.imgur.com/RTt93LX.mp4

It seems to work without most issues in comment 87.

If you move the pointer to the top and move it away fast enough then the macOS menubar won't show up.

source: https://www.reddit.com/r/FirefoxCSS/comments/bhbvhj/

On FF Dev Edition + Catalina, the toolbars & tabs are still visible when using the full screen :/

So its been 9 years and still no official fix for this?

This is reproducible on a fresh install of macOS and Firefox and just plain doesn't work "right out of the box." (See attached video recording)

Yes I understand there are add-ons, about:config changes, and CSS tweaks but none of them work 100% and come along with other side effects which cause issues.

Why is it so hard for Firefox to fix such a fundamental feature?

Whiteboard: [mac:fullscreen]

The issue is still reproducible with full-screen-api.macos-native-full-screen:true on macOS M1 mini 11.2.2 with Firefox 88.0a1 (20210303215027).

status-firefox88: --- → affected
status-firefox57: fix-optional → wontfix
status-firefox88: fix-optional → wontfix
Summary: [10.7] Allow hiding toolbars for presentations → Allow hiding toolbars for presentations

I think now is a good time to use the fix like the one in comment 87. As far as I know, the check to disable autohide on macOS was introduced because

  1. Prior to bug 738335, the titlebar would slide down over the toolbar. If autohide was enabled, you wouldn't be able to access some parts of the toolbar.
  2. Bug 1168397, which no longer appears to be an issue.

To address the concerns in comment 87:

Not working:

  • after ⌘L, typing a URL, and pressing return, the toolbars stay shown, even if the mouse is nowhere near the toolbars. this will persist until you move the mouse to the top and away again.

This is still an issue.

  • after ⌘L and using the tab key to move the keyboard focus back to the page content (so that the toolbars are no longer in focus), the toolbars stay shown. this will persist until you move the mouse to the top and away again.

Still an issue.

  • if you move the mouse to the top of the screen to show the toolbars and then leave it there, the macOS menubar and window title bar will also be shown, covering the top of the toolbars.

Fixed by bug 738335.

  • if the address bar is focused when entering fullscreen, then the toolbars will always stay visible, until leaving/re-entering fullscreen.

This no longer appears to be an issue. Blurring the address bar hides the toolbars.

What I'm going to do is apply a patch like the one in comment 87 and also disable browser.fullscreen.autohide by default on macOS. I'll file a follow-up to re-enable it by default, blocked on:

  • Resolving the two unresolved issues in comment 87 (or, at the very least, checking with Product and UX that they're not blockers)
  • A UX review of autohide on macOS (i.e. bug 1016361)
  • An audit of what caused bug 1168397, to ensure that we're not going to encounter it accidentally in the future.
Blocks: 1702563
Assignee: nobody → htwyford
Status: NEW → ASSIGNED
Iteration: --- → 89.1 - Mar 22 - Apr 4
Points: 3 → 1
Pushed by htwyford@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e5ab44fa3549
Allow toolbar autohide in fullscreen on macOS, but disable it by default. r=mac-reviewers,mstange,bradwerth

https://hg.mozilla.org/mozilla-central/rev/e5ab44fa3549

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox89: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

Hi Harry!
While looking at this today we observed that there is no animation when the toolbars are displayed or hidden. Attached a screen recording. Is this expected or should we file a new issue on this?

Also if the Hide toolbars option is activated while in fullscreen from the context menu it shows only the first time and the second time does not get displayed until the browser is unfocused or Fullscreen is closed and reopened leaving only the Apple menu opened. Screen recording here: link. Maybe this has to do with bug 1697694 because we interact with the context menu option and then the App menu remains stuck.

Flags: needinfo?(htwyford)

Thank you for fixing this! I just tried the nightly build and it worked great

Thanks for noticing those bugs Alexandru. It's expected that this behaves the same across all platforms. If Windows or Linux builds don't animate the toolbar when it's hidden, then it shouldn't on Mac either. Adding an animation could be done in bug 1016361.

The second point sounds concerning. Could you please file a new bug for that? We can always dupe it to bug 1697694 later if they turn out to have the same cause.

Flags: needinfo?(htwyford) → needinfo?(alexandru.trif)

Thank you Harry! Filled bug 1703552. Also this is the correct scren recording: link (it seems that I placed the wrong link for this issue in comment 105)

Flags: needinfo?(alexandru.trif)
Blocks: 1710151

Thank you for taking on this long awaited bug, Harry
Unfortunately I can't find the option to hide toolbars anywhere in the menus. It is just absent. Although I see that this bug was fixed in Firefox 89 release notes. Am I missing something?

https://imgur.com/JID4ufv
https://imgur.com/866NoKg

Flags: needinfo?(htwyford)

Unfortunately I can't find the option to hide toolbars anywhere in the menus.

Go into fullscreen mode, then right click on any toolbar icon. You should get two items in the context menu now: "Hide toolbars", "Exit fullscreen".

Further work is tracked in bug 1702563

(In reply to Albert Scheiner [:alberts] from comment #110)

Unfortunately I can't find the option to hide toolbars anywhere in the menus.

Go into fullscreen mode, then right click on any toolbar icon. You should get two items in the context menu now: "Hide toolbars", "Exit fullscreen".

This is correct. You can right click anywhere on the toolbar when in fullscreen mode to get the menu.

Flags: needinfo?(htwyford)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: