505699 - Need UI to get into and out of fullscreen mode on OS X

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Markus Stange [:mstange]]

Attachment: wip

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.

Comment 1

[Markus Stange [:mstange]]

Attachment: screenshot of appearance with the wip patch (not good)

Comment 2

[Dão Gottwald [:dao]]

(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?

Comment 3

[Markus Stange [:mstange]]

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.

Comment 4

[Stephen Horlander [:shorlander]]

Attachment: Leopard Quicklook Example

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.

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: iPhoto HUD

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.

Comment 7

[Markus Stange [:mstange]]

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?

Comment 8

[Markus Stange [:mstange]]

Attachment: mockup

This is what I mean.

Comment 9

[Dão Gottwald [:dao]]

That looks like bug 206544.

Comment 10

[Markus Stange [:mstange]]

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.

Comment 11

[Asaf Romano (gone)]

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

Comment 12

[Markus Stange [:mstange]]

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?

Comment 13

[Asaf Romano (gone)]

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

Comment 14

[Markus Stange [:mstange]]

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

Comment 15

[Alex Faaborg [:faaborg] (Firefox UX)]

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.

Comment 16

[Markus Stange [:mstange]]

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 ;-)

Comment 17

[Dão Gottwald [:dao]]

Note that bug 206544 has landed.

Comment 18

[Alex Faaborg [:faaborg] (Firefox UX)]

>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.

Comment 19

[Dão Gottwald [:dao]]

(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 21

[Markus Stange [:mstange]]

Attachment: fix v1

Comment 22

[Dão Gottwald [:dao]]

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?

Comment 23

[Dão Gottwald [:dao]]

(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.

Comment 24

[Markus Stange [:mstange]]

Attachment: v2

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?

Comment 25

[Markus Stange [:mstange]]

Attachment: v3

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

Comment 26

[Dão Gottwald [:dao]]

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

wrong patch

Comment 27

[Markus Stange [:mstange]]

Attachment: v3

indeed

Comment 28

[Dão Gottwald [:dao]]

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

Comment 29

[Dão Gottwald [:dao]]

(In reply to comment #24)
> Who can review the shortcut key / entity stuff?

I can review it, Alex can ui-review.

Comment 30

[Dão Gottwald [:dao]]

Comment on attachment 395796 [details] [diff] [review]
v3

Alex, is Accel+Shift+F the right keyboard shortcut?

Comment 31

[Alex Faaborg [:faaborg] (Firefox UX)]

>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 32

[Markus Stange [:mstange]]

Attachment: v4

Comment 33

[Dão Gottwald [:dao]]

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 34

[Markus Stange [:mstange]]

Attachment: v5

Comment 35

[Dão Gottwald [:dao]]

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;
}

Comment 36

[Markus Stange [:mstange]]

http://hg.mozilla.org/mozilla-central/rev/1737ecbfb542

Comment 37

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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?

Comment 38

[Dão Gottwald [:dao]]

(In reply to comment #37)
> In a default configuration this shortcut will be useless.

It won't hurt either.

Comment 39

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 40

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 41

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 42

[Markus Stange [:mstange]]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/583a73c290d5

Comment 43

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 44

[Markus Stange [:mstange]]

(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.

Comment 45

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 46

[David Bolter [:davidb] (NeedInfo me for attention)]

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?

Comment 47

[David Bolter [:davidb] (NeedInfo me for attention)]

Oh sorry I thought this was about full screen video.

Comment 48

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 49

[Mike Beltzner [:beltzner, not reading bugmail]]

Removing relnote

Comment 50

[Chris Ilias [:cilias]]

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

Comment 51

[Maaren]

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...

Comment 52

[Markus Stange [:mstange]]

(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.

Comment 53

[Maaren]

(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 54

[[e-mail]]

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...

Comment 55

[Markus Stange [:mstange]]

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

Comment 56

[Dão Gottwald [:dao]]

Because theme code hides them.

Comment 57

[Markus Stange [:mstange]]

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.