(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.

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

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

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

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.

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

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.

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

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.

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.

Could this be related to bug 1625882?

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

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.

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

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

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

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

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.

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

(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.

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?

(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.

This should help.

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

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.