1623106 - [Linux/Gtk] Firefox sometimes starts in normal mode instead of maximized one

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

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

Sometimes Firefox starts in maximized mode (it thinks is maximized) but draws only part of the screen. It affects both X11 and Wayland and seems to be a regression from Bug 1489463.

Comment 1

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

It's clearly reproducible on Fedora 32 with Firefox 74 / gnome-shell.

Comment 2

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

Here is the related log:

[(null) 78831: Main Thread]: D/Widget nsWindow::SetSizeMode [0x7fa734f52400] 0
[(null) 78831: Main Thread]: D/Widget already set
[(null) 78831: Main Thread]: D/Widget nsWindow::Resize [0x7fa734f52400] 1280 1020
[(null) 78831: Main Thread]: D/Widget nsWindow::ResizeInt [0x7fa734f52400] 0 0 -> 2560 2040 repaint 0
[(null) 78831: Main Thread]: D/Widget nsWindow::NativeResize [0x7fa734f52400] 1280 1020
[(null) 78831: Main Thread]: D/Widget nsWindow::SetSizeMode [0x7fa734f52400] 2
[(null) 78831: Main Thread]: D/Widget set maximized
[Parent 78831: Main Thread]: D/Widget GetScreenBounds [0x7fa734f52400] 0,0 -> 2560 x 2040, unscaled 0,0 -> 1280 x 1020
....
[Parent 78831: Main Thread]: D/Widget GetScreenBounds [0x7fa734f52400] 0,0 -> 3944 x 2144, unscaled 0,0 -> 1972 x 1072
[Parent 78831: Main Thread]: D/Widget nsWindow::OnSizeAllocate [0x7fa734f52400] -1,-1 -> 1280 x 1020
[Parent 78831: Main Thread]: D/Widget nsWindow::UpdateClientOffsetFromCSDWindow [0x7fa734f52400] 0, 0
[Parent 78831: Main Thread]: D/Widget GetScreenBounds [0x7fa734f52400] 0,0 -> 2560 x 2040, unscaled 0,0 -> 1280 x 1020

From some reason nsWindow::OnSizeAllocate() is called and it reverts the correct window dimension.

Comment 3

[Kestrel]

I can't reproduce this with Ubuntu 19.10 (GS 3.34.3) with a new profile (XWayland or Wayland, 74 or 76).

Comment 4

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

Seems to be related to https://gitlab.gnome.org/GNOME/gtk/issues/1044
It also depends on your current profile and resize/maximize sequence.

Comment 5

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

It works for me when the workaround for https://gitlab.gnome.org/GNOME/gtk/issues/1044 is removed. It's no longer needed for Gtk 3.24 so let's skip that for it.

Comment 6

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

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7964d615651471d21124ec41618fe17fe4405d7b

Comment 7

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

Attachment: Bug 1623106 [Linux/Gtk] Don't use window resize workaround for Gtk >= 3.24, r?jhorak

We have a workaround for https://gitlab.gnome.org/GNOME/gtk/issues/1044 which is already fixed
in Gtk 3.24 and causes resize regression there so let's remove it.

Comment 8

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

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=4e97c20755fe266f864730f633de964a804836cf

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/786ce3bfb9b5
[Linux/Gtk] Don't use window resize workaround for Gtk >= 3.24, r=jhorak

Comment 10

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

Looks like this one fixes it only partially for some cases. Filed a follow up Bug 1623658.

Comment 11

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/786ce3bfb9b5

Comment 12

[tt_1]

This happens once in a while for me with gnome-terminal-3.32.2 and gtk+3.24.13 , but I'm on v68.0 esr. Do you deem this to be backportable though? I can test any patch locally, but lack the experience with gtk+ to do the backporting on my own.

Comment 13

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

The patch here is incomplete and helps only partially. I don't think it's worth to backport it.