This is targeted at a future release. Currently transitioning to full screen is a pretty jarring experience, at least on Windows. The normalized window & content get 'trapped' in the center of the window until a reflow takes place, then the whole window refreshes. It would be nice if the transition was seamless. Chrome does a nice job of this by hiding the window temporarily while transitioning.

This briefly hides the window when going into full screen. The user experience is much improved, although there is a focus problem where the full screen browser falls into the background.

This fixes the focus problem.

Comment on attachment 512793 [details] [diff] [review] WIP v.2 Looks OK. I assume that this isn't code that a script on a page in a non-active window can invoke?

Doesn't appear to. Full screen popups are just large normalized windows.

Comment on attachment 512793 [details] [diff] [review] WIP v.2 r=me

Is this ready for landing?

Linux x86_64: Now FF window keeps its size when pressing F11 (no change to fullscreen).

(In reply to comment #8) > Linux x86_64: > Now FF window keeps its size when pressing F11 (no change to fullscreen). Hmm, the window size and position changes don't take effect at all?

Assuming this did cause a problem on unix systesm, maybe this should be a Windows specific change.

Comment on attachment 522357 [details] [diff] [review] ifdef it If we're going to do that, shouldn't the relevant show/hide bits just live in the widget implementation?

(In reply to comment #11) > Comment on attachment 522357 [details] [diff] [review] > ifdef it > > If we're going to do that, shouldn't the relevant show/hide bits just live in > the widget implementation? Possibly if I get get the window focus parts working right. I'll take a look.

Jim asked me to back out this patch, so I did: http://hg.mozilla.org/mozilla-central/rev/34e990f456dd

This works just as well with the added win of being able to remove the code for bug 575855.

There is weird fullscreen behavior now when fullscreening a maximized window. It seems like its detecting my screen size improperly and not expanding to the maximum size. The fullscreened window is about the size of what the window would be if it was un-maximized. This does not happen when fullscreening from a non-maximized window.

(In reply to comment #16) > There is weird fullscreen behavior now when fullscreening a maximized window. > It seems like its detecting my screen size improperly and not expanding to the > maximum size. The fullscreened window is about the size of what the window > would be if it was un-maximized. > > This does not happen when fullscreening from a non-maximized window. Yeah, that's bug 646067, which was already fixed today. It will be in tomorrow's nightly.

Jim, when I click f11 for full-screen, I see the entire Firefox window disappear and the window behind peaks through for some milliseconds. Is this the expected behavior with this patch?

(In reply to comment #18) > Jim, when I click f11 for full-screen, I see the entire Firefox window > disappear and the window behind peaks through for some milliseconds. Is this > the expected behavior with this patch? Yeah. Jim commented on this in bug 646067 comment 6.

If user's don't like we can always flip it back, it's purely a cosmetic change. I feel the transition is better myself.

Jim, is there anything we can do to shorten the length of time that the window is gone? Could we "mask" that space in time with blank content so that the background windows don't show through? (I'm not saying it's not better this way. It might be.)

(In reply to comment #0) > Currently transitioning to full screen is a pretty jarring experience, at least > on Windows. The normalized window & content get 'trapped' in the center of the > window until a reflow takes place, then the whole window refreshes. It would be > nice if the transition was seamless. My impressing is that we already get a basic OS-provided transition on maximising the window. Could we hook into that by temporarily maximising the window before going full screen? Alternatively is there an issue that layout won't try to bitblt the existing content area to its new location? I guess widget removal exacerbated this.

(In reply to comment #22) > (In reply to comment #0) > > Currently transitioning to full screen is a pretty jarring experience, at least > > on Windows. The normalized window & content get 'trapped' in the center of the > > window until a reflow takes place, then the whole window refreshes. It would be > > nice if the transition was seamless. > My impressing is that we already get a basic OS-provided transition on > maximising the window. That's handled in the WM_NCCALCSIZE event. You define an area of the window that will be moved to a certain location of the screen. But if we reflow and repaint everything, it doesn't afford you anything. > Could we hook into that by temporarily maximising the > window before going full screen? That would be troublesome in widget where we track the current window state based on the events we receive from Windows. But I suppose you could do something like that with direct calls to ShowWindow in MakeFullscreen in combination with a "in full screen transition" flag peppered about. > > Alternatively is there an issue that layout won't try to bitblt the existing > content area to its new location? I guess widget removal exacerbated this. I don't have time to debug this at the moment but I believe this triggers a full reflow up in nsDocumentViewer / nsPressShell for the view.

Is it still true that hiding and showing the window in a short period is a good transition? I tried to remove those code, and didn't see anything goes much worse. Currently, I intend to add Win key as a shortcut to exit DOM fullscreen on Windows, as a response to bug 1140819. But it seems that, with this hide & show, it is impossible to gain the focus after user returns to the desktop from the start screen. Also given this procedure directly causes bug 649067, bug 646374, and bug 1053783, I intend to remove the related code. Would you mind me to do that?

(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #24) > Is it still true that hiding and showing the window in a short period is a > good transition? > > I tried to remove those code, and didn't see anything goes much worse. > > Currently, I intend to add Win key as a shortcut to exit DOM fullscreen on > Windows, as a response to bug 1140819. But it seems that, with this hide & > show, it is impossible to gain the focus after user returns to the desktop > from the start screen. > > Also given this procedure directly causes bug 649067, bug 646374, and bug > 1053783, I intend to remove the related code. Would you mind me to do that? I'm open to trying to improve this what we do here. Please post a patch, I'll be happy to test it and report anything odd that I see.

(In reply to Xidorn Quan [:xidorn] (UTC+12) from comment #26) > Created attachment 8593045 [details] [diff] [review] > backout patch I'm still not convinced this is a better experience, but if a majority demand a backout, I'd be happy to acquiesce. I think we should file a fresh bug and discuss there. Neither transition is perfect. Current mc doesn't paint content twice. Both cases have ugly but brief frame related issues, although current mc is better at this imo. Mc also has the problem of reordering on the taskbar which I guess causes some users pain, personally I never notice it. Is there some compelling reason we want to back this out that I'm missing?

Could you provide a try build to compare Fullscreen transition behavior?

(In reply to Alice0775 White from comment #28) > Could you provide a try build to compare Fullscreen transition behavior? sure!

(In reply to Jim Mathies [:jimm] from comment #27) > Is there some compelling reason we want to back this out that I'm missing? I intend to add Win key as a shortcut to exit DOM fullscreen on Windows, as a response to bug 1140819. But it seems that, with this hide & show, it is impossible to gain the focus after user returns to the desktop from the start screen.

(In reply to Jim Mathies [:jimm] from comment #30) > https://treeherder.mozilla.org/#/jobs?repo=try&revision=e883a260df0d Except Bug 646374, I do not notice any difference between the try build and Nightly. https://hg.mozilla.org/try/rev/e883a260df0d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 ID:20150416131443

However, on Windows10TP slow machine without HWA, the try build seems to be better than Nightly. On Nightly build, Browser disappear and reappear when I toggle fullscreen. On Try build, Transition seems to smooth. https://hg.mozilla.org/try/rev/e883a260df0d Mozilla/5.0 (Windows NT 10.0; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 ID:20150416131443

(In reply to Alice0775 White from comment #33) > However, on Windows10TP slow machine without HWA, the try build seems to be > better than Nightly. > On Nightly build, Browser disappear and reappear when I toggle fullscreen. > On Try build, Transition seems to smooth. > > https://hg.mozilla.org/try/rev/e883a260df0d > Mozilla/5.0 (Windows NT 10.0; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 > ID:20150416131443 Really? Using the try build on a low power tablet I see window frame rendering problems during the transition. I'm not convinced but like I said I'm not attached to either solution. I'll r+ this patch and let Xidorn make the call. I don't use browser fullscreen or maximized windows at all so I'm probably not the best person to judge.

(In reply to Jim Mathies [:jimm] from comment #34) > (In reply to Alice0775 White from comment #33) > > However, on Windows10TP slow machine without HWA, the try build seems to be > > better than Nightly. > > On Nightly build, Browser disappear and reappear when I toggle fullscreen. > > On Try build, Transition seems to smooth. > > > > https://hg.mozilla.org/try/rev/e883a260df0d > > Mozilla/5.0 (Windows NT 10.0; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0 > > ID:20150416131443 > > Really? Using the try build on a low power tablet I see window frame > rendering problems during the transition. > I think you hit bug 1155489 and bug 1155494, now it is problematic to toggle fullscreen w/ e10s.

(In reply to Jim Mathies [:jimm] from comment #34) > Really? Using the try build on a low power tablet I see window frame > rendering problems during the transition. Before I ask for the formal review, I want to confirm what problem do you see during the transition. In my machine, the resizing happens immediately, and there could be some rendering problems in a flash, but this happens to me for nightly, too. But while you insist that nightly is a lot better than the try build with the backout patch, I wonder whether you are seeing something different. Is there any transition on your machine which makes the resizing not happen instantly, so that you can see a significantly less ideal effect? Could you provide a screencast for the problem you see?

You should reach out to QA and have them test both options looking for the best fix across multiple os and screen configs. I will try to get to this but setting this up takes time which I don't have much of right now.

Hmm, as part of bug 1160014, I think we definitely should backout this change then, because: 1. it would be unnecessary then as we will use black screen to cover the window while turning into fullscreen; 2. this hide-show step takes around 200ms more comparing to directly going to fullscreen in my debug build. I would probably backout it in bug 1161802.

I don't have time to test this, you should get with QA.