1934238 - Window position incorrect wnen restore size-mode to normal from maximized after relanch

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[Alice0775 White]

This problem occurs every time when exiting Firefox in maximized size-mode.

Steps to reproduce:

1. Create New profile
2. Run firefox.exe without any command line options
3. Reduce browser size and move to center of screen (To make it easier to check for bugs)
   And remember the browser position
4. Maximize the browser
5. Exit the browser
6. Run firefox.exe again without any command line options
7. Restore size-mode

Actual results:
Browser moves to the upper left corner of the screen and the top part goes off-screen.
Screencast: https://youtu.be/0DMK8DH5tow

Expected results:
The browser is positioned as remembered in step 3.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=45ed66ca8512ae779333dab919d7d365757eaf4c&tochange=ae53bce6521b13768eb4aba4a62b7bffd40174e2

Workaround:
Set browser.startup.blankWindow to false in about:config
OR
Launch with command line option, i.e., firefox.exe -p

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:emilio, since you are the author of the regressor, bug 1922250, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

So I see a LoadPositionFromXUL call from the early blank window and nothing from session restore.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1934238 - Don't try to position anything from XUL if the widget is not in the normal sizemode. r=rkraesig

The relevant MoveTo() call is:

MoveTo(-22, -22)

From the window.stop() call in:

0 _earlyBlankFirstPaint(cmdLine = "[xpconnect wrapped nsICommandLine @ 0x1f793cbfe20 (native @ 0x1f794f4a800)]") ["resource:///modules/BrowserGlue.sys.mjs":1860:9]
this = [object Object]
1 BG_observe(subject = "[xpconnect wrapped nsICommandLine @ 0x1f793cbfe20 (native @ 0x1f794f4a800)]", topic = ""app-startup"", data = """") ["resource:///modules/BrowserGlue.sys.mjs":1353:14]
this = [object Object]

Which triggers:

nsWindow::Move (D:\moz\gecko\widget\windows\nsWindow.cpp:1914)
mozilla::AppWindow::MoveResize (D:\moz\gecko\xpfe\appshell\AppWindow.cpp:707)
mozilla::AppWindow::LoadPositionFromXUL (D:\moz\gecko\xpfe\appshell\AppWindow.cpp:1224)
mozilla::AppWindow::SizeShell (D:\moz\gecko\xpfe\appshell\AppWindow.cpp:2501)
mozilla::AppWindow::OnChromeLoaded (D:\moz\gecko\xpfe\appshell\AppWindow.cpp:1084)
mozilla::AppWindow::OnStateChange (D:\moz\gecko\xpfe\appshell\AppWindow.cpp:3071)
nsDocLoader::DoFireOnStateChange (D:\moz\gecko\uriloader\base\nsDocLoader.cpp:1425)
nsDocLoader::doStopDocumentLoad (D:\moz\gecko\uriloader\base\nsDocLoader.cpp:971)
nsDocLoader::DocLoaderIsEmpty (D:\moz\gecko\uriloader\base\nsDocLoader.cpp:785)
nsDocLoader::OnStopRequest (D:\moz\gecko\uriloader\base\nsDocLoader.cpp:667)
nsDocShell::OnStopRequest (D:\moz\gecko\docshell\base\nsDocShell.cpp:13740)
mozilla::net::nsLoadGroup::NotifyRemovalObservers (D:\moz\gecko\netwerk\base\nsLoadGroup.cpp:638)
mozilla::net::nsLoadGroup::Cancel (D:\moz\gecko\netwerk\base\nsLoadGroup.cpp:259)
nsDocLoader::Stop (D:\moz\gecko\uriloader\base\nsDocLoader.cpp:254)
nsDocShell::Stop (D:\moz\gecko\docshell\base\nsDocShell.cpp:4147)
nsGlobalWindowOuter::StopOuter (D:\moz\gecko\dom\base\nsGlobalWindowOuter.cpp:4937)
nsGlobalWindowInner::Stop (D:\moz\gecko\dom\base\nsGlobalWindowInner.cpp:3742)
mozilla::dom::Window_Binding::stop (D:\moz\gecko\obj-debug\dom\bindings\WindowBinding.cpp:2128)

The window is already properly maximized (which can happen with the
pre-skeleton UI), we shouldn't adjust the position of the window.

The reason this worked before my patch was because the skeleton UI
didn't have the right bounds, so the position didn't change.

But I don't think we should move the window at all in this case (I
believe the current patch in bug 1866583 part 4 maybe fix this too, but
it's better to be explicit).

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4b396c6161bb
Don't try to position anything from XUL if the widget is not in the normal sizemode. r=rkraesig

Comment 5

[amarc]

https://hg.mozilla.org/mozilla-central/rev/4b396c6161bb

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox134 to wontfix.

For more information, please visit BugBot documentation.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9440766 [details]
Bug 1934238 - Don't try to position anything from XUL if the widget is not in the normal sizemode. r=rkraesig

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: regression fix
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): One-liner
• String changes made/needed: none
• Is Android affected?: No

Comment 8

[Donal Meehan [:dmeehan]]

:emilio, is this also safe for a release uplift request? We could include it in next week's Fx133 planned dot release.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9440766 [details]
Bug 1934238 - Don't try to position anything from XUL if the widget is not in the normal sizemode. r=rkraesig

I think it probably is, if QA is happy with it.

Comment 10

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Reproduced the issue on Firefox 135.0a1 (2024-11-29) on Windows 11 by following the STR from Comment 0.

The issue is no longer reproducible on Firefox 135.0a1 (2024-12-02) on the same system. Will look over 134/133 once it is uplifted.

Comment 11

[Donal Meehan [:dmeehan]]

Comment on attachment 9440766 [details]
Bug 1934238 - Don't try to position anything from XUL if the widget is not in the normal sizemode. r=rkraesig

Approved for 134.0b5 to get coverage before the 133 dot release.

Comment 12

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/1ced1f998f26

Comment 13

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified that this is fixed as well on Firefox 134.0b5 (Treeherder build) on Windows 11.

Comment 14

[Donal Meehan [:dmeehan]]

Comment on attachment 9440766 [details]
Bug 1934238 - Don't try to position anything from XUL if the widget is not in the normal sizemode. r=rkraesig

Approved for 133.0.3

Comment 15

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/d345d208101a

Comment 16

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified the fix on Firefox 133.0.3 (Treeherder build) on Windows 11.