1653832 - [wayland] nightly gtk3 right click menu flickering

Status: RESOLVED WORKSFORME

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

Description

[Mel]

Attachment: Screencast from 19.07.2020 10:21:27.webm

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Select all text in address bar. Right click it, hover over the entries.
OS: archlinux
DE: gnome
compositor: mutter wayland
GPU: amd rx580 with amdgpu driver
This started happening in nightly builds on 9th of July. And yes, before you even ask, this happens on a fresh profile with no addons.

Actual results:

Hovered entries were flickering.

Expected results:

Hovered entries aren't flickering.

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Darkspirit]

Gnome Wayland, Debian Testing, Intel HD Graphics 630 (KBL GT2), 2560x1440

1. Maximize Window
2. Right click into the address bar and hover entries
3. It's bad if there is an invisible seperator between menu entries, if you hover these seperators, no menu entry gets highlighted, but if you hover menu entries, they begin to flicker.

Yesterday, I hovered an address bar context menu item, it flickered, and at the same time it looked like I was hovering the "Home" button on Twitter.

MOZ_ENABLE_WAYLAND=1 mozregression --good 2020-07-01 --bad 2020-07-18 --pref gfx.webrender.all:true -a https://example.com

21:40.37 INFO: Last good revision: 9d2e5cd8c3c9c728d9d5e027fefd2fd3989b1880
21:40.37 INFO: First bad revision: 2c022fc5b638633885787aa94f1e46a7e6713956
21:40.37 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9d2e5cd8c3c9c728d9d5e027fefd2fd3989b1880&tochange=2c022fc5b638633885787aa94f1e46a7e6713956

2c022fc5b638633885787aa94f1e46a7e6713956 Emilio Cobos Álvarez — Bug 1645773 - Make sure to reflow when author specified borders / backgrounds are changed if we're themed. r=jfkthame

mozregression --repo autoland --launch 2c022fc5b638633885787aa94f1e46a7e6713956 --pref gfx.webrender.force-disabled:true -a https://example.com
Can't repro with Basic on Xwayland.

mozregression --repo autoland --launch 2c022fc5b638633885787aa94f1e46a7e6713956 --pref gfx.webrender.all:true -a https://example.com
Can't repro with WebRender on Xwayland.

MOZ_ENABLE_WAYLAND=1 mozregression --repo autoland --launch 2c022fc5b638633885787aa94f1e46a7e6713956 --pref gfx.webrender.force-disabled:true -a https://example.com
Also reproducible with Basic on Wayland.

MOZ_ENABLE_WAYLAND=1 mozregression --repo autoland --launch 9d2e5cd8c3c9c728d9d5e027fefd2fd3989b1880 --pref gfx.webrender.force-disabled:true -a https://example.com
Last good is fine.

Comment 3

[Jonathan Kew [:jfkthame]]

Recent regression, and visually pretty distracting: we should probably consider backing out the fix from bug 1645773 for now unless we can resolve this.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I can poke... So this is somehow only a wayland issue then, right?

Comment 5

[Emilio Cobos Álvarez (:emilio)]

I think the issue is that when we reflow the popup, the position is updated async in wayland, and probably we get confused about what's under the mouse, which causes the background to change (and reflow again and so on...).

I'll poke at the wayland popup code and try to fix it, but lacking that we may want to specify background color in both the hovered and unhovered menuitems, which would fix it as well.

It's on my long todo list to fix gtk dropdowns so that we can enable author-styled selects on gtk, so this probably helps...

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1653832 - Paper over this bug for now. r=Gijs

This restores menus to their previous state before bug 1645773.
Backgrounds don't disable theming on these widgets on Linux in
particular, so this does the trick for now, I want to dig more.

This is probably worth landing in any case.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

I want to avoid users hitting this for now, so posted a wallpaper. I want to dig more though...

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Jan, do you know how to debug this further? Here's what I know so far...

• The reflows trigger various view-updating and such, but no changes to the position of them as far as I can tell.
• I also don't see any effective layout change neither in the menupopups nor the menuitems. I've looked at pretty much all the members in nsMenuPopupFrame which is where I had expected stuff to go wrong.
• I also don't see any nsWindow::NativeShow/NativeMove/NativeResize while all this flickering happens (which is again a bit surprising).

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/79f4ef63ff9e
Paper over this bug for now. r=Gijs

Comment 10

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/79f4ef63ff9e

Comment 11

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

The leave-open keyword is there and there is no activity for 6 months.
:emilio, maybe it's time to close this bug?

Comment 12

[Emilio Cobos Álvarez (:emilio)]

I should check whether this is still an issue if I back out comment 10, but I'm swamped right now.

Comment 13

[Emil Ghitta, QA [:emilghitta]]

Hi Emilio,

I'm reproducing this flicker on Windows & macOS platforms as well (but on a different context menu) with Firefox 87.0a1 (BuildId:20210204192309).

Should I file a separate bug ?

Screencast (it exceeds bugzilla attachement size limit :( )

Comment 14

[Mel]

(In reply to Emil Ghitta, QA [:emilghitta] from comment #13)

Hi Emilio,

I'm reproducing this flicker on Windows & macOS platforms as well (but on a different context menu) with Firefox 87.0a1 (BuildId:20210204192309).

Should I file a separate bug ?

Screencast (it exceeds bugzilla attachement size limit :( )

Different OS
Different GUI toolkits
Different menu
7 versions of firefox difference
I'd say YES.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Yes. please file a separate bug

Comment 16

[jman]

Attachment: recording.mp4

I think this has regressed in 87.0b1 and 87.0b2 (see attachment).
Until nightly 86.x I didn't experience this issues.

I'm on Debian, Wayland and Sway

Comment 17

[Aidan Harris]

Regression range:

19:07.08 INFO: Narrowed integration regression window from [f838b9f6, e1e5bb1b] (3 builds) to [b0615d05, e1e5bb1b] (2 builds) (~1 steps left)
19:07.08 INFO: No more integration revisions, bisection finished.
19:07.08 INFO: Last good revision: b0615d0577ae4f0ca373b122b74c8da14cb7dc3a
19:07.08 INFO: First bad revision: e1e5bb1b3ccf4021ab9b54a1fd4153ad3ab624c9

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b0615d0577ae4f0ca373b122b74c8da14cb7dc3a&tochange=e1e5bb1b3ccf4021ab9b54a1fd4153ad3ab624c9

Comment 18

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi , As per comment 17 I will update Has Regression Range field accordingly.
Best,
Clara

Comment 19

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

Can you please test latest nightly under Wayland? A new popup handling code landed there.
Thanks.

Comment 20

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

Please re-test with new nightly as it gets another popup fixes.
Thanks.

Comment 21

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

This bug diverted a bit - please file a new one if you have any issue.
Thanks.