1837651 - Contextual menu doesn't follow system theme

Status: UNCONFIRMED

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

Description

[med medin]

Attachment: image171.png

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

Steps to reproduce:

Contextual menu doesn't follow Breeze theme. See attached image for more info.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Theme' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Dão Gottwald [:dao]]

From what I understand and remember, Gtk4 makes it hard / impossible for us to get all the info we'd want to render this stuff perfectly. E.g. right now there's no way for us to set the correct active menu item border as a CSS border, and I don't know that we can use appearance for this either.

Comment 3

[med medin]

(In reply to Dão Gottwald [:dao] from comment #2)

From what I understand and remember, Gtk4 makes it hard / impossible for us to get all the info we'd want to render this stuff perfectly. E.g. right now there's no way for us to set the correct active menu item border as a CSS border, and I don't know that we can use appearance for this either.

But Firefox was using the correct contextual menu a month ago, did something change with latest 114 version ? Did you also adopt the foolish libadwaita idea ?

Comment 4

[Emilio Cobos Álvarez (:emilio)]

This was an intentional change from bug 1828413, see there for context, but tldr:

• Yes, with the Breeze theme (the one in comment 0), native rendering looked fine(-ish, it didn't work correctly with fractional scaling, and not super consistent with the rest of Firefox UI, but it was pretty good).
• But with most other gtk themes (I'd argue including Adwaita), gtk3 menus etc looked a bit out of place with the rest of gtk4 apps, or flat out wrong like the one in that bug.

It is not possible for us to render non-native menus as native perfectly in all themes. What we were doing was a bespoke mix which clearly didn't work correctly across themes, so we changed the rendering to be both more similar to GTK4 and the rest of the Firefox UI.

There's some code to use native context menus under the pref widget.gtk.native-context-menus. It's experimental and it doesn't work properly, but I'd be happy to review patches to improve it, and that should use proper native menus. We use a similar approach in macOS for example.

Comment 5

[med medin]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

• But with most other gtk themes (I'd argue including Adwaita), gtk3 menus etc looked a bit out of place with the rest of gtk4 apps, or flat out wrong like the one in that bug.

So you fixed the look of Firefox to look good on only GNOME desktop while giving zero interest to other desktops.

Comment 6

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

(In reply to med medin from comment #5)

So you fixed the look of Firefox to look good on only GNOME desktop while giving zero interest to other desktops.

What you see is a problem with KDE/Gtk theme integration AFAK.
Is there any difference between Firefox and other Gtk based applications like gedit?
Thanks.

Comment 7

[med medin]

Attachment: Gedit fully respects Breeze theme

Gedit v44.2 fully respects Breeze theme in the contextual menu, app menu, settings window and dialogs.

Comment 8

[med medin]

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

Is there any difference between Firefox and other Gtk based applications like gedit?
Thanks.

Gedit looks fine on Plasma desktop, see attached image.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

So you fixed the look of Firefox to look good on only GNOME desktop while giving zero interest to other desktops.

Not quite, but it's a trade off. I use plasma myself fwiw.

Firefox already never used native menus in literally every other panel (like the hamburger menu etc).

The right fix for this would be to do what macOS does and use native menus properly, but native menus don't (easily) have the capability of rendering some of the kinds of things we want like the back forward buttons in the context menu... I think what we're doing now is the less bad option given the constraints, but I'd be open to improvements to the native menu code that allowed us to enable them by default.

Furthermore, GTK4 removed foreign drawing altogether so all hope of drawing native-like menus that aren't really native there is lost, if/whenever we switch.

Comment 10

[med medin]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)

Furthermore, GTK4 removed foreign drawing altogether so all hope of drawing native-like menus that aren't really native there is lost, if/whenever we switch.

You don't have to switch if things work fine, jumping to something new that will be more restricting is a bad move.

If Firefox wants to use its own contextual menu, then at least it should look like the humberger menu (same background and highlight colors).

Comment 11

[Emilio Cobos Álvarez (:emilio)]

(In reply to med medin from comment #10)

You don't have to switch if things work fine, jumping to something new that will be more restricting is a bad move.

Well, there are fixes that are in GTK4 that aren't backported to GTK3 which cause issues, like bug 1786182 etc...

Comment 12

[med medin]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)
On Plasma desktop, no matter how much I try to convince myself to adapt my eyes to it, that new look of contextual menu is still ugly/inconsistent and out of context.

Comment 13

[med medin]

Well, the current status of how Firefox looks is inconsistent and makes the browser totally non-pleasing to the eyes on non GNOME desktops. So, for us, this is still a valid bug.

Comment 14

[med medin]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)

but native menus don't (easily) have the capability of rendering some of the kinds of things we want like the back forward buttons in the context menu...

Since I started using for 8 years ago I never user those back/forward... in the contextual menu, they are clear visible beside address bar, so adding some redundant buttons to make the whole Firefox design look inconsistent is not logical at all.

Comment 15

[bugzilla]

Same issue here with Firefox looking gratingly mismatched in Plasma. The "System theme -- auto" option (in the "Manage Your Themes" section) seems half-baked as it doesn't apply any colors other than very light gray or very dark gray to the tabs, address bar, and context menus. Why aren't these colors imported from the system theme? (It should certainly be possible since the "Firefox Color" extension has no issue applying color to the tabs and address bar.) Even if you just added a button to "Firefox Color" to import the actual system theme colors, that would be a very good start.

And how about adding a setting to revert to standard context menus that ditch the forward/back/etc. buttons and respect the system theme colors? Disrupting visual integration just to add redundant buttons is a trade-off that many users don't want to make.

Comment 16

[Mr. Beedell, Roke Julian Lockhart (RJLB)]

Attachment: `widget.gtk.native-context-menus: true`

And how about adding a setting to revert to standard context menus that ditch the forward/back/etc. buttons and respect the system theme colors?

widget.gtk.native-context-menus: true would remediate this, if its entries were functional.