1981073 - If title bar enabled, then the window shrinks on restore

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect)

Description

[jmdavis]

Steps to reproduce:

1. Create a new Firefox profile and open it.
2. Enable "Open previous windows and tabs" in the general settings.
3. Enable the title bar via "Customize Toolbar..." when right-clicking on the top of the browser window.
4. Resize the browser window to something where it's clear whether it stays the same when the browser is restarted (e.g. lining it up with another window).
5. Close Firefox.
6. Open Firefox again with the same profile.

Actual results:

The bottom of the browser window is now shorter by approximately the height of the task bar, and the right side of the browser window has move to the left by several pixels. The top and left sides appear to be in the same place.

This happens to every browser window in the profile every time that the browser is started again. So, if you don't want your browser windows to shrink over time, you have resize them every time that you open Firefox.

This occurs for me with 140.1.0esr
user agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0

This does not occur for me with 128.11.0esr
Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0

I am using FreeBSD 14 with KDE 6 and X11.

I have also tested this on Debian 12 with KDE 5 and X11, and the results are the same.

141.0
user agent: Mozilla/5.0 (X11; Linux x86_64; rv:141.0) Gecko/20100101 Firefox/141.0

has the problem, whereas

128.13.0esr
user agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0

is fine. So, it looks like something got broken between 128 ESR and 140 ESR.

Expected results:

The browser windows should be exactly the same size in exactly the same position that they were in prior to the browser being closed.

Comment 1

[jmdavis]

Well, I don't know anything about the code, but I figured that I could at least bisect the commits to find where the bug was introduced, and it was this commit:

commit 4eaad99f2b93c078e43b6a4924430b6b32cb5960
Author: Emilio Cobos Álvarez <[e-mail]>
Date:   Mon Feb 3 17:08:44 2025 +0000

    Bug 581863 - Fix nsWindow coordinates to make sense. r=stransky,win-reviewers,rkraesig,devtools-reviewers,ochameau

    I stumbled upon this bug while realizing that some of the math I'm doing
    for PiP windows doesn't work at all on Linux (bug 1934760), because
    screenX != mozInnerScreenX, even though outerWidth == innerWidth.

    I've tested this on X11 and Wayland (plasma and Gnome) with CSD and SSD,
    and in general, this is the same thing Windows does, so should be fine.

    The basic idea is:

     * Keep mBounds being frame manager bounds (so, outer* and screen*),
       relative to mShell.

     * Keep mClientMargin to translate from mBounds to client bounds.

    This is both simpler and makes the math consistent.

    Differential Revision: https://phabricator.services.mozilla.com/D230981

 browser/base/content/test/popups/head.js           |   6 +-
 ...rowser_ext_browserAction_popup_resize_bottom.js |   4 +
 .../browser/browser_ext_windows_create_params.js   |  12 +-
 ...wser_unified_extensions_overflowable_toolbar.js |   2 +-
 .../browser/browser_screenshots_short_page_test.js |   4 +-
 .../tests/browser/browser_test_resize.js           |   4 +-
 .../components/screenshots/tests/browser/head.js   |  14 +-
 .../tests/browser_resources_stylesheets.js         |  21 +-
 dom/tests/mochitest/general/mochitest.toml         |   3 +
 dom/tests/mochitest/general/test_resizeby.html     |  16 +-
 layout/generic/nsContainerFrame.cpp                |   6 +-
 layout/xul/test/test_popupReflowPos.xhtml          |   8 +-
 .../content/tests/chrome/file_maximized_persist.js |  18 +-
 .../tests/chrome/test_screenPersistence.xhtml      |  32 +-
 widget/cocoa/nsCocoaWindow.h                       |   2 +-
 widget/cocoa/nsCocoaWindow.mm                      |   2 +-
 widget/gtk/WidgetStyleCache.cpp                    |  17 +-
 widget/gtk/gtk3drawing.cpp                         |   8 +
 widget/gtk/gtkdrawing.h                            |   2 +
 widget/gtk/nsWindow.cpp                            | 710 +++++++++++----------
 widget/gtk/nsWindow.h                              |  40 +-
 widget/nsBaseWidget.cpp                            |   4 +-
 widget/nsIWidget.h                                 |  26 +-
 widget/windows/nsWindow.cpp                        |   2 +-
 widget/windows/nsWindow.h                          |   2 +-
 xpfe/appshell/AppWindow.cpp                        |  30 +-
 26 files changed, 574 insertions(+), 421 deletions(-)

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Thanks, adding regression then.

Comment 3

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Can you reproduce on https://nightly.mozilla.org? I can't reproduce locally on KDE wayland (with either X11 and XWayland)...

Comment 5

[jmdavis]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #4)

Can you reproduce on https://nightly.mozilla.org? I can't reproduce locally on KDE wayland (with either X11 and XWayland)...

Yes, I can reproduce it with nightly. I also just tried building the latest commits for the main, release, and esr140 branches. The bug is there in all cases. And this is with KDE and X11.

If "Open previous windows and tabs" is enabled in the settings, and the title bar has been enabled via "Customize Toolbar...", then the window shrinks every time that Firefox is opened. I suspect that you missed one of the repro steps.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Not really, I did follow those to the letter. Do you repro on a clean profile? I presume so since you're building off clean commits... What GTK3 version are you on?

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Also, any titlebar customization on kde or so that might affect this?

Comment 8

[jmdavis]

I've been building it in a VM with Debian 12 (which has KDE 5) with no customizations for KDE at all, though I also tried nightly on one of my machines which has Arch on it with KDE 6, and that has some amount of customization, though I'm not aware of any which would affect the title bar aside from the color. Either way, since I've only used the VM for testing stuff, it has no customizations for KDE.

When building and running Firefox with mach, it seems to give a fresh profile every time I build (or at least every time I do a clean build, which is what I've been doing every time), so I have to set the settings again every time I test a commit. For testing nightly (or repro-ing with the installed version on any machine), I've just provided an empty directory to --profile to give it a fresh profile (and then set the settings). So, it's happening with a fresh profile with just the two settings. It also happens with my normal profiles with everything else in those, since I use those settings, but I had originally narrowed down the bug by using a fresh profile, and I've been using a fresh profile when testing to see if a particular commit or version has the issue.

As far as the GTK version goes, in the Debian VM where I've been building the code, it claims to have 3.24.38, whereas the Arch install where I tested the nightly (in addition to testing it on Debian) to make sure that I was getting the same behavior on multiple machines is using 3.24.51.

Now, I just tried it in the VM with Wayland instead of X11, and I'm not seeing the shrinking problem in that case. With X11, the window gets moved to where it was prior to closing Firefox, and then it gets resized to a smaller size (which is the bug), whereas on Wayland, it fails to move the window back to where it was but then doesn't resize it either. So, the shrinking problem isn't there, but instead, it has a problem restoring the window to where it was before.

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Yeah the wayland positioning issue is known and it's not really our bug in a sense (see bug 1870955).

But that's odd if you can repro on Arch with Kwin-x11. that's my environment and I haven't been able to reproduce...

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Attachment: Screencast of emilio trying to repro on kwin-x11, with current nightly build

I wonder what am I missing? What could be different from your set-up? The GTK theme? But that shouldn't affect decorations if you have the titlebar on...

Note that there's one time in the recording that we failed to restore the position but...

Comment 11

[jmdavis]

Attachment: Tested with nightly on Debian in a VM (no special config)

This shows the bug with nightly on Debian in a VM, using KDE 5 and X11. As it's a VM, there's no special config. IIRC, I turned off the screen locker and the power savings, but other than that, it should just be default KDE settings (or at least whatever the default is on Debian).

The window shrinks vertically each time that it's opened. I'm not sure why it's not shrinking horizontally as well though, since when I've tested it on other machines, it's also shrunk horizontally (though much less than vertically).

Comment 12

[jmdavis]

Attachment: Tested with nightly on Debian in a normal machine (so not the default config)

This shows the problem on a normal box running Debian with KDE 5 and X11. Because it's a machine that I use normally, it is not using the default config, though I don't know know off the top of my head what changes were made.

The window shrinks both vertically and horizontally each time that firefox is opened.

Comment 13

[jmdavis]

I overlaid the firefox window exactly over the konsole window in those two examples and avoided having it touch the sides of the screen in case some KDE setting would act differently because of that. Maybe you can reproduce it doing it that way. I don't know. As it is, for some reason, while it shrinks vertically on both of those machines, it only shrinks horizontally on the normal machine where the KDE config has been changed. In the VM (where it should be the default config aside from the power settings and screenlocker being disabled), it only shrinks vertically. So, maybe the drivers can interact in some way to affect it? I don't know.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Maybe running Firefox with the MOZ_LOG="widget:5" environment variable set would reveal some more details in the logs as printed to the console? @jmdavis maybe you could try and attach the log?

Comment 15

[Martin Stránský [:stransky] (ni? me)]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+2] from comment #14)
You need to use MOZ_LOG="Widget:5" env variable (it's case sensitive).

Comment 16

[jmdavis]

Attachment: firefox_debian_vm.log

This log is from just opening the browser (with the two settings in place already and the browser lined up with another window prior to closing it), waiting for it to open and shrink itself, and then closing the browser. This log was done in a VM running KDE 5 with Xorg in Debian 12 without custom settings for KDE, and it just shrunk vertically.

Comment 17

[jmdavis]

Attachment: firefox_arch.log

This log is from just opening the browser (with the two settings in place already and the browser lined up with another window prior to closing it), waiting for it to open and shrink itself, and then closing the browser. This log was done on one of my normal machines running KDE 6 with Xorg in Arch and with some amount of customization for KDE. It shrunk both vertically and horizontally.