With bug 639705's changes we now play two animations when a video or a DOM element is going full-screen (assuming we don't hit bug 726943): 1) First the standard Lion animation -- the browser window is moved to a separate space, maximized, the menu and title bars are hidden. 2) Then the toolbars are hidden and the video is truly full screen. This is worse than our previous behavior - it takes more time and looks less polished, for this reason I'm filing this as a separate issue (since there's a more general bug 684628) and asking for tracking-firefox14. Both our competitors perform better in this case: - Safari creates a fullscreen window on the same space as the browser window, without using the Lion's effect. - Chrome uses the Lion animation, but it doesn't have any chrome in full-screen, so there's no need for transition #2.

(In reply to Nickolay_Ponomarev from comment #0) > Both our competitors perform better in this case: > - Safari creates a fullscreen window on the same space as the browser > window, without using the Lion's effect. > - Chrome uses the Lion animation, but it doesn't have any chrome in > full-screen, so there's no need for transition #2. I haven't actually seen Safari have a working DOM fullscreen & I'd actually say Chrome's isn't great either. They transition the document to fullscreen (with chrome hidden) and then the element is made fullscreen. But that's not really the point here :) I agree that we're not perfect. I think we get the domfs event first (though it's async so maybe not?)... maybe we can hide more chrome then before the "fullscreen" event goes through (after the transition). I thought we were already doing that though, so perhaps we can do something on mozfullscreenrequested (I think that exists).

Re: safari -- try joining the HTML5 trial on youtube <http://www.youtube.com/html5> and watching an HTML5-enabled video, like http://www.youtube.com/watch?v=siOHh0uzcuY Re: better -- I meant they make fewer transitions than we do (which isn't actually true for Chrome as I now see.. it just felt less weird). Anyway, the point of filing this bug was to point out that the current Lion fullscreen transition is (IMHO, and I hope this is obvious) less useful for video than what we used to do before.

I see two basic options that could be implemented here, maybe this needs input from UI? - Use Lion fullscreen: open fullscreen video on a separate space, but hide chrome and make the video fullscreen "during" the animation (I'm not sure how it could be implemented, but chrome does the first half of this somehow). - Go fullscreen the old way: on the same space (that's what Safari, VLC, and the Flash player all do) Note: VLC initially shipped with Lion full-screen, which was reverted because a fullscreen app can't be on a secondary monitor -- http://trac.videolan.org/vlc/ticket/6096 )

On the technical side, if we go with the Lion fullscreen option, note that executing this code in chrome scratchbox: FullScreen.toggle = function(event) { // called on the "fullscreen" event document.getElementById("navigator-toolbox").collapsed = true; } ...makes video transition to fullscreen in one go (breaking everything else, but that's not the point). So it seems like the problem is in showXULChrome() somewhere.

Tracking for 14 to keep this on our radar, although it's doubtful we'd consider backing out bug 639705 if this was left unfixed.

[Triage Comment] Moving this over to Dolske now that Paul has left, Dolske can you give a status update as to the priority of this issue and whether it's something worth tracking for FF14?

(In reply to Lukas Blakk [:lsblakk] from comment #6) > [Triage Comment] > Moving this over to Dolske now that Paul has left, Dolske can you give a > status update as to the priority of this issue and whether it's something > worth tracking for FF14? Honestly, it's not that bad. This feels to me like much more of a polish bug that would be nice, but is far from necessary for the feature to work.

(In reply to Paul O'Shannessy [:zpao] from comment #7) > Honestly, it's not that bad. This feels to me like much more of a polish bug > that would be nice, but is far from necessary for the feature to work. Given where we are in the cycle, I have to agree - this is polish.

Yeah, polish. /cc limi to see if UX wants to track it.

Can't simply both animations be combined so they run at the same time? Safari BTW has integrated the Fullscreen API now, and they are not opening a new space when enlarging DOM elements (tested in Safari 6.0.5 on Mac OS X 10.8.4 via http://html5-demos.appspot.com/static/fullscreen.html). I always thought that first entering App Fullscreen mode for fullscreen-ing an element is odd, so I'd like to see Firefox following Safari's approach.