Currently, the fullscreen api code highly depends on the fullscreen mode. We should separate them into independent parts.

We can display fullscreen document in an independent fullscreen window, so that users can switch between the fullscreen window and other tabs without exiting the fullscreen. Also, it could solve the current interaction problem between the Fullscreen API and our fullscreen mode. The tab in the original window could display a "Exit Fullscreen" button to replace the document in fullscreen like Safari on Mac. I guess this may need UX review, but I have no idea how to request for such review. Should I do that before or after implementing this?

That's how Flash Player does fullscreen and allow browser interaction on the second screen. I think we want that feature. We're working on getting a UX designer soon but I'd like to see how using an independent window lets us animate more smoothly even with our current UI. +cc: mattwoodrow who had ideas about that

Hmm, but once the fullscreen window of Flash gets blurred, it is closed immediately, which I don't think is what we want for fullscreen api. The first thing I want to solve by using an independent screen is bug 947854, and then investigate about the transition on Mac. The effect I intend to impl on Mac is, zooming the document area out to fullscreen (not the element like Safari, because per spec, the background document are not necessarily invisible). This itself cannot make us animate more smoothly, but we can extend the viewport in advance to prevent reflow inside page. Actually, on Mac, now the system paints the transition for us, which is smoothly. The problem is that, the system blocks our painting during the transition. We can simply add custom fullscreen animation methods to the cocoa window to make the system not block us, but that would cause a bunch of reflow because of resizing.

roc thinks there is probably too much work to hack in Firefox UI code for doing this, and it is not necessary to do so for any effect. It is possible to implement either zooming or fade-to-black without having a separate fullscreen window. Also, it wouldn't be easier to implement this bug than to fix bug 947854 directly. The only downside not having this bug be implemented is that, the user will continue not to be able to access other tab in the same window when one is in fullscreen.