1986262 - [wayland] Context menus still flash underlying window when first drawn

Status: NEW

(Core :: Widget: Gtk, defect)

Description

[Kestrel]

Bug 1978615 is still reproducible on latest Nightly 144.0a1 (2025-09-01). It does not appear in screen recordings anymore, showing a black region instead of the underlying window but it still appears on the screen itself.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:emilio, since you are the author of the regressor, bug 1967114, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Martin, any chance you know what's going on?

Comment 3

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

If you see a back region there's gap between window map and window paint. It may be visible in debug mode. If we mark the window non-transparent Gtk may paint default background of mShell/mContainer which will be replaced by Firefox content then.

For instance if toplevel Firefox window is painted in debug mode, window decorations are visible before actual content, but mShell GtkWindow is transparent so it's not visible (except the decorations).

I guess we may delay the opaque region set somehow and set it when the content is already painted if we want to fix it.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1967114

Comment 5

[Donal Meehan [:dmeehan]]

Adding a need-info for :emilio from Comment 3.
We're wondering if there will be an investigation in time for Fx145?

Comment 6

[Emilio Cobos Álvarez [:emilio]]

I mean, we could re-disable opaque region for popups at some efficiency cost, but I haven't been able to reproduce this whatsoever.

Comment 7

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

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

I mean, we could re-disable opaque region for popups at some efficiency cost, but I haven't been able to reproduce this whatsoever.

That may introduce Bug 1978615 again. If we create transparent window with opaque region set, there may be any underlying content here. Right now we ensure there's default background at least.

Comment 8

[Kestrel]

Attachment: Context menus flash underlying window on display

I can reproduce it on multiple systems running Ubuntu 25.04 and 24.04 LTS (GNOME) (HW-WR and SW-WR).

It does not occur on Kubuntu 25.04 (KDE, Plasma).

Comment 10

[Daniel Holbert [:dholbert]]

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

I mean, we could re-disable opaque region for popups at some efficiency cost, but I haven't been able to reproduce this whatsoever.

I can repro fwiw. Happy to test a patch if you have ideas.

Comment 11

[Emilio Cobos Álvarez [:emilio]]

This would be the obvious patch for that:

diff --git a/widget/gtk/nsWindow.cpp b/widget/gtk/nsWindow.cpp
index 732a02a8d2cf..5dbea3a0e171 100644
--- a/widget/gtk/nsWindow.cpp
+++ b/widget/gtk/nsWindow.cpp
@@ -7028,7 +7028,7 @@ void nsWindow::UpdateOpaqueRegion(const LayoutDeviceIntRegion& aRegion) {
 }

 void nsWindow::UpdateOpaqueRegionInternal() {
-  if (!mCompositedScreen) {
+  if (!mCompositedScreen || IsPopup()) {
     return;
   }

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #11)

This would be the obvious patch for that:

That patch does seem to fix it.

I tested a git commit from today: https://github.com/mozilla-firefox/firefox/commit/b371c49fd343412ffec3043369a83bdcb307bb37

I tested three times without comment 11's patch, and then three times with comment 11's patch. I started with a fresh profile each time and followed my STR from bug 1989611 comment 6.

All three tests without the patch were "bad" (corruption was visible in the second or third context-menu that I spawned at the end of the STR, and every few context menus that I spawned thereafter).

All three tests with comment 11's patch were "good" (I spawned 20+ context-menus at the end of the STR without seeing any corruption).

Comment 13

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

(In reply to Emilio Cobos Álvarez [:emilio] from comment #11)

This would be the obvious patch for that:

diff --git a/widget/gtk/nsWindow.cpp b/widget/gtk/nsWindow.cpp
index 732a02a8d2cf..5dbea3a0e171 100644
--- a/widget/gtk/nsWindow.cpp
+++ b/widget/gtk/nsWindow.cpp
@@ -7028,7 +7028,7 @@ void nsWindow::UpdateOpaqueRegion(const LayoutDeviceIntRegion& aRegion) {
 }

 void nsWindow::UpdateOpaqueRegionInternal() {
-  if (!mCompositedScreen) {
+  if (!mCompositedScreen || IsPopup()) {
     return;
   }

Can we just set the opaque region when we have painted any content there? This just removes all the rendering optimization we use.

Comment 14

[Emilio Cobos Álvarez [:emilio]]

Yeah, though arguably it only does so for popups which historically didn't happen until the regressing bug... So probably an ok stop-gap...

Comment 15

[Daniel Holbert [:dholbert]]

FWIW I'm pretty sure I've been seeing this same bug when opening new Firefox windows, too (Ctrl+N or Ctrl+Shift+P) -- not just popups. I've noticed it twice today -- I can't reproduce it on-demand, but when it does happen, I'll see a flicker of content from some not-currently-visible window or tab, as the new window opens (showing up briefly in the new window before we draw the actual Firefox UI, I think).

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: video of flicker on new-window

Managed to capture the new-window/Ctrl+N version of this on camera -- see attached video.

At about t=1s, I do Ctrl+N which should open a new window, so we should go directly from showing the bugzilla page to showing about:home. But for some reason we show a brief flicker with what looks like several superimposed background windows.

Comment 17

[Daniel Holbert [:dholbert]]

Attachment: screenshot showing the moment from my video where Ctrl+N has a flicker of unrelated content

Here's the moment-of-badness from my just-attached video.

Observations:
(1) The new window is partially transparent as it appears (that's expected, I think).
(2) The toolbars at the top of the (partially-transparent) new window all look correct - there's a tab-strip with a single focused tab at the left, with a "+" to the right of it, and "Search with Google or enter address" in the address-bar.
(3) but the page-content area is filled with unexpected/unwanted renderings of background windows -- several Chrome windows in this case, actually, with testcases that I was poking at in bug 1990901.

Comment 18

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

Yes, I think it's a general bug which affects all Firefox windows. We open a GtkWidget first and then it takes some time before we have a content for it.

Comment 19

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

We're trying to start composting / rendering only when we're ready to draw, i.e. we have rendering target:
https://searchfox.org/firefox-main/rev/6f3037f71baa242161ed343cdccb12c1b8e50227/widget/gtk/nsWindow.cpp#6088

I wonder if that can be adjusted somehow - paint to offscreen buffer for instance. That's Bug 1943518 - always paint to subsurface even if it's detached from screen.

Comment 20

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

Can you please test latest nightly? May be dupe of Bug 1999513.
Thanks.

Comment 21

[Kestrel]

Still see it on latest Nightly 147.0a1 (2025-11-13).

Comment 22

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

Okay, Thanks. Will try debug build then.

Comment 23

[Daniel Holbert [:dholbert]]

Yeah, I'm still seeing the bug on latest Nightly (2025-11-13) too. Tested using my STR in bug 1989611 comment 6.

Comment 24

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

Ahh I see. Bug 1999513 can't fix that for popups as we don't use frame callbacks for popups. Bug 1998657 regressions are related here.

Comment 25

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

(In reply to Martin Stránský [:stransky] (ni? me) from comment #24)

Ahh I see. Bug 1999513 can't fix that for popups as we don't use frame callbacks for popups. Bug 1998657 regressions are related here.

Okay, disregards this - we use mPendingOpaqueRegion && !mOpaqueRegionFrameCallback prior of early quit at !mFrameCallbackEnabled || !mFrameCallbackHandler.IsSet().