I think that this could be worded also : - Fullscreen state should be a counter, not a flag, so that it can be entered recursively Steps to reproduce: - go to this page http://blogs.sitepointstatic.com/examples/tech/full-screen/index.html - presse F11 to go in full screen mode - click on the squirrel image - exit the full screen squirrel image any way you wish - you are back to the previous page but *not* anymore in full screen mode on that page Actual results: Firefox displays the page http://blogs.sitepointstatic.com/examples/tech/full-screen/index.html outside of fullscreen mode Expected results: Firefox should stay in fullscreen mode if the user has selected it manually before an application made him enter fullscreen mode programmatically (when he exits the fullscreen mode of that application). This behavior very likely interacts with bug 724554 in some interesting ways.
It's not likely I'll get to this any time soon unfortunately, so if someone else wants to take this in the meantime, that's fine.
Assignee: cpearce → nobody
Well I don't know when someone will have time to take care of that, but anyway the actual desirable behavior needs to be precisely identified first. And it's not that easy after all because they are many border cases. They are actually two perpendicular axes : - the user decision with the F11 key - the application request with the fullscreen API It's obvious the user decision with F11 should override the rest. But then, it's not very easy to understand what the principle of least astonishment will be if they are recursive full screen API calls. If I allow an application to go full screen, and then it start a second full screen application, and I use F11 to go out of full screen, and next leave the second application, do I expect I will be full screen again coming back to the first application ? Probably not. Now, if I allow an application to go full screen, then use F11 to go out of full screen, then use F11 to go full screen again, and next leave the application, do I expect to leave full screen ? I think, probably. One simpler thing : When the browser is already full screen before the application request full screen, the confirmation screen is not needed (and it appears now)
> One simpler thing : When the browser is already full screen before the > application request full screen, the confirmation screen is not needed (and > it appears now) It is needed -- browser window fullscreen and document element fullscreen have different entry, different ui within, and different exits. Anyway it shouldn't sound so complicated I think from the user facing side -- a fullscreened browser window is a user toggled mode, and an element of the document fullscreened by script waddles and quacks like a popup (except that it unfullscreens its parent when closed, which is just weird).
Even though it does need some time to get used to on the Mac, I do like how Chrome handles it. It has something called 'Presentation Mode' and 'Fullscreen Mode'. You can enter both without any HTML5 elements, where-as Presentation Mode is like the Mac OS native Fullscreen Mode + hidden tabs. That is one functionality really missing for FF on the Mac. And if you watch a HTML5 Video in fullscreen Chrome automatically switches to 'Presentation Mode' and if you click ESC it switches back to 'Fullscreen Mode' Anyway, hope there will be some progress soon. One of the little annoyances that could FF help to get on top of other Browsers.
See also bug 947854, which is a Mac-specific version of this bug.
I think this bug and bug 947854 is the same problem, and could be solved together. I've changed the platform to All in that bug.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
See Also: 947854 →
Duplicate of bug: 947854
You need to log in before you can comment on or make changes to this bug.