1813407 - [Wayland] Portions of the protections panel are disappearing

Status: VERIFIED FIXED

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

Description

[Gregory Pappas [:gregp]]

Attachment: popup_bug.webm

Steps to reproduce:

1. Navigate to https://bugzilla.mozilla.org/
2. Open the Protections Panel (shield icon)
3. Press the info button at the top right corner of the panel

Actual results:
The top and bottom of the panel disappear sometimes.

Expected results:
Normal

Comment 1

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

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

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

For more information, please visit auto_nag documentation.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

So I couldn't reproduce this but there's lots of flickering on this animation even before my patch if you have a non-round width (so if you have "large text" or something).

I see that already on release tho... Robert / Martin, any idea of what might be going on? This animation causes a lot of widget resizes so it might be triggering a race in GTK even perhaps. I don't see the flickering with X11, but I'm not sure what's the root cause off-hand.

Comment 3

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

X11 should not cause any race during rendering.
Wayland uses wl_subsurfaces when popup is smaller than toplevel parent window and xdg_popup when it's bigger. xdg_popup is known to flicker while wl_subsurfaces should not.

Gregory, can you please attach your about:support page? Which system/compositor do you use?
Thanks.

Comment 4

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

I don't see any flickering on X11, only Wayland affected. Tested latest nightly and I can reproduce the flickering on Wayland only.

Comment 5

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

Hm, the animation on video looks like X11 one, not Wayland.

Comment 6

[Gregory Pappas [:gregp]]

Attachment: about:support

(In reply to Martin Stránský [:stransky] (ni? me) from comment #3)
> Gregory, can you please attach your about:support page? Which system/compositor do you use?

Comment 7

[Gregory Pappas [:gregp]]

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

Which system/compositor do you use?

Fedora 37. GNOME, Wayland, Mutter.

Comment 8

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

Can you try nightly with MOZ_ENABLE_WAYLAND=0 env variable, i.e. with disabled Wayland?
Thanks.

Comment 9

[Gregory Pappas [:gregp]]

I see no flickering when MOZ_ENABLE_WAYLAND is set 0.

Comment 10

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

(In reply to Gregory Pappas [:gregp] from comment #9)

I see no flickering when MOZ_ENABLE_WAYLAND is set 0.

And do you see the bug with MOZ_ENABLE_WAYLAND set to 0?

Comment 11

[Gregory Pappas [:gregp]]

I don't see the bug when MOZ_ENABLE_WAYLAND is set to 0.

Comment 12

[Donal Meehan [:dmeehan]]

:stransky could you set a severity, anything we can do for 111?

Comment 13

[Robert Mader [:rmader]]

Gregory, any chance you have enabled gfx.webrender.compositor.force-enabled? If so, does disabling solve the issue?

Comment 14

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

(In reply to Robert Mader [:rmader] from comment #13)

Gregory, any chance you have enabled gfx.webrender.compositor.force-enabled? If so, does disabling solve the issue?

I do see the flickering too. I wonder why because the popup is smaller than toplevel window and we're supposed to use wl_suburface which are resized without hide/show sequence. Will look at it this week.

Comment 15

[Gregory Pappas [:gregp]]

(In reply to Robert Mader [:rmader] from comment #13)

Gregory, any chance you have enabled gfx.webrender.compositor.force-enabled? If so, does disabling solve the issue?

I have not enabled gfx.webrender.compositor.force-enabled.

Comment 16

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

I see the flickering back to 99/100, changelog from mozregression is:

https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=bc1aed5ba113eff5be89837fa44a8a3978772978&tochange=bad8853d0c215d636a2d58526a1a4013f3c22c8e

Looks like we enabled animations or so? But I'm confused why we see flickering on Wayland while X11 works ok. Window log doesn't show any hide/show sequence for the popup so it looks like painting issue. Maybe related to background clearing we use on Wayland for transparent popups?

Comment 17

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

Seems to be caused by SW partial rendering. There isn't any artifacts/flickering when RenderCompositorSWGL::RequestFullRender() return always true, i.e. we request full render. It may be variant of Bug 1792568.

Comment 18

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

Lee, does RenderCompositorSWGL full render when window size is changed? I'd expect so.

Comment 19

[Lee Salzman [:lsalzman]]

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

Lee, does RenderCompositorSWGL full render when window size is changed? I'd expect so.

Glenn might know more about how window size changes are reflected in invalidation?

Comment 20

[Glenn Watson [:gw]]

I'm not aware of anything specific that we do to handle window size changes. We rely on the display list itself changing (for example, when the window resizes, it would change the dimensions of the background color rects, and various other elements, which implicitly then cause invalidations in the affected parts of the window).

Comment 21

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

I see, Thanks. On Wayland when window size is changed, we need to repaint whole window because Wayland does not preserve any part of the window during change like X11. AFAIK it's the same as GL double buffering.

Comment 22

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

This one is caused by mismatched container/widget sizes and missing updates when wayland surface size changes. I managed to fix it but it needs some polishing.

Comment 23

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

Attachment: Bug 1813407 Get widget size only once in RenderCompositorSWGL r?lsalzman

• Get widget size in RenderCompositorSWGL::BeginFrame() and save it for further use. That prevents flickering/artifacts if compositor widget size is changed during rendering.
• Request full screen update when widget size changes on Wayland.

Comment 24

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

Attachment: Bug 1813407 [Linux] Allow to initialize WindowSurfaceProvider with GtkCompositorWidget for OMTC rendering r?emilio

Depends on D169905

Comment 25

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

Attachment: Bug 1813407 [Linux] Get window size from compositor widget if possible in WindowSurfaceWaylandMultiBuffer backend r?emilio

• We want to get window size from compositor widget as it matches window size used by parent RenderCompositorSWGL rendrer.
• For main thread rendering mCompositorWidget is not available so get window size directly from nsWindow.

Depends on D169906

Comment 26

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

Attachment: Bug 1813407 [Linux] Remove unused nsWindow::GetMozContainerSize() r?emilio

Depends on D169907

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f99d85efb04c
Get widget size only once in RenderCompositorSWGL r=lsalzman
https://hg.mozilla.org/integration/autoland/rev/61c79624c2ab
[Linux] Allow to initialize WindowSurfaceProvider with GtkCompositorWidget for OMTC rendering r=emilio
https://hg.mozilla.org/integration/autoland/rev/aba3e370a587
[Linux] Get window size from compositor widget if possible in WindowSurfaceWaylandMultiBuffer backend r=emilio
https://hg.mozilla.org/integration/autoland/rev/897b95c7fdad
[Linux] Remove unused nsWindow::GetMozContainerSize() r=emilio

Comment 28

[Serban Stanca [:SerbanS]]

Backed out for causing Linux bp-hybrid bustages in WindowSurfaceProvider.h.

• Backout link
• Push with failures
• Failure Log
• Failure line: /builds/worker/checkouts/gecko/widget/gtk/WindowSurfaceProvider.h:47:19: error: unknown type name 'GtkCompositorWidget'

Comment 29

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

Updated, Thanks. try: https://treeherder.mozilla.org/jobs?repo=try&revision=7d4139e7381a25930c539a76dc37447044e8d7f0

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5053092fce43
Get widget size only once in RenderCompositorSWGL r=lsalzman
https://hg.mozilla.org/integration/autoland/rev/8392cae054d1
[Linux] Allow to initialize WindowSurfaceProvider with GtkCompositorWidget for OMTC rendering r=emilio
https://hg.mozilla.org/integration/autoland/rev/d57b1b2adb5d
[Linux] Get window size from compositor widget if possible in WindowSurfaceWaylandMultiBuffer backend r=emilio
https://hg.mozilla.org/integration/autoland/rev/a85ff6a754ef
[Linux] Remove unused nsWindow::GetMozContainerSize() r=emilio

Comment 31

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/5053092fce43
https://hg.mozilla.org/mozilla-central/rev/8392cae054d1
https://hg.mozilla.org/mozilla-central/rev/d57b1b2adb5d
https://hg.mozilla.org/mozilla-central/rev/a85ff6a754ef

Comment 32

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

The patch landed in nightly and beta is affected.
:stransky, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox111 to wontfix.

For more information, please visit auto_nag documentation.

Comment 33

[Daniel Bodea [:danibodea]]

I would like to verify this fix, but Ubuntu 22 opens Firefox with x11 by default.
In the past, we could force open it with wayland, but this no longer seems to work.

To force-open Fx with wayland:

1. Open a terminal and navigate to the build directory folder.
2. type in: export MOZ_ENABLE_WAYLAND=1
3. then type in: ./firefox
   Firefox would open in wayland Window Protocol.

Is there another way to force-open Firefox using wayland Window Protocol in order to attempt verification of this fix? Thanks!

Comment 34

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

(In reply to Bodea Daniel [:danibodea] from comment #33)

I would like to verify this fix, but Ubuntu 22 opens Firefox with x11 by default.
In the past, we could force open it with wayland, but this no longer seems to work.

To force-open Fx with wayland:

1. Open a terminal and navigate to the build directory folder.
2. type in: export MOZ_ENABLE_WAYLAND=1
3. then type in: ./firefox
   Firefox would open in wayland Window Protocol.

Is there another way to force-open Firefox using wayland Window Protocol in order to attempt verification of this fix? Thanks!

You need to run in one piece to make MOZ_ENABLE_WAYLAND=1 effective, i.e.:

MOZ_ENABLE_WAYLAND=1 ./firefox

or use 'export' command to export MOZ_ENABLE_WAYLAND to current shell, i.e. run:

export MOZ_ENABLE_WAYLAND=1
./firefox

Comment 35

[Daniel Bodea [:danibodea]]

I have managed to force-open Firefox Release v111.0 and v111.0.1 with wayland Window Protocol on a different system. The issue has quite a low reproduction rate as it was reproduced twice while stressing different websites for about 15 minutes. I wonder what triggers it...

To verify this fix I insisted on reproducing it in Beta v112.0 (RC) for about 30 minutes with no result. I consider this fix verified, although I am not very confident with this result.