Last Comment Bug 632748 - new windows spawned from a full-screen window should be normal windows not in an in-between state
: new windows spawned from a full-screen window should be normal windows not in...
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla7
Assigned To: Jim Mathies [:jimm]
:
Mentors:
: 636779 641359 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-09 01:31 PST by Frank Yan (:fryn)
Modified: 2011-05-27 11:01 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
fix (1.58 KB, patch)
2011-05-26 10:57 PDT, Jim Mathies [:jimm]
neil: review+
Details | Diff | Splinter Review

Description Frank Yan (:fryn) 2011-02-09 01:31:55 PST
Currently (Firefox 4 beta 11) in full-screen mode, opening a new window (by pressing accel+N, detaching a tab, etc.) produces a window that is somewhat in full-screen mode but not quite. The |sizemode="fullscreen"| attribute is set, but the toolbars and titlebar are not completely in fullscreen configuration, and on Windows, the window does not fill the screen. We should fix this, so full-screen mode is correctly initialized for the new window.
Comment 1 Dão Gottwald [:dao] 2011-02-09 01:33:49 PST
I think we actually don't want sizemode="fullscreen" there, it should just be a normal window.
Comment 2 Frank Yan (:fryn) 2011-02-09 01:41:49 PST
(In reply to comment #1)
> I think we actually don't want sizemode="fullscreen" there, it should just be a
> normal window.

I'd be okay with that too. It's a bit odd to have a fullscreen window not in the foreground, but it'll do.
Comment 3 Mike Beltzner [:beltzner, not reading bugmail] 2011-02-09 20:44:05 PST
(would approve a patch, though, most likely!)
Comment 4 Dão Gottwald [:dao] 2011-02-25 16:05:11 PST
*** Bug 636779 has been marked as a duplicate of this bug. ***
Comment 5 Dão Gottwald [:dao] 2011-03-14 06:29:36 PDT
*** Bug 641359 has been marked as a duplicate of this bug. ***
Comment 7 Jim Mathies [:jimm] 2011-05-25 07:46:50 PDT
So this doesn't appear to be a widget bug, although I'm not sure where to move it. The window that gets created has it's sizemode attribute set to "fullscreen" despite widget having sent a sizemode = normal event shortly after the window is created. Tabs in titlebar code looks to have regressed the problem but it doesn't look like it's the actual cause, it's just looking at the sizemode attribute and applying the right ui.

Looks like it might be bug in persisted attributes or session restore.

Moving this to DOM for now.
Comment 8 Dão Gottwald [:dao] 2011-05-25 10:28:42 PDT
browser.xul sets persist="screenX screenY width height sizemode". This wasn't supposed to persist fullscreen mode. Bug 484488 changed this.
Comment 9 Jim Mathies [:jimm] 2011-05-26 07:56:10 PDT
The classes in xpfe know the current sizemode of the window. They persist sizemode but update this accordingly when they detect the window isn't in full screen. DOM's global window and global chrome window are also in sync via the code in xpfe. The problem here is that the document (main-window) also persists the size mode, and this is completely out of sync with the real state of the window that contains it.

There are plenty of little hacks we could add in browser.js to get these synced up, but I think the real fix here is to make sure the window syncs the size mode state of the root document during state changes.
Comment 10 Jim Mathies [:jimm] 2011-05-26 10:24:18 PDT
nsXULWindow attempts to persist the state on the doc, but persistence is locked until after chrome is loaded. browser.js receives the resize event before chrome fully loads, so the doc element's sizemode isn't up to date. :/
Comment 11 Jim Mathies [:jimm] 2011-05-26 10:57:37 PDT
Created attachment 535410 [details] [diff] [review]
fix
Comment 12 neil@parkwaycc.co.uk 2011-05-26 14:02:30 PDT
Comment on attachment 535410 [details] [diff] [review]
fix

SeaMonkey doesn't seem to rely on the attribute so I had to manually inspect the window with DOM Inspector to note the attribute was now correct.
Comment 13 Jim Mathies [:jimm] 2011-05-27 08:21:10 PDT
http://hg.mozilla.org/mozilla-central/rev/1388b00e8b64

Note You need to log in before you can comment on or make changes to this bug.