There are several difficulties here. 1. What keyboard shortcut to use? Preview uses Cmd+Shift+F, iTunes Cmd+F, Opera doesn't have a shortcut key and Chromium uses Cmd+F11 (!?). Looks like Cmd+Shift+F to me. 2. What should the restore buttons look like? Do we really want the whole set (minimize, restore, close)? I think a restore button would be enough.

(In reply to comment #0) > 2. What should the restore buttons look like? Do we really want the whole set > (minimize, restore, close)? > I think a restore button would be enough. Is that a Mac-specific question?

Yeah, I'm only thinking about Mac right now. Maybe the minimize and close button should go on the other platforms, too, but I'm not sure if this bug is the right place to discuss that. None of the Mac applications with full screen support I know allow closing or minimizing while in full screen mode. Moreover, minimizing doesn't even seem to be possible while the Dock is hidden (the minimize button of non-fullscreen windows is disabled), so I think we can definitely get rid of that button on Mac. Another argument for removing the close button is that it's currently positioned in the top right corner, which is just wrong on Mac OS X.

Leopard introduced what I would consider a "default" fullscreen look/behavior with Quicklook(probably predated by iTunes). You get a mini-HUD with a Close glyph and a Restore glyph. It goes away when if you don't move your mouse for a few seconds. I don't think that would necessarily work for us but I think we should consider using the symbols.

>I think we should consider using the symbols. Overall I agree, white glyphs consisting of either two arrows and an X seem to have a lot of external consistency on OS X for the concepts of "restore down" and "exit full screen mode." The only problem is that they often end up meaning the same thing, and being interchangeable (iPhoto uses X, Quicktime two arrows), Also in general OS X windows can't be closed from full screen mode, you have to first restore down and then close the window. The finder quicklook window is an exception.

In terms of overall appearance, I was thinking a HUD style panel similar to the button/glyph appearance of iPhoto (on the right). The panel would hide when you are not using it, but it unlike iPhoto it would be docked to the top of the screen. It's debatable if we want to expose the menu bar or not. I'm thinking probably not, and having access to the two new toolbar buttons Page and Tools, which contain all functionality.

Yeah, a HUD UI would be great. However, that requires that we can put toolbars on top of content without moving the content area down. And as far as I know that will only be possible after phase 3 of Compositor has been completed, which might not make it into Firefox 3.6. I think we should start with something simple here so that testing of the fullscreen mode can begin as soon as possible. How about a normal toolbar button (like the refresh button) with the restore glyph on it?

This is what I mean.

That looks like bug 206544.

The problem that Dão points out is that if bug 206544 lands (and the user has put the new fullscreen button in his toolbar), we'd have two buttons to get out of fullscreen mode that look very similar. A possible solution might be to only show the restore button if there's no fullscreen button in the toolbar.

You can simply implement toolbars-on-content using panels. Though I'd bet that would expose some bugs in the full screen implementation ;)

Yeah, and it would be non-trivial for several reasons. For example, how do you put the tab bar into the panel? Rip it out like in bug 347930, which might not even work any more?

The tabbar is by no means considered a toolbar. We made a pretty great effort to ensure that isn't changed in the past.

I think we want the tabbar in the HUD fullscreen UI anyway, regardless whether it's a toolbar or not.

Comment on attachment 390848 [details] mockup giving this a ui-r+ for the purpose of getting it landed for testing. Not an ideal solution, but as long as we also support the Esc key this should work well enough.

Stephen, could you create a suitable button and send me the new Toolbar.png? Maybe you want to combine this with bug 494927 and / or bug 504160... the ordering is up to you ;-)

Note that bug 206544 has landed.

>Note that bug 206544 has landed. This is kind of the equivalent of the window controls on Windows (minimize, restore down, close), so while redundant (if the user has added the full screen button), I think we probably need to include the OS X standard "restore to window" glyph.

(In reply to comment #18) > >Note that bug 206544 has landed. > > This is kind of the equivalent of the window controls on Windows (minimize, > restore down, close), so while redundant (if the user has added the full screen > button), I think we probably need to include the OS X standard "restore to > window" glyph. I said that because the potential existence of the customizable fullscreen button should be kept in mind in this bug (see comment 10). Perhaps that button should in fact be implemented in this bug. Bug 206544 excluded OS X, as there's no icon.

Comment on attachment 394425 [details] [diff] [review] fix v1 >+#fullscreen-button[disabled="true"] { >+ -moz-image-region: rect(23px, 787px, 46px, 751px); >+} It won't be disabled, so please don't add this here. We avoided this in winstripe as well. Can you combine #fullscreen-button[checked="true"] and #restore-button?

(In reply to comment #22) > Can you combine #fullscreen-button[checked="true"] and #restore-button? I meant grouping them, as they use the same image regions.

Not sure what's the difference between combining and grouping, but sharing the declaration between those two selectors is a good idea ;-) Who can review the shortcut key / entity stuff?

This also hides the standard fullscreen button while in fullscreen mode, which feels like the right thing to do.

Comment on attachment 395725 [details] [diff] [review] v3 wrong patch

indeed

Comment on attachment 395796 [details] [diff] [review] v3 >+#navigator-toolbox[inFullscreen="true"] #fullscreen-button { >+ display: none; >+} Rather than removing the button that the user put on the toolbar, we should probably remove the restore button, e.g. using #fullscreen-button ~ #window-controls > #restore-button

(In reply to comment #24) > Who can review the shortcut key / entity stuff? I can review it, Alex can ui-review.

Comment on attachment 395796 [details] [diff] [review] v3 Alex, is Accel+Shift+F the right keyboard shortcut?

>Alex, is Accel+Shift+F the right keyboard shortcut? Well, not totally sure. We've mapped accel-F to find (consistent with Safari), although the more common convention on OS X for full screen is accel-f. Either way we should pick up F11 just for consistency with Windows. Let's go with accel-shift-f for now, and if we later decide that full screen is more important than find (and we want to break the muscle memory of our current user base), we can consider swapping them.

Comment on attachment 397797 [details] [diff] [review] v4 What about F11? >+#navigator-toolbox[inFullscreen="true"] #fullscreen-button ~ #window-controls > #restore-button { >+ display: none; > } #navigator-toolbox[inFullscreen="true"] is unnecessary.

Comment on attachment 398079 [details] [diff] [review] v5 > #fullscr-toggler { > display: none; >- min-height: 5px; >+ min-height: 5px !important; Any reason why min-height in toolbar.css is !important? I'd prefer removing it there. >+#minimize-button, >+#close-button { >+ display: none; > } > >+#fullscreen-button ~ #window-controls > #restore-button { >+ display: none; > } #minimize-button, #close-button, #fullscreen-button ~ #window-controls > #restore-button { display: none; }

We shouldn't use F11 on OS X to switch into fullscreen mode. It collides with the system wide shortcut for showing the desktop. In a default configuration this shortcut will be useless. Shall I file a new bug to get this shortcut removed?

(In reply to comment #37) > In a default configuration this shortcut will be useless. It won't hurt either.

I'll have to check some of our Litmus tests.

(no longer needs approval as it's a blocker, so please land on 1.9.2 ASAP)

Verified fixed on trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20090908 Minefield/3.7a1pre ID:20090908030622 As given by Markus he will write automated tests. So flipping the flag.

Verified fixed on 1.9.2 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a2pre) Gecko/20090921 Namoroka/3.6a2pre ID:20090921034459. Markus, on which bug we cover the toolbar button? Bug 206544? It's still missing.

(In reply to comment #43) > Markus, on which bug we cover the toolbar button? Bug 206544? It's still > missing. The updated Toolbar.png which was created in bug 494927 hadn't landed on 1.9.2 yet. I hadn't thought about that, so thanks for noticing! It will hopefully be fixed in the next nightly.

Yeah, looks good now with todays nightly Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1pre) Gecko/20090922 Namoroka/3.6b1pre ID:20090922041132

On a fresh mozilla-central trunk, on OS X, when I put focus on the video and try command-shift-f it just puts FF into full screen browse mode. I made sure focus was on the video. Does this happen for anyone else?

Oh sorry I thought this was about full screen video.

I have updated existing Litmus tests to cover the shortcut and the menu entry.

Removing relnote

user-doc-complete https://support.mozilla.com/en-US/kb/Navigation+Toolbar+items

Shouldn't the command Cmc+Shift+F be in the menu View after option Full screen? Most users will press command F but that is search...

(In reply to comment #51) > Shouldn't the command Cmc+Shift+F be in the menu View after option Full screen? It should, and for me it is. If you don't see it please file a new bug.

(In reply to comment #52) > (In reply to comment #51) > > Shouldn't the command Cmc+Shift+F be in the menu View after option Full screen? > It should, and for me it is. If you don't see it please file a new bug. Hmmm... :( Even with all add-ons disabled it isn't there... So reset the toolbars in Firefox and there it was I will not file a new bug, because it could be a corrupted file after testing something And if this is only for me, I think no one else here has it, it is not worth a bug

Comment on attachment 398079 [details] [diff] [review] v5 >+#minimize-button, >+#close-button { >+ display: none; The buttons will mysteriously reappear when you install a 3rd-party theme...

What 3rd-party theme, for example? Do you know why it happens?

Because theme code hides them.

Oops, I misread that as "3rd-party extension"... Neil, if you think it's worth fixing, please file a bug about it, but I don't think it's going to be much of a problem. The buttons should work, they'll just look non-native. But that's what you get when you use a 3rd-party theme.