Answering Hsin-Yi's question:

If it's correct that this is due to bug 1363829, then this isn't really about throttling. What Bug 1363829 accomplished was to change setTimeout to use one nsITimer per call to setTimeout to one nsITimer per all calls to setTimeout for one Window (as in nsGlobalWindowInner). What Ben is reasoning about in Bug 1366642 is if this change to how setTimeout uses nsITimers have made setTimeout(f, 0) so much faster that it more frequently wins races against other events having a weak dependence on 'f' coming after where there should be a strong dependence.

Given the nature of the bug this actually feels quite plausible. We can hypothesise that painting the Firefox hangs off a setTimeout and the OS level window maximize waits on a callback from an event on the event queue and the setTimeout wins the race. We could possibly verify this by trying to reproduce this in a setting where we instrument setTimeout to be "slower" but we will probably not find it by scrutinizing Bug 1363829.

I'm experiencing this as well for months, somewhat frequently yet randomly.

I noticed both the reporter and myself have pinned tabs and CSD. I wonder if it's a problem that only surfaces under these certain conditions? Maybe some kind of bug initializing a pinned tab on session restore with CSD enabled

Screen recording:

https://www.youtube.com/watch?v=FobotXWC-bU

Watch carefully when I minimize and maximize the window. You'll see a faint rectangle on the outside edges animating outward into fullscreen mode.

I get this issue on both of my systems, Firefox Stable 66.0.2 on Solus 4 Budgie and Nightly on KDE Neon

(In reply to arcooke from comment #24)

I'm experiencing this as well for months, somewhat frequently yet randomly.

I noticed both the reporter and myself have pinned tabs and CSD. I wonder if it's a problem that only surfaces under these certain conditions? Maybe some kind of bug initializing a pinned tab on session restore with CSD enabled

Screen recording:

https://www.youtube.com/watch?v=FobotXWC-bU

Watch carefully when I minimize and maximize the window. You'll see a faint rectangle on the outside edges animating outward into fullscreen mode.

I get this issue on both of my systems, Firefox Stable 66.0.2 on Solus 4 Budgie and Nightly on KDE Neon

Somebody else reported here that it didn't work, but I found the Firefox startup to be much cleaner with MOZ_GTK_TITLEBAR_DECORATION=client. Instead of starting with a smaller size, then maximizing, the browser window starts directly maximized for me. I'm not really sure what the option does (compared to the browser.tabs.drawInTitlebar preference).

Note that you'll have to make sure this is set, so adding it to .profile probably won't work. You can put it in /etc/environment, ~/.pam_environment, or maybe in a .desktop file.

(In reply to Laurentiu Nicola from comment #25)

Thanks, I'll give it a shot for a while and see if it helps. I just used menulibre to modify the launch command to $MOZ_GTK_TITLEBAR_DECORATION=client firefox %u. So far in the first test, it opened maximized just fine but causes some weird flickering issues in Firefox if I right click on any of my "taskbar" icons in Budgie. Not a big deal though, I don't do that often.

Hopefully this gets looked at further, I'd rather not have to remember to do this on every new installation. Thanks for the reply.

Does this still happen? I've been running with MOZ_GTK_TITLEBAR_DECORATION=client which fixed the issue for me, but I can't seem to reproduce it even without. I switched to Wayland in the meantime, so that environment variable doesn't seem to be used there: https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#6701-6718, but it seems fixed now, even on X11.

I can still reliably reproduce this with latest Nightly 69.0a1 on XWayland (Ubuntu 19.04) using Comment 12 STR.

It's still happening for me too both under nightly and release, so it's not always reproducible.

Hsin-Yi, Andreas, can you help find someone to tackle this issue?
From the number of duplicates and possible dupes/related issues, it seems like this issue might be hitting a lot of users.

Looking at the reports, I feel like it's more likely a Widget:Gtk issue.
I wonder if Martin may know better to suggest the next step.

I'll look at it.

Martin, did you hear about picture-in-picture video window becoming super tiny after Windows wakes up after hibernation?

It happens to me regularly. Is this the same issue as this bug?

Can you try to create a log of that situation? Just run nightly as

$MOZ_LOG="Widget:5" ./firefox > log.txt 2>&1

close it when you see the bug and attach the log.txt here.

Thanks.

I mentioned this before, I haven't been able to reproduce the issue for a while now, but other commenters said it still happens. I'll remove my MOZ_GTK_TITLEBAR_DECORATION=client environment variable and keep an eye out for it in the next few days.

I'm running Firefox on Gnome Wayland with the title bar hidden. I don't know why setting MOZ_GTK_TITLEBAR_DECORATION used to have an effect.

Wayland backend always use MOZ_GTK_TITLEBAR_DECORATION=client as it's running in CSD mode due to Wayland architecture.

https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#6905 suggests that MOZ_GTK_TITLEBAR_DECORATION is set to client on Wayland, but that has been the case since bug 1514828 from last December. Before that it used system on Gnome.

I thought that client meant CSD and system meant non-CSD, but Gnome doesn't support system decorations, so I'm even more confused now.

Anyway, this WORKSFORME. If anyone in this thread still has the issue on non-Wayland, please mention your DE and try the test :stransky suggested.

I haven't tried on Wayland, but on non-Wayland I haven't encountered the issue recently.

(In reply to Laurentiu Nicola from comment #42)

https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#6905 suggests that MOZ_GTK_TITLEBAR_DECORATION is set to client on Wayland, but that has been the case since bug 1514828 from last December. Before that it used system on Gnome.

I thought that client meant CSD and system meant non-CSD, but Gnome doesn't support system decorations, so I'm even more confused now.

Client means CSD created/managed by Firefox, system means whatever is system default and it's managed by Gtk. System may mean CSD or non-CSD which depends on actual DE.

I reproduce on update. Just started lagging need to wait for the next nightly to show up.

I still can't reproduce this on Xorg and without MOZ_GTK_TITLEBAR_DECORATION or MOZ_ENABLE_WAYLAND set.

:Usul did you mean to post in this bug?

yes

20191002033852, Debian Testing, KDE, X11, Macbook Pro A1502, 2560x1600

MOZ_LOG="Widget:5" ./firefox > log.txt 2>&1

[ludovic@saraan ~]$ tail logforbugzilla.txt
[Parent 85544: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [0x7f53b2933400] for 0x7f53b2933a60 changed 0x80 new_window_state 0xab04
[Parent 85544: Main Thread]: D/Widget early return because no interesting bits changed
[Parent 85544: Main Thread]: D/Widget nsWindow::OnWindowStateEvent [0x7f53b2933400] for 0x7f53b5ec4050 changed 0x80 new_window_state 0xab04
[Parent 85544: Main Thread]: D/Widget quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 85544: Main Thread]: D/Widget OnEnterNotify: 0x7f53b2933400
[Parent 85544: Main Thread]: D/Widget OnLeaveNotify: 0x7f53b2933400
[Parent 85544: Main Thread]: D/Widget OnEnterNotify: 0x7f53b2933400
[Parent 85544: Main Thread]: D/Widget OnLeaveNotify: 0x7f53b2933400
[Parent 85544: Main Thread]: D/Widget GetScreenBounds 0,27 | 1600x843
[Parent 85544: Main Thread]: D/Widget GetScreenBounds 0,27 | 1600x843

I mentioned in my comment above (#24) that I suspect this may be related to pinned tabs, CSD, or a combination of the two.

Pinned tabs seem to be the one common denominator in all of the reports I've seen. This is evidenced again in comment #48. I am able to reproduce on both of my systems (Solus and KDE Neon) and all Firefox versions (Stable, beta, and nightly). If anyone is trying to reproduce and cannot.. please try pinning tabs and enabling CSD.

(In reply to arcooke from comment #51)

I mentioned in my comment above (#24) that I suspect this may be related to pinned tabs, CSD, or a combination of the two.

Not sure what CSD is, but I also ran into the issue without pinned tabs.

Thanks for the logs and video!

This seems to be relevant:

quick return because IS_MOZ_CONTAINER(aWidget) is true

also this line makes sense as we draw to moz_container in CSD mode (not mShell). Looks like we need to listen on mContainer state events in CSD mode.

FWIW, people that can or cannot reproduce may depend on whether the fix for https://gitlab.gnome.org/GNOME/gtk/issues/1044 is in their system or not (though I haven't verified that).

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

FWIW, people that can or cannot reproduce may depend on whether the fix for https://gitlab.gnome.org/GNOME/gtk/issues/1044 is in their system or not (though I haven't verified that).

Thanks Emilio.

I see in the log/video from comment 49 that Firefox is created maximized, then it's set to normal state but underlying mShell toplevel window remains maximized which seems to be bit different bug. Looks like resize event issued by Firefox itself (by session restore - last window size is saved) is not applied to toplevel mShell window.

I can still easily and reliably reproduce this with Comment 12 STR regardless of CSD being enabled or disabled on Ubuntu 19.04 (XWayland). I see the same thing as Comment 48 video (except that the blank area and window position differs based on the compositor). It is most likely a timing issue based on the regression window (Comment 19), that just happens to manifest with GTK.

(In reply to Martin Stránský [:stransky] from comment #56)

Looks like resize event issued by Firefox itself (by session restore - last window size is saved) is not applied to toplevel mShell window.

The (small) window size you see would occur if I unmaximized Nightly. But my Nightly is always maximized because I'm still unable to resize in CSD mode (bug 1453386). The only special thing I do is enforcing DPI=180 in KDE font settings.

Scratch my previous comment. I've just hit this on my non-Wayland setup with nightly 20191009213914.

I haven't seen this on Wayland recently using Firefox nightly.

This bug is making the rounds on reddit - https://www.reddit.com/r/firefox/comments/dy12wk/for_some_reason_firefox_often_doesnt_open/ - 73 points.

Is there any additional information that could be gathered to help resolve this bug?

Jim, your decision in this component without contribution to this issue is surprising. Please try KDE and restore sessions while having some app tabs pinned. This all started with client side decorations. This is both the most annoying and most user-visible Linux bug. I am sad that a broken Firefox window on a default KDE desktop is considered as wontfix - without any comment about what is going on and how one could further help. 9 days ago I marked 72 as affected as I saw this issue that day (and afterwards) - like all those affected Reddit users across all desktop environments. Yes, this severe regression is really shipped for over a year and nothing was done about it yet. :/

This morning I just run into this on Xfce (Fedora 31) and it seems reproducible. I'll see if I can get a log out of it.

The same bug can happen on Gnome too. I don't think it depends on the Desktop Environment/Window Manager (excepted maybe tilling WM whose behavior is a bit different).

I can still reliably reproduce it with MOZ_GTK_TITLEBAR_DECORATION=client in
X11 (and XWayland) and also with mozilla.widget.use-argb-visuals = false. I
made a test build with most of Bug 1364355 changes removed and it still
happens so it looks like a different bug in the regression window (which I
retested and is quite solid).

Can you please try to reproduce with MOZ_GTK_TITLEBAR_DECORATION=system ?
If MOZ_GTK_TITLEBAR_DECORATION=system works (and MOZ_GTK_TITLEBAR_DECORATION=client fails) it's a variant of Bug 1587008 when mozcontainer has it's own window which fails to change the size.
Thanks.

From what I see now it looks like Firefox resizes itself but GdkWindow size allocation does not change.

I can reproduce it so I don't need any other info.

There's the bug description:

step 1
[(null) 10355: Main Thread]: D/Widget nsWindow::SetSizeMode [0x7f8da5976800] 2 (maximized)
[(null) 10355: Main Thread]: D/Widget nsWindow::OnSizeAllocate [0x7f8da5976800] 0,0 -> 3892 x 2092
[(null) 10355: Main Thread]: D/Widget configure event [0x7f8da5976800] 0 54 3840 2040
[(null) 10355: Main Thread]: D/Widget GetScreenBounds [0x7f8da5976800] 0,54 -> 3892 x 2092, unscaled 0,54 -> 3892 x 2092

mShell/mContainer is at maximized state, GetScreenBounds returns correct values (3892 x 2092)

step 2
[(null) 10355: Main Thread]: D/Widget nsWindow::SetSizeMode [0x7f8da5976800] 0 (normal)
[(null) 10355: Main Thread]: D/Widget nsWindow::Resize [0x7f8da5976800] 1446.000000 945.000000
[(null) 10355: Main Thread]: D/Widget nsWindow::NativeResize [0x7f8da5976800] 1446 945 maximized state 1
[(null) 10355: Main Thread]: D/Widget GetScreenBounds [0x7f8da5976800] 0,54 -> 1446 x 945, unscaled 0,54 -> 1446 x 945

mShell/mContainer is requested to have a normal state but mContainer was not resized yet - we're missing OnSizeAllocate() call on it.
GetScreenBounds was set to new size (1446 x 945) by Resize() without actual mContainer size update.

https://searchfox.org/mozilla-central/rev/42c2ecdc429115c32e6bcb78bf087a228a051044/widget/gtk/nsWindow.cpp#1079
https://searchfox.org/mozilla-central/rev/42c2ecdc429115c32e6bcb78bf087a228a051044/widget/gtk/nsWindow.cpp#1108

step 3
[(null) 10355: Main Thread]: D/Widget nsWindow::SetSizeMode [0x7f8da5976800] 2 (maximized)
[(null) 10355: Main Thread]: D/Widget configure event [0x7f8da5976800] 0 54 3840 2040
[(null) 10355: Main Thread]: D/Widget GetScreenBounds [0x7f8da5976800] 0,54 -> 1446 x 945, unscaled 0,54 -> 1446 x 945

mShell/mContainer was asked to be maximized again. GetScreenBounds are set to old size (1446 x 945) by Resize() from step 2
but we don't get another OnSizeAllocate() call as mShell/mContainer didn't change their actual sizes at step 2.

Karl,do you think we can remove the mBounds set from nsWindow::Resize() and wait for mContainer change?

Thank you for the analysis, Martin.

From GTK's perspective, it doesn't need to send a size-allocate for 3892 x 2092 because it hasn't ever sent a size-allocate for 1446 x 945.

(In reply to Martin Stránský [:stransky] from comment #68)

Karl,do you think we can remove the mBounds set from nsWindow::Resize() and wait for mContainer change?

So yes, removing the mBounds.SizeTo() code from Resize() is the right thing to do from GTK's perspective.

If doing that, then it would also make sense to remove the DispatchedResized() call, which would send the wrong size. OnSizeAllocate() will ensure that DispatchedResized() is called eventually.

I don't know how much Gecko depends on mBounds being updated synchronously.
I suspect some tests may make assumptions.

Given that the correct size is eventually notified, any issues should be transient. If the mochitests pass, or can be adjusted to wait for the right size, then I like your approach.

(In reply to Karl Tomlinson (:karlt) from comment #69)

Given that the correct size is eventually notified, any issues should be transient. If the mochitests pass, or can be adjusted to wait for the right size, then I like your approach.

You're right, mochitest is all orange. I may find a different solution for it.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=726f2112f3bc12b96892a99f051583d1f7e81484

Usually we update mBounds from OnSizeAllocate() which is called
by Gtk when mContainer changes its actual size.

However we need to set mBounds in advance at Resize() as JS
code expect immediate window size change. When Resize() is called between
SetSizeMode() calls (which maximize/unmaximize the window) we can miss
OnSizeAllocate() Gtk call as actual mContainer size may not change
from Gtk perspective and we end up with incorrect mBounds.

To compensate it call OnSizeAllocate() explicitly also
from OnConfigureEvent().

Karl, I can't find any better solution as the delayed mBounds update breaks our test ans I also think JS code expect the window resize is immediate.

A more complicated solution may be to detect the actual scenario (SetSizeMode() -> Resize() ->SetSizeMode() -> OnWindowStateEvent() -> OnWindowStateEvent()) but I think it's too much complicated and it's better to just early return from OnSizeAllocate() when mBounds are already set from configure.

Also it may not break nested mContainers as those were AFAIK used for windowed NPAPI plugins only which are not supported now.

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

Using OnConfigureEvent() should be fine, I assume, if it works.
If gtk_window_maximize() is called after gtk_window_resize() on a window at maximum size, then it looks like GTK will not send a ConfigureRequest.
I don't know of any guarantee that unmaximize followed by maximize will generate a ConfigureNotify, but it would seem reasonably likely that a window manager would generate a ConfigureNotify.

There will be more resize events if the window is being resized by the user, so there may be a little more lag in keeping up. Hopefully the browser responds somewhat asynchronously to the resize events so as not to repeat layout.

I considered some other approaches, but didn't come up with anything good:

A gtk_container_check_resize() call after gtk_window_resize() would force a ConfigureRequest with the size passed to resize. However, when configure_notify_received is set, gtk_window_move_resize() size_allocate()s with current width/height, which I assume may have the new maximized size by the time the queued resize event runs. Another gtk_container_check_resize() call in OnConfigureEvent() might ensure a gtk_widget_size_allocate() call with the size of the ConfigureNotify response, but all the forced resizes don't seem appealing.

It would be hard to gtk_widget_size_allocate() appropriately immediately after gtk_window_resize() because the allocation for the window needs to include CSD.

I agree that an approach detecting a specific sequence of resize/maximize events is not appealing.

Backed out for failures on browser_roundedWindow_windowSetting_max_inner.js

backout: https://hg.mozilla.org/integration/autoland/rev/c105b062c29812190c074cbd24f97c6306017321

push: https://treeherder.mozilla.org/#/jobs?repo=autoland&searchStr=linux%2Cx64%2Cshippable%2Copt%2Cmochitests%2Ctest-linux64-shippable%2Fopt-mochitest-browser-chrome-e10s-3%2Cm%28bc3%29&revision=c9c256a84d8de828e6af4f04183ee8d0eb039a20&selectedJob=281355202

failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=281355202&repo=autoland&lineNumber=3110

[task 2019-12-16T13:28:43.547Z] 13:28:43 INFO - TEST-PASS | browser/components/resistfingerprinting/test/browser/browser_roundedWindow_windowSetting_max_inner.js | The window.innerWidth has a correct rounded value - 1000 == 1000 -
[task 2019-12-16T13:28:43.547Z] 13:28:43 INFO - Buffered messages finished
[task 2019-12-16T13:28:43.548Z] 13:28:43 INFO - TEST-UNEXPECTED-FAIL | browser/components/resistfingerprinting/test/browser/browser_roundedWindow_windowSetting_max_inner.js | The screen.height has a correct rounded value - 100 == 1000 - got 100, expected 1000 (operator ==)
[task 2019-12-16T13:28:43.548Z] 13:28:43 INFO - Stack trace:
[task 2019-12-16T13:28:43.549Z] 13:28:43 INFO - is@resource://specialpowers/SpecialPowersSandbox.jsm:89:21
[task 2019-12-16T13:28:43.549Z] 13:28:43 INFO - @chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:278:13
[task 2019-12-16T13:28:43.549Z] 13:28:43 INFO - EventListener.handleEvent*@chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:275:11
[task 2019-12-16T13:28:43.549Z] 13:28:43 INFO - @chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:274:11
[task 2019-12-16T13:28:43.549Z] 13:28:43 INFO - asyncexecute@resource://specialpowers/SpecialPowersSandbox.jsm:140:12
[task 2019-12-16T13:28:43.550Z] 13:28:43 INFO - _spawnTask@resource://specialpowers/SpecialPowersChild.jsm:1724:15
[task 2019-12-16T13:28:43.550Z] 13:28:43 INFO - receiveMessage@resource://specialpowers/SpecialPowersChild.jsm:286:21
[task 2019-12-16T13:28:43.550Z] 13:28:43 INFO - JSWindowActor queryreceiveMessage@resource://specialpowers/SpecialPowersParent.jsm:1055:12
[task 2019-12-16T13:28:43.550Z] 13:28:43 INFO - JSWindowActor queryspawn@resource://specialpowers/SpecialPowersChild.jsm:1679:17
[task 2019-12-16T13:28:43.551Z] 13:28:43 INFO - testWindowSizeSetting@chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:221:23
[task 2019-12-16T13:28:43.551Z] 13:28:43 INFO - doTest@chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:372:11
[task 2019-12-16T13:28:43.551Z] 13:28:43 INFO - doTests@chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:359:18
[task 2019-12-16T13:28:43.551Z] 13:28:43 INFO - asyncrun/<@chrome://mochitests/content/browser/browser/components/resistfingerprinting/test/browser/head.js:317:20
[task 2019-12-16T13:28:43.551Z] 13:28:43 INFO - Tester_execTest/<@chrome://mochikit/content/browser-test.js:1062:34
[task 2019-12-16T13:28:43.552Z] 13:28:43 INFO - async*Tester_execTest@chrome://mochikit/content/browser-test.js:1097:11
[task 2019-12-16T13:28:43.552Z] 13:28:43 INFO - nextTest/<@chrome://mochikit/content/browser-test.js:925:14
[task 2019-12-16T13:28:43.552Z] 13:28:43 INFO - SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:808:67
[task 2019-12-16T13:28:43.552Z] 13:28:43 INFO - Not taking screenshot here: see the one that was previously logged

https://hg.mozilla.org/mozilla-central/rev/26a680dd5f44

I can still reliably reproduce this on latest Nightly with STR from Comment 12.

I'm the original reporter but I no longer had this problem. I upgraded today to check up on this patch, and on the first startup the window size was wrong. One difference is that the window buttons are now aligned correctly, while the window extends downwards, under my panel. Clicking maximize (or restore?) once brought the window height to the screen height, while a second click maximized it properly.

(In reply to Kestrel from comment #79)

Created attachment 9116640 [details]
Maximized window from previous session still not fully rendering

I can still reliably reproduce this on latest Nightly with STR from Comment 12.

Can you please run with MOZ_LOG="Widget:5" and attach the output here?
Thanks.

As requested.

Thanks.

I'm afraid there's no workaround so just need to fix the tests.

• Invalidate mBounds when window state is changed. That ensures we get new window size from configure event.
• Join Resize() routines and use ResizeInt() for the actual resize work.
• Add more logging to nsWindow file.

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

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

https://hg.mozilla.org/mozilla-central/rev/7b38387950db

Comment 12 STR is no longer reproducible on latest Nightly.

(In reply to Kestrel from comment #90)

Comment 12 STR is no longer reproducible on latest Nightly.

\o/ This is awesome

Sorry to have to kick this can down the road again.. but I'm still having this issue on Nightly 72.0b11.

Recently, I started getting a weird flickery black box in addition to the phantom window issue. I've had the reported issue for quite some time now, but the black box is relatively new for me. See below:

https://www.youtube.com/watch?v=Xcr8wtQ8v8Y

Solus w/ Budgie (Mutter)

arcooke, I have a feeling that your issue might be the same as the issue I reported in Bug 1604948, which I have been informed is a mutter/gnome-shell bug. Since you use mutter, maybe the same issue?

That could have something to do with the black part I suppose.. but I'm still having the original reported issue with the firefox window rendering in the wrong spot. You can see in my video that my mouse cursor is hovering over an invisible browser window at the top of the screen, while highlighting tabs and buttons in the visible firefox window below.

I posted about it in this thread 9 months ago and I've been encountering it almost every day since, so I'm intimately familiar with the bug. No fix yet on my end, unfortunately :(

(In reply to arcooke from comment #92)

Sorry to have to kick this can down the road again.. but I'm still having this issue on Nightly 72.0b11.

This bug is marked as fixed in 73 (current nightly), not 72 (current beta).

(In reply to arcooke from comment #92)

Sorry to have to kick this can down the road again.. but I'm still having this issue on Nightly 72.0b11.

Recently, I started getting a weird flickery black box in addition to the phantom window issue. I've had the reported issue for quite some time now, but the black box is relatively new for me. See below:

https://www.youtube.com/watch?v=Xcr8wtQ8v8Y

Yes, I understand you. I saw that too with WebRender/GL compositor enabled. This one is a bug when underlying mozcontainer which is holding GL window is not resized/positioned properly. This bug happens with WebRender/GL compositor only.

If you see it please file a new bug against widget:gtk for it and CC me there.

Thanks.

(In reply to Julien Cristau [:jcristau] from comment #95)

(In reply to arcooke from comment #92)

Sorry to have to kick this can down the road again.. but I'm still having this issue on Nightly 72.0b11.

This bug is marked as fixed in 73 (current nightly), not 72 (current beta).

Touché... you're right. I bamboozled myself. I use Beta on some of my machines and use Nightly on others.. but I always manually change to the purple nightly icon because I like how it looks.. ha. I'll switch to nightly on that machine and see if that resolves it (I expect it will now). Thanks

(In reply to Martin Stránský [:stransky] from comment #96)

(In reply to arcooke from comment #92)

Sorry to have to kick this can down the road again.. but I'm still having this issue on Nightly 72.0b11.

Recently, I started getting a weird flickery black box in addition to the phantom window issue. I've had the reported issue for quite some time now, but the black box is relatively new for me. See below:

https://www.youtube.com/watch?v=Xcr8wtQ8v8Y

Yes, I understand you. I saw that too with WebRender/GL compositor enabled. This one is a bug when underlying mozcontainer which is holding GL window is not resized/positioned properly. This bug happens with WebRender/GL compositor only.

If you see it please file a new bug against widget:gtk for it and CC me there.

Thanks.

Will do! Thanks. And you're correct, I'm using webrender/gl.

This can probably be re-closed now.. apologies for the mixup

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

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