Found in:

• Nightly 106.0a1

Affected versions:

• Nightly 106.a1
• Beta 105.0b9

Tested platforms:

• Affected platforms: Ubuntu 22.04
• Unaffected platforms: Windows and macOS

Preconditions

• Have High Contrast enabled (Accessibility menu > High contrast).

Steps to reproduce

1. Launch the Firefox browser and enable the Menu Bar.
2. From about:addons enable the Light or the Alpenglow theme.
3. Click on one of the items from the Menu Bar.
4. Hover the other items.

Expected result

• The Menu Bar items are visible.

Actual result

• The Menu Bar items are not visible.

Regression range

• I'll will find a regression as soon as posible.

Additional notes

• Reproducible with Light or Alpenglow theme enabled.
• Screencast attached to observe the issue.

I've reached the following regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=457d764d3379c8757985089511eceae52ca3ef65&tochange=dd10e3373b26a3500b4685f6f37b74f32b7fe280
Potential regressor: Bug 1785904

Set release status flags based on info from the regressing bug 1785904

:dao, since you are the author of the regressor, bug 1785904, could you take a look?

For more information, please visit auto_nag documentation.

Set release status flags based on info from the regressing bug 1785904

Marking access-s3 because items are visible when they are not selected.

I think something to the effect of this diff would fix this:

--- a/toolkit/themes/linux/global/menu.css
+++ b/toolkit/themes/linux/global/menu.css
@@ -68,7 +68,7 @@ menubar > menu:not([open], [disabled="tr
   color: inherit;
 }
 
-menubar > menu[open] {
+menubar > menu[open]:not([_moz-menuactive="true"]) {
   color: -moz-menubarhovertext;
   background-color: -moz-menuhover;
 }

The problem is the menu labels are getting the hover colors when the menu is open - which is not what we want in this case. I don't know off the top of my head if this is the right patch, or what ramifications this change might have elsewhere, but hopefully this will help move things along.

(In reply to Sam Foster [:sfoster] (he/him) PTO until Jan 9th from comment #6)

I think something to the effect of this diff would fix this:

--- a/toolkit/themes/linux/global/menu.css
+++ b/toolkit/themes/linux/global/menu.css
@@ -68,7 +68,7 @@ menubar > menu:not([open], [disabled="tr
   color: inherit;
 }
 
-menubar > menu[open] {
+menubar > menu[open]:not([_moz-menuactive="true"]) {
   color: -moz-menubarhovertext;
   background-color: -moz-menuhover;
 }

From what I can tell a menu that is open will also always have _moz-menuactive set. So it seems like the above would effectively disable that rule entirely?

The problem is the menu labels are getting the hover colors when the menu is open - which is not what we want in this case.

Is it not? What other system color would we use instead? The above change would make us fall back to -moz-menuhovertext, I think, which doesn't seem more correct, except that it would semantically fit with the -moz-menuhover background. It seems odd that -moz-menubarhovertext doesn't seem to have a corresponding background color.

I'll tentatively move this bug over to Widget: Gtk as it seems that we may not have everything we need to do the right thing here.

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

What other system color would we use instead?

How about the background and text colors that are used when Firefox's system them" is used. That one does it correctly.

it seems that we may not have everything we need to do the right thing here.

It worked as intended until FF 105 broke it. And it still works in FF's system theme. It could very well be that the regressor of the duplicate-closed issue 1796122, https://hg.mozilla.org/mozilla-unified/rev/dd10e3373b26a3500b4685f6f37b74f32b7fe280#l1.17, is also the regressor here.

(In reply to cobinja from comment #8)

It worked as intended until FF 105 broke it.

Whether it worked as intended would depend on your OS theme and Firefox theme. There were certainly situations where it wasn't working properly, see bug 1785904 comment 0.