1951296 - Nightly moves windows up after restart and reduces the height of maximum height windows

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[B.J. Herbison]

For while Nightly has been changing the size and location of windows on restart.

Steps to reproduce:

1. Create and launch new profile. Move the window to touch the bottom of the screen.
2. Restart Firefox.
3. Create a maximum height (touching top and bottom) but not maximized window.
4. Restart Firefox.

Expected:
2&4) The window returns with the same size and position.

Actual:
2) The window appears in the same place as before, but then the whole window jumps up a few pixels.
4) The window appears in the same place as before, but then the bottom jumps up a few pixels shortening the window.

Using Ubuntu 24.04.2 LTS with XFCE.

This issue was reported on February 19th by jonzn4SUSE in the #Nightly room in the Matrix. Aryx responded and asked for the bug report to mention bug 1946184 in See Also.

Later jonzn4SUSE said the issue was resolved by Firefox Refresh. I still see the issue in a new profile and after a refresh in the new profile.

I have not identified the regression with Mozregression. I'm currently traveling and when I attempted Mozregression it was taking about five minutes for each 1% of a build download.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

I couldn't reproduce on a clean profile on either XFCE, Gnome, or KDE (on X11). This bug is moot on Wayland I believe because we can't control the window position there.

Comment 2

[B.J. Herbison]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

I couldn't reproduce on a clean profile on either XFCE, Gnome, or KDE (on X11). This bug is moot on Wayland I believe because we can't control the window position there.

I modified my XFCE configuration -- I have a panel at the top but removed the panel at the bottom. If your reproduction attempt includes a panel at the bottom that might be why you don't see the issue.

jonzn4SUSE reproduced the issue with KDE and reported bug 1951324.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

I guess the important thing is having the titlebar checkbox checked. Can you confirm you also have it?

Comment 4

[B.J. Herbison]

I don't have Title Bar checked in configure. I don't have Menu Bar checked either. (Both of these settings are the same in my regular profile and in the unconfigured profile I created to reproduce this issue.)

Comment 5

[B.J. Herbison]

I found a place where I could use my phone as a hot spot. Mozregression:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ff5432cc7e7c0d223330a7c8f09a89d797793f83&tochange=9efb94e533503b0cd1309c16d01d488a69941059

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1951296 - Account for uneven client margins in nsWindow::GetScreenEdgeSlop(). r=stransky

Return the larger of the two margins.

Some themes have a bigger bottom vs. top shadow, and without this change
session restore may incorrectly try to move the window up so that it's
in view.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9dccaec9a915
Account for uneven client margins in nsWindow::GetScreenEdgeSlop(). r=stransky

Comment 8

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/9dccaec9a915

Comment 9

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

Set release status flags based on info from the regressing bug 581863

Comment 10

[B.J. Herbison]

The fix worked. I can no longer reproduce this issue with 138.0a1 Build ID 20250304094020.

Comment 11

[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-firefox137 to wontfix.

For more information, please visit BugBot documentation.

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Comment on attachment 9469377 [details]
Bug 1951296 - Account for uneven client margins in nsWindow::GetScreenEdgeSlop(). r=stransky

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: comment 0
• 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 13

[Pascal Chevrel:pascalc]

Comment on attachment 9469377 [details]
Bug 1951296 - Account for uneven client margins in nsWindow::GetScreenEdgeSlop(). r=stransky

-> 137 beta 3, thanks.

Comment 14

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/c7b5d3c1371a

Comment 15

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Reproduced the issue with Firefox 137.0b2 by following steps from comment 0 on Ubuntu 24.04 LTS Xfce. After step 2, the Firefox window will shift upward, creating space at the bottom, and after step 4, it will become shorter, leaving space at the bottom.
The issue is verified fixed with 138.01 (2025-03-06) and 137.0b3 (comment 14). Firefox will no longer shift upward after step 2 and it will not be shorter after step 4.
However, after a restart, sometimes the Firefox window is initially shown to a different location and then is moved to the correct position. This happens fast. Is this expected behavior, or should we file a new issue for it?

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Could be good to get on file specially if you can find a regression range, but probably relatively low priority.