Open Bug 1016361 Opened 6 years ago Updated 12 days ago

[UX] Design for a toolbar-less fullscreen mode on Mac

Categories

(User Experience Design :: Firefox Desktop: Consultation, defect, P3)

x86
macOS
defect
Points:
2

Tracking

(Not tracked)

People

(Reporter: phlsa, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [qx] p=5)

Attachments

(1 file)

There is no real fullscreen mode on OS X anymore (i.e. one that hides all the toolbars etc.), so let's think about what such a mode could look like.

While this is primarily an issue on Mac right now, the results of this work could also be used to improve the fullscreen experience on other platforms.
Flags: firefox-backlog+
(In reply to Philipp Sackl [:phlsa] from comment #0)
> There is no real fullscreen mode on OS X anymore (i.e. one that hides all
> the toolbars etc.), so let's think about what such a mode could look like.
> 
> While this is primarily an issue on Mac right now, the results of this work
> could also be used to improve the fullscreen experience on other platforms.

The code that hides the toolbars etc. is shared across platforms, we just need to use it again on OS X. Short-term focus should be on specifying how OS X users are supposed to enter that mode (bug 740148). Changing how that mode itself looks or behaves is a separate cross-platform question.
Copying Chrome, it could be "enter fullscreen mode" (and be a different mode)

I believe that instead if should be that the visibility of the toolbar / tabs be like on other platform, or like the menu bar on Mac fullscreen: ad-hoc when needed.

That's just my $.02
A simple interim solution could be to we show the toggle context menu item on the toolbars like we do on Windows/Linux? I'm not sure if the code path is totally different making this harder than it seems.

https://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-fullScreen.js?rev=ff1731d85f58#520
Whiteboard: p=13
Is there any update on this whatsoever? Just switched back from Chrome to Firefox and that really is one of my biggest issues now and it seems there is quite a few people/developers who would love to see better support for the fullscreen mode.
One would think with the large user base on Mac at Mozilla that use the browser for presentations that this would be high priority - instead of making them use Chrome.
I'm a heavy Firefox user but I do use Chrome in my presentations because of that. It would be very nice if that could be set as high priority.
Blocks: 1066282
One thing we could do is to rename the fullscreen-button in the menu panel to something like »Presentation mode« since we already have a native control for normal fullscreen in the corner of the window.

Here's what would need to be done:
- Rename the menu item and create a more fitting icon for it
- Make the menu item set FullScreen.useLionFullScreen to false when it gets clicked
- Make sure that this setting only affects one window
- When in presentation mode, make sure that the page doesn't jump when the chrome appears
- Also nice: make the chrome appear with some transition instead of just popping up.
That sounds like a great plan. Would love to see any activity on that, you are doing great work with the Developer Edition.
Is there any updates on this! Its quite sad that we have to use Chrome for presentations.
Safari 9 has an option for that in view menu:
Always Show Toolbar in Fullscreen

I'd like to see this in Firefox
I have a somewhat different perspective on the requirement than most commenters.  I think there are two parts:
 1. The part in the subject, i.e. provide a full screen mode that devotes the entire screen to the web page, with NO visible artifacts from either the browser or the operating system.
 2. Either allow this option to be driven by the displayed page (ECMAScript) [dangerous, since it could be used to spoof the OS or browser interface] OR make it both compatible with the way such a mode is obtained on other browsers and OSes, and extremely simple, so that the user (not the developers who hang out here, but the 'typical' user) can be instructed with few words how to select it.

I'm working on a web-based game for children ages 2-5 or so.  They can't read yet.  An adult will have to set up the environment in which the game runs best for them.  That means nothing visible but the game screens themselves.  Since I can't create that environment programatically, I need to give the adult clear and concise instructions for doing so.

For Firefox on Windows, it's easy: "Maximize the window, then press F11 (which may require first holding down a 'fn' key)".
For Firefox on OS X, it seems to be impossible.  If it becomes possible, but requires modifying about:config or installing an add-on, that's useless to me.  KISS.
(In reply to Chris Beall from comment #11)
>  2. Either allow this option to be driven by the displayed page (ECMAScript)

This API already exists and has been supported in Firefox for many years: https://developer.mozilla.org/en-US/docs/Web/API/Element/requestFullScreen
Hey Matt,

Thanks for the suggestion but I believe the point of this bug is the incoherent behavior of Firefox across platforms. I'm sure the community could develop a plugin to make Firefox fullscreen but is that what we really want?

Personally not having this feature is something annoying. For the past year I had to use Chrome in every presentation I've made just because I can't have real fullscreen using Firefox.

I'm not sure if this was a design decision but for me this looks like a bug caused when OS X introduced it's own fullscreen mode a few years ago.

Having this implemented in Firefox for OS X like it's implemented in Firefox for Windows isn't something reasonable?
Hey Sergio, I wasn't discussing this bug in recent comments, I was replying to the off-topic ones.

I personally don't think you need to use Chrome instead of installing an extension though. Btw. all HTML slide decks use the fullscreen API already. I agree that you probably shouldn't need an extension but for now you do.
Matt,

Thanks for the API pointer (which points, in turn, to https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen).  For me, that's the best interface, once I get it to work (though I've yet to be successful, targeting the <body> element and driving it from an onload handler on that element).
(In reply to Chris Beall from comment #17)
>(I've yet to be
> successful, targeting the <body> element and driving it from an onload
> handler on that element).

OT.  Among the not-well-documented pitfalls to using fullscreen:
  - Cannot be driven from onload.  Onclick works.  The idea is to ensure that the user intentionally initiated the action.  If there's a complete list of 'on' conditions that allow fullscreen, I haven't found it.
  - Won't work if immediately preceded by an alert(), such as you might use if trying to determine if you reached the right place in your code.  This is probably another attempt to prevent spoofing a real user into clicking where they shouldn't.

And, subject to further investigation, seems to:
  - Preempt usage of the Escape key within the application, while remaining full-screen, as that drives the exit-fullscreen function of the browser.
  - Prevent vertical scrolling if the content is specifically dimensioned to exceed the screen size.
See Also: → 1424955
See Also: 1424955
Here is a userChrome.css I use to get a working fullscreen back on Mac. With this you can still access the tabs and addressbar by hovering near the top of the screen. If you don't mind having to exit fullscreen to navigate or switch tabs then it could be simply the last bit without the :not(:hover)

Markus: Gijs suggested I ping you on this bug. There are a lot of people unhappy that Fullscreen on Mac shows the tabs/toolbar. It doesn't seem to be an intentional UX decision given that Windows and Linux Firefox do it differently, and it's not an OS limitation given web content can trigger full-fullscreen on mac. Can we get a UX decision on whether we can fix this?

As a comparison, Chrome offers users a choice between showing the tabs or not when in fullscreen ("Always show Toolbar in Full Screen" toggle on the View menu). Same in Safari. In both when you mouse up to the top you get the title bar and menu. In Safari when you do so you get to see your tabs and a working address bar, but in Chrome you get neither if you're not showing tabs in fullscreen. Safari's behavior is nicer and I tried to emulate that with my userChrome.css (weakly, because it's not actually tied to the OS window chrome).

Obviously this is an old bug, but it's getting renewed urgency because many of the homegrown workarounds (e.g. comment 19, comment 20, https://github.com/nuchi/firefox-quantum-userchromejs) rely on features we want to go away. The last one there is particularly ugly since it uses XBL to run user script in the chrome, and we're getting telemetry we'll break a bunch of people when we try to ratchet up some anti-exploit protection for our product chrome pages.

Flags: needinfo?(mjaritz)

Note also that there's an extant context menu item on the toolbars in fullscreen mode on mac to "Hide Toolbars" (where not hiding them means they autoshow based on mouse movement, which is the behaviour on windows), but the context menu item is non-functional (ie ticking/unticking it does nothing).

Component: General → Firefox Desktop: Consultation
Flags: firefox-backlog+
Priority: -- → P3
Product: Firefox → User Experience Design
Version: 31 Branch → unspecified

Thank you for bringing this up. I put it on the backlog for my team to pick up when someone has time.
I do understand the renewed relevance and urgency. When would the mentioned features go away and break workarounds?

(In reply to Daniel Veditz [:dveditz] from comment #21)

Obviously this is an old bug, but it's getting renewed urgency because many of the homegrown workarounds rely on features we want to go away. > we're getting telemetry we'll break a bunch of people when we try to ratchet up some anti-exploit protection for our product chrome pages.

Points: --- → 2
Flags: needinfo?(mjaritz)
You need to log in before you can comment on or make changes to this bug.