Open Bug 1567791 Opened 1 year ago Updated 9 days ago

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

Categories

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

70 Branch
Desktop
Linux
defect

Tracking

()

Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- disabled
firefox70 --- disabled
firefox72 --- disabled
firefox73 --- disabled
firefox74 --- disabled

People

(Reporter: sdk, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: nightly-community, regression)

Attachments

(1 file)

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.

Component: Untriaged → Menus

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?

Flags: needinfo?(contact)

I still see it on the same build.

(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)

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

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

(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.

Flags: needinfo?(contact)

(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.

Flags: needinfo?(contact)

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!

(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 ;).

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.

Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(daniel.bodea)
Flags: needinfo?(contact)

(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?

Component: Menus → Graphics
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(aosmond)
Product: Firefox → Core
Regressed by: 1549965

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?

OS: Unspecified → Linux
Hardware: Unspecified → Desktop
Flags: needinfo?(daniel.bodea)

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

Blocks: wr-linux
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P2

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.

(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.

(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. ^^

(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.

  1. 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.

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

Component: Graphics → Graphics: WebRender

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!

Attached file Copy of about:support

Thanks!

Summary: Highlight in popup menus is broken → Highlight in popup menus is broken (with bspwm or gfx.xrender.enabled)
Flags: needinfo?(jmuizelaar)

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.

Summary: Highlight in popup menus is broken (with bspwm or gfx.xrender.enabled) → Highlight in popup menus is broken with non-compositing window manager or gfx.xrender.enabled

(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.

See Also: → 1479135

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.

Flags: needinfo?(aosmond)

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.

You need to log in before you can comment on or make changes to this bug.