Closed Bug 1714149 Opened 3 years ago Closed 3 years ago

Firefox 89.0 on CentOS 7.9 (KDE) - hamburger menu not displaying

Categories

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

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 89
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: ericj, Unassigned)

Details

Attachments

(2 files)

about:support graphics section
9.06 KB, text/plain
Details
about_support_graphics.png
351.33 KB, image/png
Details

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

Steps to reproduce:

After moving from Firefox 88.0.1 to 89.0, the hamburger menu is no longer displaying. Even disabling Proton (browser.proton.enabled = False) does not have an effect.

OS: CentOS 7.9 x86_64
Window Manager: KDE (kde-workspace-4.11.19-16.el7_9.x86_64)

Actual results:

When pressing on the hamburger button, It looks like the outline is displayed, but no contents in that outline.

Expected results:

The hamburger menu should be displayed with the menu contents.

about:support graphics section

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

Can you please use mozregression to find the regressing commit?
How-to is here:
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Use_Mozregression_tool
Thanks.

Flags: needinfo?(ericj)
Priority: -- → P1

Hey, I'm affected by something similar too: I cannot open any menu (the hamburger menu, also the HTTPS lock info thingy in the toolbar, dropdowns in the settings don't show, too). Also, clicking on them hangs the browser for a moment (and I even just encountered a crash when accessing the hamburger menu - might be related)

I tried to use mozregression which interestingly wasn't able to work with 89.0 as a release version. I used

mozregression --good 88.0.1 --bad 20210527174632

but the second spawned (supposed to be broken version) was working on my system. I now tried opening my browser in troubleshooting mode to disable addons and settings, but this is still broken.

Toggling gfx.xrender.enabled from true to false in about:config seems to 'fix' the issue for me. @ericj can you reproduce?

Now used the time for mozregression to test by enabling gfx.xrender.enabled for each version and restarting it (the setting is only effective after a restart if someone tries to reproduce, didn't point this out)

Was this integration build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
 6:39.21 INFO: Narrowed integration regression window from [b608bef3, 5fbe8efb] (3 builds) to [86583083, 5fbe8efb] (2 builds) (~1 step left)
 6:39.22 INFO: No more integration revisions, bisection finished.
 6:39.22 INFO: Last good revision: 8658308399d3a794ca42ac0c55310b6c7f3ac91f
 6:39.22 INFO: First bad revision: 5fbe8efb0aefee517dd48b3a91111e79769b1880
 6:39.22 INFO: Pushlog:
https://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=8658308399d3a794ca42ac0c55310b6c7f3ac91f&tochange=5fbe8efb0aefe517dd48b3a91111e79769b1880

I'm not quite familiar with this tool? Is this information already helpful? I think it's nothing new, only saying that this was introduced between the latest minor in 88.x and 89.0? This was what we noticed, too. Is there a way to test single commits with this method, too? I can try to do so later if you think this is useful.

(In reply to Otto Richter from comment #6)

Toggling gfx.xrender.enabled from true to false in about:config seems to 'fix' the issue for me. @ericj can you reproduce?

Confirmed! Setting gfx.xrender.enabled to false fixes the issue for me as well.

I had this set to true because if you run firefox with X Forwarding (via an SSH tunnel), performance is really bad without it being set to true. So hopefully this can still be fixed because I rely on running firefox like this.

Flags: needinfo?(ericj)

Well, Firefox 89.0 / CentOS 7.9 / KDE is a combination which may be a bit fragile and Red Hat ships ESR lines there by purpose. Also XRender is known to be broken on various X11 drivers.

Flags: needinfo?(stransky)

(In reply to Otto Richter from comment #9)

By the way, here my crash reports in case they are related:
https://crash-stats.mozilla.org/report/index/3cadcd3f-85b6-40c6-af10-6778f0210603
https://crash-stats.mozilla.org/report/index/e33e5eaa-a7aa-4529-96fd-b0fff0210603

Otto, this is completely different bug - a crash in Skia. Please file a new bug against Graphics component and mark it security related.
Thanks.

Flags: needinfo?(bugzilla-mozilla)
Priority: P1 → P3

Well, Firefox 89.0 / CentOS 7.9 / KDE is a combination which may be a bit fragile

Well, I'm using Debian Testing (Bullseye). Since Debian ships with ESR, too, and my settings apparently derivated from the defaults, I understand the lowered prio, but I just wanted to point out that it's not very uncommon to install a more recent Firefox on top of Debian / Testing. I don't know why I changed the xrender thing, but if this is common too, this situation might affect quite some users?

Flags: needinfo?(bugzilla-mozilla)

(In reply to Otto Richter from comment #12)

Well, Firefox 89.0 / CentOS 7.9 / KDE is a combination which may be a bit fragile

Well, I'm using Debian Testing (Bullseye). Since Debian ships with ESR, too, and my settings apparently derivated from the defaults, I understand the lowered prio, but I just wanted to point out that it's not very uncommon to install a more recent Firefox on top of Debian / Testing. I don't know why I changed the xrender thing, but if this is common too, this situation might affect quite some users?

You posted crashes related to skia graphics library, this is not related to XRender (at least not directly).

I have also been able to reproduce this issue on openSUSE 15.2 x86_64 with LXDE (but it does not occur with KDE Plasma on opensuse) (X11). And of course this is with gfx.xrender.enabled = True.

This issue seems to be fixed in 89.0.1. I again set gfx.xrender.enabled = True and confirmed that on openSUSE 15.2 x86_64 with LXDE that the tooltips and hamburger menu are no longer blank.

Otto do you want to give it a try too?

Flags: needinfo?(bugzilla-mozilla)

Yeah, flipping gfx.xrender.enabled to true on 89.0.1 and restarting doesn't bring back the broken menues. Nice.
I think I can't close this, but maybe you?

Flags: needinfo?(bugzilla-mozilla)

(In reply to Otto Richter from comment #16)

Yeah, flipping gfx.xrender.enabled to true on 89.0.1 and restarting doesn't bring back the broken menues. Nice.
I think I can't close this, but maybe you?

Great! Yes this can be closed.

It won't let me close it as RESOLVED/FIXED or RESOLVED/DUPLICATE as I don't know the bugzilla ID that actually fixed it. So I will close it as RESOLVED/INVALID.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID

Firefox 91.0 brought back this issue (although not all users are seeing this, and setting gfx.xrender = False fixes it again). Also exists in 91.0.1. It is causing 'SELECT' input boxes in webpages to not show up (I do not even see an outline of the drop down). But the hamburger menu is OK this time. I am going to open a new bugzilla for this and will reference this one.

(In reply to ericj from comment #19)

Firefox 91.0 brought back this issue (although not all users are seeing this, and setting gfx.xrender = False fixes it again). Also exists in 91.0.1. It is causing 'SELECT' input boxes in webpages to not show up (I do not even see an outline of the drop down). But the hamburger menu is OK this time. I am going to open a new bugzilla for this and will reference this one.

See Bug 1726456 for a similar issue in 91.0+.

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

Attachment

General

Creator:
Created:
Updated:
Size: