1567791 - Highlight in popup menus is broken with non-compositing window manager or gfx.xrender.enabled

Status: RESOLVED DUPLICATE of bug 1574746

(Core :: Graphics: WebRender, defect, P2)

Description

[Danny Colin [:sdk]]

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

Steps to reproduce:

1. Open Firefox Nightly
2. Click on the Hamburger Menu
3. Hover over items in the menu

Additional notes:

• I've tested it in a fresh profile
• It also happens on any other popup menu (e.g Three dots pageAction)

Actual results:

The hover styling is applied on the wrong item.

Expected results:

The hover styling should be applied on the item that cursor is on.

Comment 1

[Pascal Chevrel:pascalc (PTO until April 26)]

I can't reproduce with Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0 ID:20190721215935, Danny do you see the problem in that same build?

Comment 2

[Jagan]

I still see it on the same build.

Comment 3

[Pascal Chevrel:pascalc (PTO until April 26)]

(In reply to Jagan from comment #2)

I still see it on the same build.

Do you have webrender enabled? Is your graphics backed X11 or Wayland? (I don't have the bug with X11)

Comment 4

[Jagan]

Yes, I have webrender enabled and it is on X11.

Comment 5

[:Gijs (he/him)]

Reporter: Would you be able to run mozregression ( https://mozilla.github.io/mozregression/ ) to figure out when this broke?

Comment 6

[Danny Colin [:sdk]]

(In reply to Pascal Chevrel:pascalc from comment #1)

I can't reproduce with Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0 ID:20190721215935, Danny do you see the problem in that same build?20190721215935

Yes, I can see that problem in build 20190721215935.

(In reply to Pascal Chevrel:pascalc from comment #3)

Do you have webrender enabled? Is your graphics backed X11 or Wayland? (I don't have the bug with X11)

Webrender isn't enabled and I use X11.

Comment 7

[:Gijs (he/him)]

(In reply to :Gijs (he/him) from comment #5)

Reporter: Would you be able to run mozregression ( https://mozilla.github.io/mozregression/ ) to figure out when this broke?

This would still be useful, especially because other folks can't reproduce.

Comment 8

[Daniel Bodea [:danibodea]]

I have also attempted to reproduce this issue on AMD FX 8320 with AMD Radeon RX 550 video board, on the exact same build (ID: 20190721215935). This being said, I cannot regress this issue without being able to reproduce it.

Danny, We need your help with the investigation on this issue; more exactly, we need you to regress the introduction of the issue using the mozregression tool:

1. Install mozregression:
   1a. Open terminal.
   1b. Install python 2 by command: sudo apt-get install python-pip (works for Ubuntu; don't know which Linux version you are having)
   1c. Actually install mozregression by command: sudo pip2 install -U mozregression
2. You need to find a build that does reproduce the issue (ID: 20190721215935) and one that does not:
   2a. Use the command: mozregression --launch yyyy-mm-dd (where "yyyy-mm-dd" is the notation of a certain date) to launch a Nightly build from any date you choose; This is how you can find a build that does NOT reproduce the issue, data that you need for your regression.
3. Use the following command to start running a regression:
   mozregression --good yyyy-mm-dd --bad 20190721215935
   (but replace "yyyy-mm-dd" with the date found to be a build that does not reproduce the issue.)
   3a. Now the mozregression tool will search for archived builds on the server, download them and launch them one-by-one on your PC. You need to verify whether the issue reproduces on each of them and then, in terminal, write "good" if the issue does not reproduce and "bad" if the issue does reproduce on the opened build.
   3b. Finish the process of checking builds; it might take a while depending on how apart are the good and bad builds that were input.
   3c. When the bisection is finished, the useful data will be found in the terminal. Copy-paste the last few lines inside this bug.

Please feel free to ask any questions about the regression process. I hope you can complete it considering that I cannot reproduce it.

Thank you for your contribution!

Comment 9

[Danny Colin [:sdk]]

(In reply to :Gijs (he/him) from comment #5)

Reporter: Would you be able to run mozregression ( https://mozilla.github.io/mozregression/ ) to figure out when this broke?

Oh sorry I completely missed your comment :/. I'll run mozregression as soon as I can and keep you posted ;).

Comment 10

[Danny Colin [:sdk]]

Here's the output of mozregression

19:12.13 INFO: Narrowed inbound regression window from [53af1841, 284dca34] (3 builds) to [a4daa44c, 284dca34] (2 builds) (~1 steps left)
19:12.13 INFO: No more inbound revisions, bisection finished.
19:12.13 INFO: Last good revision: a4daa44cdb9cd0ab8a1870a4105ff8f9103c193e
19:12.13 INFO: First bad revision: 284dca344fcc2736acc3c2d8bc54befea0a8ce73
19:12.13 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a4daa44cdb9cd0ab8a1870a4105ff8f9103c193e&tochange=284dca344fcc2736acc3c2d8bc54befea0a8ce73

PS.: Thank you Daniel for the instructions.

Comment 11

[:Gijs (he/him)]

(In reply to Danny Colin [:sdk] from comment #10)

Here's the output of mozregression

19:12.13 INFO: Narrowed inbound regression window from [53af1841, 284dca34] (3 builds) to [a4daa44c, 284dca34] (2 builds) (~1 steps left)
19:12.13 INFO: No more inbound revisions, bisection finished.
19:12.13 INFO: Last good revision: a4daa44cdb9cd0ab8a1870a4105ff8f9103c193e
19:12.13 INFO: First bad revision: 284dca344fcc2736acc3c2d8bc54befea0a8ce73
19:12.13 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a4daa44cdb9cd0ab8a1870a4105ff8f9103c193e&tochange=284dca344fcc2736acc3c2d8bc54befea0a8ce73

Thanks! :aosmond / :jrmuizel, can you take a look please?

Comment 12

[Darkspirit]

Which desktop environment and distribution are you both using?

(In reply to Danny Colin [:sdk] from comment #6)

Webrender isn't enabled and I use X11.

If you open about:support, what does "Compositing" say?

Comment 13

[Darkspirit]

Btw, I can reproduce this bug with Nightly/WebRender on KDE/X11/Debian Testing if gfx.xrender.enabled is true.

Comment 14

[Darkspirit]

For me, this is only reproducible with

• WebRender + XRender + GPU Process.
• Basic + XRender + layers.gpu-process.allow-software;true (non-default)

It does not occur with OpenGL + XRender + GPU Process.

But Danny (comment 0) states this would happen with a fresh profile of Nightly 70, WebRender is probably enabled like it is for Jagan (comment 4).
(Hidden pref gfx.webrender.all.qualified enables WebRender. gfx.webrender.all/enabled can be used to force-enable WebRender).
Danny told in a different bug he's using the i3 window manager.
The other known i3 problem is bug 1514148.

Comment 15

[Danny Colin [:sdk]]

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #14)

But Danny (comment 0) states this would happen with a fresh profile of Nightly 70, WebRender is probably enabled like it is for Jagan (comment 4).
(Hidden pref gfx.webrender.all.qualified enables WebRender. gfx.webrender.all/enabled can be used to force-enable WebRender).

It also happens when Webrender is disabled. See comment 6. However turning layers.gpu-process.enabled to false remove the issue.

Danny told in a different bug he's using the i3 window manager.

Which bug? Most be an old one because I use bspwm.

Comment 16

[Darkspirit]

(In reply to Danny Colin [:sdk] from comment #15)

It also happens when Webrender is disabled. See comment 6.

The background is: Too often people think WebRender is still off when seeing "gfx.webrender.enabled" is false, but in many cases it's only disabled after setting gfx.webrender.force-disabled to true and restarting Firefox. I tried to confirm this by asking you in comment 12.
Unfortunately bspwm doesn't seem to work out of the box for me.

1. Please run mozregression --launch 2019-07-26 --pref gfx.webrender.force-disabled:true -a about:support
   "Compositing" should contain "Basic". Are you able to reproduce the bug?
2. Run mozregression --launch 2019-07-26 --pref gfx.webrender.force-disabled:true layers.acceleration.force-enabled:true -a about:support
   "Compositing" should contain "OpenGL". Are you able to reproduce the bug in this case?

Which bug? Most be an old one because I use bspwm.

You mentioned both in bug 1568373 comment 0 three days ago, i3 at first, so I quoted that. ^^

Comment 17

[Danny Colin [:sdk]]

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #16)

The background is: Too often people think WebRender is still off when seeing "gfx.webrender.enabled" is false, but in many cases it's only disabled after setting gfx.webrender.force-disabled to true and restarting Firefox. I tried to confirm this by asking you in comment 12.
Unfortunately bspwm doesn't seem to work out of the box for me.

Oh I didn't know there was a force-disabled preference and my apologies I didn't see your comment the first time. I got a lot of notifications lately!

1. Please run mozregression --launch 2019-07-26 --pref gfx.webrender.force-disabled:true -a about:support
   "Compositing" should contain "Basic". Are you able to reproduce the bug?

There's no bug if compositing is set to basic.

2. Run mozregression --launch 2019-07-26 --pref gfx.webrender.force-disabled:true layers.acceleration.force-enabled:true -a about:support
   "Compositing" should contain "OpenGL". Are you able to reproduce the bug in this case?

There's no bug with the menu highlight effect. However, the menu is inside a black box. I should mention that I don't use a window compositor.

Comment 18

[Darkspirit]

Thank you! ;) Confirmed as only happening with WebRender.

Comment 19

[Darkspirit]

As a last step, please run mozregression --launch 2019-07-26 -a about:support, click on "Copy text to clipboard", paste it into a text file and upload it here (Attach File) to document your graphics hardware/driver/feature situation. Thanks!

Comment 20

[Danny Colin [:sdk]]

Attachment: Copy of about:support

Comment 21

[Darkspirit]

Thanks!

Comment 22

[Darkspirit]

In display settings I disabled KDE's compositor, logged out and in and see both bugs now too.
bug 1479135 wants to address black borders.

Comment 23

[Darkspirit]

(KDE, but without compositor)
Since when is a different than the actually hovered main menu entry shown as hovered?
mozregression --good 2018-03-01 --bad 2018-10-01 --pref gfx.webrender.all:true layers.gpu-process.enabled:true

6:15.31 INFO: Last good revision: dd386b5b9fa7f5cd6dc4bbbfa0503b3eb2969af5 (2018-07-24)
6:15.31 INFO: First bad revision: 02c8644c45b1f143263d30d769d86c2d1058812e (2018-07-25)
6:15.31 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dd386b5b9fa7f5cd6dc4bbbfa0503b3eb2969af5&tochange=02c8644c45b1f143263d30d769d86c2d1058812e

Other builds are gone. These seem relevant:

4b73b8c7240859ef2587a99cc1f1523c58bbddb2 Martin Stransky — Bug 1406533 - Remove hack for remote popup windows on Linux, r=karlt
89b8c49481b207f0496212c2aaf1a86b26f5be3c Martin Stransky — Bug 1406533 - Don't force in process rendering for transparent (popup) windows, r=lsalzman
0cfb908b2ccffb69ad600b44bb4a4152eac3b5e4 Martin Stransky — Bug 1406533 - Configure compositor widget to shape X11 window on non-compositing WM, r=lsalzman
6a9aeec308180e51bbee9319703b098c4053240f Martin Stransky — Bug 1406533 - Implement a way to transfer shape option from nsWindow to WindowSurfaceX11Image, r=lsalzman
6af61c29b5497d864fd7c1ceac0084590b097218 Martin Stransky — Bug 1406533 - Create and apply XShape mask at WindowSurfaceX11Image, r=lsalzman

Basic is unaffected by default.
OpenGL uses the GPU process, but is unaffected as it uses OpenGL widgets (black borders: bug 1479135).
WebRender uses the GPU process, but because of https://hg.mozilla.org/mozilla-central/rev/a99a53c8f13d main menu and identity panel are Basic widgets (and show this bug), while WebExtension popups are WebRender widgets (black borders: bug 1479135).

It could be fixed by loosening the restriction a bit and always using WebRender for shaped widgets (or for "widgets other than the context menu") on X11. Then, only bug 1479135 (black borders) needed to be fixed, but not this "shaped Basic within GPU process" bug.

Comment 24

[Darkspirit]

As long the Sync icon is spinning there is no bug. Otherwise it's like an event is only processed when the next event occurs.
If you hover menu entries A, B, C, B, A, then A is shown as hovered when hovering B, B when hovering C, C when hovering B, B when hovering A.

Comment 25

[Darkspirit]

Open KDE settings > Display > Compositor and uncheck the box to enable Compositor on startup. Restart KDE. Open Firefox with gfx.webrender.all;true and hover main menu entries.

Comment 26

[u589248]

I am seeing a similar issue: when I hover my mouse over the drop-down, hamburger menu, none of the entries are highlighted when I hover over them with my mouse. Additionally, clicking the entries does not produce an immediate response.

All this started when I switched to using the Wayland back-end via the environment variable: MOZ_ENABLE_WAYLAND=1 .

I am on the stable release, v74.0.1, I have acceleration enabled via env var MOZ_ACCELERATED=1, and WebRender enabled via pref. I am using the Archlinux distribution and the KDE plasma-wayland session. My machine has an Intel processor with integrated graphics.

Comment 27

[Darkspirit]

KDE Wayland bugs are tracked by bug 1609115. This sounds like bug 1584845. Please use only https://nightly.mozilla.org for trying out Firefox' Wayland backend (bug 1543600).

Comment 29

[Darkspirit]

bug 1574746 will fix this and makes WebRender's (gfx.webrender.all) behavior the same as of previous OpenGL (layers.acceleration.force-enabled).