517379 - restarting after quit from fullscreen presents fullscreen window with wrong controls

Status: RESOLVED DUPLICATE of bug 575195

(Firefox :: General, defect, P2)

Description

[Karl Tomlinson (:karlt)]

STR:
1. With one tab in a single Firefox window, View -> Full Screen.
2. Quit by clicking on the close box in the urlbar.
3. Start Firefox again.

Expected results:
Probably a window with decorations, perhaps maximized.
Possibly a fullscreen window with fullscreen controls and "Full Screen" checked in the View menu.

Actual results:
A fullscreen window with normal toolbars, and "Full Screen" unchecked in the View menu.
Trying to check "Full Screen" in the View menu exits fullscreen mode.

Comment 1

[Doug Turner (:dougt)]

probably my regression.  we did this on linux:

https://bug512575.bugzilla.mozilla.org/attachment.cgi?id=396836

Comment 2

[Markus Stange [:mstange]]

This kind of stuff feels like it should be shared in nsBaseWidget.

Comment 3

[Karl Tomlinson (:karlt)]

Regression from http://hg.mozilla.org/mozilla-central/rev/ac92849658c3.
Bug 512529 comment 2 was also caused by that.
(http://hg.mozilla.org/mozilla-central/rev/8dc97b8f087f helped some of the other issues.)

Comment 4

[Karl Tomlinson (:karlt)]

Looks like we shouldn't return early here if GDK_WINDOW_STATE_FULLSCREEN has
changed:
http://hg.mozilla.org/mozilla-central/annotate/7d0c4369c0d1/widget/src/gtk2/nsWindow.cpp#l3252
Maybe the changes in Bug 512575 won't even be needed with that sorted.

Comment 5

[Karl Tomlinson (:karlt)]

(In reply to comment #4)
> Looks like we shouldn't return early here if GDK_WINDOW_STATE_FULLSCREEN has
> changed:
> http://hg.mozilla.org/mozilla-central/annotate/7d0c4369c0d1/widget/src/gtk2/nsWindow.cpp#l3252

I tried that (attachment 411575 [details] [diff] [review]) but it's not the (whole?) solution.

I don't know if this is really a Widget bug even.  (Either it's not or I don't know what Widget is meant to do.)

Comment 6

[Karl Tomlinson (:karlt)]

On MS Windows, the browser starts in normal size mode but the size covers the whole desktop.  That's not right either, but quite different.

Comment 7

[Karl Tomlinson (:karlt)]

nsGlobalWindow::SetFullScreen() dispatches a "fullscreen" event.
I'm guessing that delayedStartup in browser/base/content/browser.js has not yet been called to register the event listener, and var FullScreen doesn't seem to get initialized based on the value of window.fullScreen.

Product -> Firefox.

Comment 8

[Karl Tomlinson (:karlt)]

blocking1.9.2+ -> blocking-firefox3.6

Comment 9

[Dietrich Ayala (:dietrich)]

(In reply to comment #7)
> nsGlobalWindow::SetFullScreen() dispatches a "fullscreen" event.

that's dispatched here it looks like:

http://mxr.mozilla.org/mozilla-central/source/xpfe/appshell/src/nsXULWindow.cpp#1188

would moving registration for that even to the xul window's onload be early enough?

Comment 10

[Dietrich Ayala (:dietrich)]

WANT. but not a blocker, would accept low-risk fix.

Comment 12

[Jim Mathies [:jimm]]

related: windows bug 575195. The browser.js patch there might fix this bug if linux's widget is sending a size mode event from Makefullscreen.

Comment 13

[Jim Mathies [:jimm]]

(In reply to comment #12)
> related: windows bug 575195. The browser.js patch there might fix this bug if
> linux's widget is sending a size mode event from Makefullscreen.

oh, and it would need the xpfe patch as well.

Comment 14

[Karl Tomlinson (:karlt)]

Fixed by bug 575195.  Thank you!