The default bug view has changed. See this FAQ.

new windows spawned from a full-screen window should be normal windows not in an in-between state

RESOLVED FIXED in mozilla7

Status

()

Core
XUL
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: fryn, Assigned: jimm)

Tracking

({regression})

Trunk
mozilla7
regression
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(1 attachment)

fix
1.58 KB, patch
neil@parkwaycc.co.uk
: review+
Details | Diff | Splinter Review
(Reporter)

Description

6 years ago
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.
I think we actually don't want sizemode="fullscreen" there, it should just be a normal window.
(Reporter)

Comment 2

6 years ago
(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.
Summary: in full-screen mode, opening new windows should be handled gracefully → new windows spawned from a full-screen window should be normal windows
(Reporter)

Updated

6 years ago
blocking2.0: --- → ?
Summary: new windows spawned from a full-screen window should be normal windows → new windows spawned from a full-screen window should be normal windows not in an in-between state
blocking2.0: ? → -
Keywords: polish, ux-consistency
(would approve a patch, though, most likely!)

Updated

6 years ago
Duplicate of this bug: 636779

Updated

6 years ago
Duplicate of this bug: 641359

Updated

6 years ago
Component: General → Widget: Win32
Product: Firefox → Core
QA Contact: general → win32
(Assignee)

Updated

6 years ago
Assignee: nobody → jmathies
(Reporter)

Updated

6 years ago
Keywords: ux-consistency
(Assignee)

Comment 6

6 years ago
regression range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f93c5678d642&tochange=8f1c39add00f
(Assignee)

Comment 7

6 years ago
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.
Assignee: jmathies → nobody
Component: Widget: Win32 → DOM
Keywords: polish → regression
QA Contact: win32 → general
browser.xul sets persist="screenX screenY width height sizemode". This wasn't supposed to persist fullscreen mode. Bug 484488 changed this.
(Assignee)

Comment 9

6 years ago
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.
(Assignee)

Comment 10

6 years ago
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. :/
(Assignee)

Comment 11

6 years ago
Created attachment 535410 [details] [diff] [review]
fix
Assignee: nobody → jmathies
(Assignee)

Updated

6 years ago
Attachment #535410 - Flags: review?(neil)

Updated

6 years ago
Component: DOM → XUL
QA Contact: general → xptoolkit.widgets
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.
Attachment #535410 - Flags: review?(neil) → review+
(Assignee)

Comment 13

6 years ago
http://hg.mozilla.org/mozilla-central/rev/1388b00e8b64
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
Target Milestone: --- → mozilla7
You need to log in before you can comment on or make changes to this bug.