1692685 - The context menu and menubar menus on the one hand, and hamburger menu on the other, look different on GNU/Linux

Status: NEW

(Toolkit :: Themes, enhancement)

Description

[Andrei Petcu]

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

Steps to reproduce:

Enable all the proton flags:

browser.proton.appmenu.enabled
browser.proton.enabled
browser.proton.tabs.enabled
browser.proton.toolbar.enabled
browser.proton.contextmenus.enabled

On GNU Linux with default Adwaita theme (the light variant)
Install a dark theme for example this one https://addons.mozilla.org/en-US/firefox/addon/dark-fenix/

Open the main menu and the context menu

Actual results:

They have different colors

Expected results:

All Firefox menus should have the same background and text colors.

Comment 1

[Andrei Petcu]

Attachment: DuckDuckGo — Privacy, simplified. — Firefox Nightly_044.png

Comment 2

[Andrei Petcu]

Attachment: DuckDuckGo — Privacy, simplified. — Firefox Nightly_042.png

Comment 3

[Andrei Petcu]

Even if I switch to Adwaita Dark they still look different. It's not only the colors, there are other aspects also like the selected item. I need to pick a Firefox theme that matches my GTK theme or the other way around if I want all my Firefox menus to look the same.

Comment 4

[:Gijs (he/him)]

Does this problem not happen without the proton flags?

Comment 5

[Andrei Petcu]

It happens without the flag, that is why I marked as an enhancement, not a bug. It looks fine on windows but not GNU/Linux. Just wanted to make sure this does not slip by.

Comment 6

[Andrei Petcu]

To be clear: Proton seems to fix it on Windows (I only saw print screens on Windows)

Comment 7

[:Gijs (he/him)]

:ntim, I guess this is about whether webextension styling affects the context menu vs. the main menupanel. I don't think it's proton-related and we won't have time to address it as we are already having to figure out how to handle the previously-identified scope. Do you know if this is already on file?

(In reply to petcuandrei from comment #6)

To be clear: Proton seems to fix it on Windows (I only saw print screens on Windows)

Not really - based on your screenshots, assuming that the hamburger panel colour is a result of your Firefox theme (not the OS theme), the theme could make the background of the panel any colour, and we don't currently use the same colour for the context menu, even on Windows. We've only made it so the context menu is (a fixed combination of) light-text-on-dark-background for themes that match certain brightness criteria (which has similar results for Firefox themes that use very dark / black backgrounds for the main window, and includes Firefox's OS dark mode handling on Windows). AIUI dark mode handling on Linux is... difficult... because there's no clear way to identify which themes are supposed to be "dark", as they mix light and dark colours for different UI elements. :ntim knows more about that.

Comment 8

[Tim Nguyen :ntim]

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

:ntim, I guess this is about whether webextension styling affects the context menu vs. the main menupanel. I don't think it's proton-related and we won't have time to address it as we are already having to figure out how to handle the previously-identified scope. Do you know if this is already on file?

I'm not sure if there's any bug on file, but what's possible here is checking the popup, popup_text, etc. properties are set (a[lwt-popup] attribute could be added at https://searchfox.org/mozilla-central/rev/899bbd9e5a0d6de9bb9f068c48b1445c7905d9cf/toolkit/modules/LightweightThemeConsumer.jsm#82 ). Then writing custom CSS for context menus that targets [lwt-popup] and uses the the relevant theme CSS variables. That would fix Andrei's case of the context menu not matching the webextension theme.

This is actually much easier to do on Windows, since there's already custom CSS for context menus (since proton), which can just use the pre-existing CSS variables.

AIUI dark mode handling on Linux is... difficult... because there's no clear way to identify which themes are supposed to be "dark", as they mix light and dark colours for different UI elements. :ntim knows more about that.

The difference between macOS/Windows and Linux detection is that macOS/Windows provides us a flag saying "this theme is dark", whereas this is auto-detected on Linux via luminance calculation on a certain platform color. In this case, dark mode detection isn't so much the problem though.

Comment 9

[Andrei Petcu]

I think the core of the issue is that context menu and main menu pick up colors from different places. It's like refresh button using Firefox Theme colors while the back button would picknup system theme colors.

Is this by design? Is this desirable? If it's hard to implement I get it but if it's by design, I don't.

Windows seems to have advantages regarding this, is gtk hard to work with and inject css for the context menu?

Comment 10

[Tim Nguyen :ntim]

(In reply to petcuandrei from comment #9)

Windows seems to have advantages regarding this, is gtk hard to work with and inject css for the context menu?

Right now, context menus are styled using native APIs rather than CSS. On Windows, Proton switched to using CSS instead (which gives flexibility, but also slightly more bugs, as the list of follow ups show). I think once the followups are figured out on Windows, adding custom CSS for Linux is not so hard.
The task itself isn't so hard, it's mostly figuring out the edge cases right which takes time, and finishing the Windows Proton context menu follow ups would help with that.

Andrei, if you'd like to give it a try at having a work in progress, feel free to play around with this file: https://searchfox.org/mozilla-central/source/toolkit/themes/linux/global/menu.css

The menu.css changes in https://phabricator.services.mozilla.com/D104466 can be a good starting point (though without the Windows specific-bits).

Feel free to let me know if you need any guidance (I'm on Matrix as ntim and here as well).

Comment 11

[Andrei Petcu]

Would love to help but currently I want to finish up some about:logins work.

Comment 14

[Rob Wu [:robwu]]

Resetting for triage; this is not an issue with the theming API of extensions; it seems that the theme was only implemented on Windows in bug 1682522.

Comment 15

[:Gijs (he/him)]

This was a deliberate decision - the context menu work was only ever going to affect Win10 and macOS, as in both cases our menus either did not match native ones (macOS) or there was no useful idea of what "native" meant (Windows 10). It so happens that for Windows 10, we chose styling that is similar to (but not identical to) the styling we use for panels.

Neither of these applies on Linux - we're honouring GTK themes and that was that. I don't think it makes sense to track it in relation to proton - as noted in comment #4 / comment #5, menus and panels have always been different, also before proton. On macOS and Windows 7/8, they are still different, and people are mostly, AIUI, happy about this. It's not clear to me that overriding people's GTK theme on Linux would actually be perceived as a good thing.

Comment 16

[Mr. Beedell, Roke Julian Lockhart]

Indeed, I also do not believe that overriding of the GTK style would be desirable. However, I had interpreted the request to be that the panel context menus adhere to the style of the host DE as well as the secondary-action the context menus. That, certainly for me, would be desirable. I don't know why Firefox chooses to use two different types of context menus for each type rather than merely standardize both with widget.gtk.native-context-menus.

Comment 17

[Danny Colin [:sdk]]

I don't know why Firefox chooses to use two different types of context menus for each type rather than merely standardize both with widget.gtk.native-context-menus.

All context menus (right-click) use the gtk theme and styling. Regular menus (left-click) as pointed out previous were already following the app design system before Proton.

Comment 18

[Mr. Beedell, Roke Julian Lockhart]

Yeah, [e-mail], I haven't contested whether that's true. I'm suggesting that changing that should be the focus of this bug, since I don't understand whatsoever why such distinction would be useful for the user since no other software does so, and since this isn't even consistent with left-click drop-downs invoked by HTML controls.