684628 - Transition effect when moving to DOM full-screen mode

Status: RESOLVED DUPLICATE of bug 1160014

(Core :: General, defect)

Description

[Chris Pearce [:cpearce (Not reading bugmail)]]

We need some sort of transition effect when moving into DOM full-screen mode, so that it's obvious what's happening. We need to expand the requested full-screen element to encompass the entire viewable area.

The "you've entered full-screen" warning which we'll add in bug 684625 needs to be displayed throughout this transition.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There are lots of ways to do this and choosing a good one is going to be tricky. Here are some requirements:
-- A video playing in the page should scale smoothly out to fill the screen. Video rendering preserves aspect ratio and the aspect ratio should be preserved during the transition.
-- We don't want to have to establish "separate views" for a document or parts of a document. We can take static snapshots of parts of documents though.

A key question is when the content enters fullscreen mode --- i.e. the fullscreen CSS apply and the fullscreenchanged event fire: at the beginning of the transition, or the end of the transition?

When the content enters fullscreen mode, the content window should be sized to the screen size, so that scripts that try to size canvases etc to the window size work. So if we have the browser chrome sliding away, either we need to make it overlay the content window or we need to enter fullscreen mode after the browser chrome has gone.

I guess the most important question is: what should the UX be? Browser window goes full-screen instantly, as now? Browser window stays where it is while a snapshot of the element zooms out to cover the screen? Lots of other options.

Comment 2

[Justin Dolske [:Dolske]]

I bet our UX team may have an opinion! ;)

A zoom effect seems most logical to me. Might be worth considering some of the lessons-learned from Panorama, since they spent a lot of time working on getting a smooth zoom when selecting a tab.

Also, it's not just the browser chrome going away, but it's other stuff on the OS desktop as well.

Some other random thoughts:

* It would be /nice/ for the content (especially <video>) to be live during the brief transition interval. Required? Dunno, might depend on performance.

* What effect to apply to the rest of the screen not being zoomed? Maybe fade to black? A selectable color? Average color of the zooming region?

* Maybe first build a simple HTML-based prototype to play with how potential transitions effects might look? Steven's done this kind of thing for chrome UI in the past...

* Would it be easy to have a pref controlling if this API zooms to full-screen or just full-tab? Could be useful for security-paranoid folks, or as a way to nerf the feature without disabling it entirely, if there's some security angle that's been over looked. OTOH, since we already expose information about screen size and coordinates to content, sites would inevitably code with full-screen assumptions and full-tab wouldn't work right. :(

* What should happen on multi-monitor setups? (Specifically, to the screen the browser isn't on).

* What should happen on mobile devices without hardware home/back keys? How can the user call up the keyboard or exit FS mode?

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Justin Dolske [:Dolske] from comment #2)
> * Would it be easy to have a pref controlling if this API zooms to
> full-screen or just full-tab? Could be useful for security-paranoid folks,
> or as a way to nerf the feature without disabling it entirely, if there's
> some security angle that's been over looked. OTOH, since we already expose
> information about screen size and coordinates to content, sites would
> inevitably code with full-screen assumptions and full-tab wouldn't work
> right. :(

I think that would be relatively easy. Not sure if it's worth building in from the beginning. Not really relevant to this bug.

> * What should happen on multi-monitor setups? (Specifically, to the screen
> the browser isn't on).

Nothing, I guess.

> * What should happen on mobile devices without hardware home/back keys? How
> can the user call up the keyboard or exit FS mode?

Again, not really relevant to this bug. But extremely relevant to bug 688082!

Comment 4

[Jennifer Morrow [:Boriss] (UX)]

This has been fixed since the filing of the bug - the current window scales in size while the contents fade to its expanded view.  The rest of the OS shifts to the background. It's sexy!

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

Are you referring to the use of the OSX Lion Full Screen APIs from Bug 639705? I don't see any such animation on [Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120127 Firefox/12.0a1], and obviously can't use the Lion APIs on non Lion platforms...

Comment 6

[Jennifer Morrow [:Boriss] (UX)]

(In reply to Chris Pearce (:cpearce) from comment #5)
> Are you referring to the use of the OSX Lion Full Screen APIs from Bug
> 639705? I don't see any such animation on [Mozilla/5.0 (Windows NT 6.1;
> WOW64; rv:12.0a1) Gecko/20120127 Firefox/12.0a1], and obviously can't use
> the Lion APIs on non Lion platforms...

Aw, too good to be true.  As Roc points out in Comment 1, there's a few ways to skin this cat.  One thing Lion does is fade the content to white in the smaller size and fade it in again at the fullscreen size.  It avoids the problem of scaling content pretty well.  Could we mimic this type of motion for other platforms?

Comment 8

[Thomas Stache]

dupe-of or fixed-by bug 1160014?