Currently we've assumed that going fullscreen is a synchronous activity and until recently was entirely under our control. With "native" fullscreen for Lion fullscreen and (minimaly) GTK, we're no longer 100% in control of fullscreen and it's not guaranteed the future (or even present) is actually synchronous. I've been working on Lion FS and there are issues that are mostly due to when the "fullscreen" event fires. When toggling FS via our menuitem, we fire the "fullscreen" event before calling MakeFullScreen (https://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#4594). When toggling FS via OS controls, we exit full screen, then fire the event. The discrepancy leads to different visual behavior since we're depending on the fullscreen event to change UI. It looks smooth when the fullscreen event fires before hitting the animation, but when the event fires after the animation, it's very noticeable that the UI is shifting. So I guess I have a couple ideas here: 1. The simplest is to just move when we fire that event in nsGlobalWindow. At least on Lion, that will bring things all into line. While consistent, this is still going to result in ugly transitions. 2. Fire multiple fullscreen* events. This would match more closely what is happening in Cocoa and should allow us to separate work into different stages. fullscreenBegin, fullscreenEnd, fullscreenFail (I also want to specify enter vs exit). I think this is the best path forward. I think DOM FS already works somewhat like this.

I filed bug 741475 which feels related (or equal to) this.

I need this to stem the flood of orange in bug 745047. It looks like our internal nsSizeMode_Fullscreen event handler runs after the transition is complete on MacOSX, so fixing this may fix bug 741475 too.

(In reply to Chris Pearce (:cpearce) from comment #2) > I need this to stem the flood of orange in bug 745047. > > It looks like our internal nsSizeMode_Fullscreen event handler runs after > the transition is complete on MacOSX, so fixing this may fix bug 741475 too. Actually this isn't quite what I need to do to fix the orange. I'll complete my orange-busting work in bug 756334.

No assignee, updating the status.

No assignee, updating the status.

No assignee, updating the status.

No assignee, updating the status.