Maximized windows sometimes get stuck in their initial small creation size when restoring previous session (No. 2)
Categories
(Core :: Widget: Gtk, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | wontfix |
firefox-esr91 | --- | wontfix |
firefox75 | --- | wontfix |
firefox76 | --- | wontfix |
firefox77 | --- | wontfix |
firefox78 | --- | wontfix |
firefox92 | --- | wontfix |
firefox93 | --- | wontfix |
firefox94 | --- | wontfix |
firefox95 | --- | wontfix |
firefox96 | --- | wontfix |
firefox97 | --- | wontfix |
firefox99 | --- | wontfix |
firefox100 | --- | fixed |
People
(Reporter: jan, Assigned: emilio)
References
Details
(Keywords: nightly-community, regression, regressionwindow-wanted)
Attachments
(6 files)
(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.
Reporter | ||
Comment 1•4 years ago
|
||
No, this is on X11. bug 1489463 was about Firefox' default Linux configuration and this seems like the same.
Comment 2•4 years ago
|
||
I see it on Gnome Wayland. Maybe we're running into two different issues?
Reporter | ||
Comment 3•4 years ago
|
||
Then it's likely the same Gtk problem, but it's not exclusive to disabled-by-default Wayland.
Reporter | ||
Comment 4•4 years ago
|
||
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•4 years ago
|
||
I think you have HW acceleration enabled, don't you? Can you try with basic compositor?
It may be also Bug 1623658.
Updated•4 years ago
|
Reporter | ||
Comment 6•4 years ago
|
||
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.
Reporter | ||
Comment 7•4 years ago
|
||
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.
Reporter | ||
Updated•4 years ago
|
Comment 9•4 years ago
|
||
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.
Reporter | ||
Comment 10•4 years ago
|
||
Could this be related to bug 1625882?
Updated•4 years ago
|
Reporter | ||
Comment 13•4 years ago
|
||
I haven't seen this bug in the past one or two weeks. (kwin-x11 4:5.17.5-2, Debian Testing)
Comment 14•4 years ago
|
||
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•4 years ago
|
||
Build 20200611093454, webrender disabled (I have graphic crashes with lately :[ )
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 18•4 years ago
|
||
Comment 19•4 years ago
|
||
Comment 20•3 years ago
|
||
This happens each time i start Firefox from cold boot on Kubuntu 20.04.2. WebRender is enabled.
Comment 21•3 years ago
|
||
Bug has gotten even worse with version 89. Now it seems to do a double resize and shrink even more, see screenshot.
Reporter | ||
Updated•3 years ago
|
Comment 22•3 years ago
|
||
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.
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Comment 26•3 years ago
|
||
Martin, given the high number of duplicates, could you reassess the priority and assign a severity to this bug?
Comment 27•3 years ago
|
||
(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.
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 34•2 years ago
|
||
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•2 years ago
|
||
(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.
Assignee | ||
Comment 36•2 years ago
|
||
This should help.
Updated•2 years ago
|
Comment 37•2 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fb04ac8d460a Ignore window move request when not in the normal size mode. r=stransky
Comment 38•2 years ago
|
||
bugherder |
Comment 39•2 years ago
|
||
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.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•1 year ago
|
Description
•