1630251 - Maximized windows sometimes get stuck in their initial small creation size when restoring previous session (No. 2)

Status: RESOLVED FIXED

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

Description

[Darkspirit]

(Jan Andre Ikenmeyer [:darkspirit] from bug 1489463 comment 99)

This intermittent bug (bug 1489463 comment 62) came back four or five weeks ago. It was present before and during bug 1624199. (KDE, X11, Debian Testing)

This time it is not black, I see my desktop background, but behavior is the same.

(Laurențiu Nicola from bug 1489463 comment 100)

I can confirm. I think it started showing up again around bug 1609538.

Comment 1

[Darkspirit]

No, this is on X11. bug 1489463 was about Firefox' default Linux configuration and this seems like the same.

Comment 2

[Laurențiu Nicola]

I see it on Gnome Wayland. Maybe we're running into two different issues?

Comment 3

[Darkspirit]

Then it's likely the same Gtk problem, but it's not exclusive to disabled-by-default Wayland.

Comment 4

[Darkspirit]

Attachment: Screenshot_20200415_171753.png

It happens with and without browser.tabs.drawInTitlebar. KDE/X11/Debian Testing/Macbook Pro
I'll try to run mozregression with a copy of my profile.

Comment 5

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

I think you have HW acceleration enabled, don't you? Can you try with basic compositor?
It may be also Bug 1623658.

Comment 6

[Darkspirit]

Attachment: Basic.png

Basic layers, KDE, X11 (not XWayland), Debian Testing
I force-disabled WebRender and restarted by applying a Nightly update:
It seemed the window was maximized (like in attachment 9140784 [details] where I'm using WebRender), but not the window's visible content which jumped into the top-left corner, left phantom window content (painting) at its previous position and another behind its right border. Then I opened about:support. I could hover tabs and window buttons at the place they were drawn.

Comment 7

[Darkspirit]

The Gtk bug report of bug 1623658 is only about Wayland and its fix only changed "gdk/wayland/gdkwindow-wayland.c".

Comment 8

[gwarser]

I can reproduce this easily when i had popups opened in previous session and main window was closed before popup. This happens to me often with uBlock Origin logger (see also bug 1516819).
Seems to also happen with normal popups, I tried just now on "direct url popup" from http://raymondhill.net/ublock/popup.html

Latest Nightly, clean profile, title bar disabled, restore session enabled. Manjaro KDE.

On daily used profile (webrender on) I have browser.startup.blankWindow set to false and it helps.

Comment 9

[Denis Lisov]

Seeing the same for a long time, KDE/X11, WebRender. A huge session with lots of tabs in session restore.

There was one change in bug behavior I noticed at some point (probably weeks or months ago, not sure): when I unmaximize the window and then maximize it again to "fix" this, it used to repaint correctly on unmaximize, and now it does not, only on the following maximize it repaints correctly.

Comment 10

[Darkspirit]

Could this be related to bug 1625882?

Comment 13

[Darkspirit]

I haven't seen this bug in the past one or two weeks. (kwin-x11 4:5.17.5-2, Debian Testing)

Comment 14

[Zach Hoffman [:zrhoffman]]

I can still consistently reproduce bug 1617506 on the latest nightly (10ad7868f3 according to about:buildconfig) in i3 on Arch Linux. Its behavior looks the same as when it was reported.

Comment 15

[gwarser]

Attachment: Screenshot_20200612_103343.png

Build 20200611093454, webrender disabled (I have graphic crashes with lately :[ )

Comment 18

[Darkspirit]

https://www.reddit.com/r/firefox/comments/ikn801/every_time_after_a_reboot_firefox_startup_like/

Comment 19

[Clément Lefèvre]

Attachment: Screenshot from 2021-03-06 13-15-24.png

Comment 20

[Lyubomir [:mystiquewolf]]

This happens each time i start Firefox from cold boot on Kubuntu 20.04.2. WebRender is enabled.

Comment 21

[Clément Lefèvre]

Attachment: Screenshot from 2021-06-07 15-14-14.png

Bug has gotten even worse with version 89. Now it seems to do a double resize and shrink even more, see screenshot.

Comment 22

[Lyubomir [:mystiquewolf]]

On Kubuntu 21.04 with Wayland session, MOZ_ENABLE_WAYLAND=1 and WebRender + Fission, this does not happen on my PC. Before that on X.Org and Kubuntu 20.04 i believe it happened on almost every start of Firefox.

Comment 26

[Marco Castelluccio [:marco]]

Martin, given the high number of duplicates, could you reassess the priority and assign a severity to this bug?

Comment 27

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

(In reply to Marco Castelluccio [:marco] from comment #26)

Martin, given the high number of duplicates, could you reassess the priority and assign a severity to this bug?

This is a longstanding issue caused by async nature of Gtk events, sync nature of JS/DOM event and Gtk timers. And potential fix also needs to pass mozilla testsuite which is based on ancient Ubuntu 18.04.

When we update test environment to something recent (see Bug 1725245) we can consider to open it again. I tried to fix that before (Bug 1489463) but I obviously failed.

Comment 34

[Emilio Cobos Álvarez (:emilio)]

There are some logs in bug 1719120. I think part of the issue may be the:

[Parent 990046: Main Thread]: D/Widget [7fa70144f400]: nsWindow::Move to 960 0

That unmaximizes the window implicitly, which can cause confusion.

Then there is three OnSizeAllocate calls on the bad case, the last one being::

[Parent 990046: Main Thread]: D/Widget [7fa70144f400]: nsWindow::OnSizeAllocate -1,-1 -> 1440 x 750
[Parent 990046: Main Thread]: D/Widget [7fa70144f400]: Already the same size

Which seems to go from here.

Martin, this seems to be similar to bug 1623106, can you make any sense of the logs above?

One potential workaround / simplification that could help, maybe, is just not unmaximizing when nsWindow::Move is called. That matches the macOS / Cocoa behavior, and it might make sense since on Wayland we can't honor the move anyways... Martin wdyt of that?

Comment 35

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

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

One potential workaround / simplification that could help, maybe, is just not unmaximizing when nsWindow::Move is called. That matches the macOS / Cocoa behavior, and it might make sense since on Wayland we can't honor the move anyways... Martin wdyt of that?

That may work but for toplevels only.

Comment 36

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1630251 - Ignore window move request when not in the normal size mode. r=stransky

This should help.

Comment 37

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fb04ac8d460a
Ignore window move request when not in the normal size mode. r=stransky

Comment 38

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/fb04ac8d460a

Comment 39

[Zach Hoffman [:zrhoffman]]

I tested attachment 9270404 [details] and can still reproduce Bug 1617506 (privacy.resistFingerprinting=true, layers.acceleration.force-enabled=true, check second startup). So if Bug 1630251 is now fixed, maybe Bug 1617506 should be reopened.