Open Bug 1016361 Opened 6 years ago Updated 12 days ago
[UX] Design for a toolbar-less fullscreen mode on Mac
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.
(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
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.
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.
6 years ago
Whiteboard: p=13 → p=5
That sounds like a great plan. Would love to see any activity on that, you are doing great work with the Developer Edition.
5 years ago
Whiteboard: p=5 → [qx] p=5
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.
Check this for a solution: https://bugzilla.mozilla.org/show_bug.cgi?id=740148#c77
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)
Component: General → Firefox Desktop: Consultation
Priority: -- → P3
Product: Firefox → User Experience Design
Version: 31 Branch → unspecified
Points: --- → 2
You need to log in before you can comment on or make changes to this bug.