Closed Bug 1477407 Opened 4 years ago Closed 4 years ago

[Windows] Menu items are not visible in high contrast mode


(DevTools :: General, defect, P1)



(firefox63 verified)

Firefox 63
Tracking Status
firefox63 --- verified


(Reporter: Abe_LV, Assigned: birtles)


(Blocks 1 open bug)



(2 files)

Steps to Reproduce:
Screen capture-

1. Set high contrast. In Windows 10 select 'High Contrast Black' and apply
2. Click on the meatballs menu
3. Observe the menu items

Expected Result:
Menu items should be visible in high contrast mode

Actual Result:
Menu items are not visible in high contrast
This seems like a P1 to me. Brian what do you think? Do we have a solution in mind for addressing this quickly?
Flags: needinfo?(bbirtles)
Priority: -- → P1
I haven't looked into this properly yet -- I suspect it is the same as the Ubuntu theming bug (bug 1477417), i.e. using a system value for the text color but not the background color. That's just mirroring what other doorhangers in Firefox do but I suppose they have some specific handling for high-contrast mode. It might be enough just to hard-code the text color.

For now P1 seems fine.
Flags: needinfo?(bbirtles)
This is reproducible in both Chevron and meatballs door-hanger menu.
I started to look into this and here's what I found.

The fundamental problem is that we're mixing system colors with non-system ones. We have:

  --theme-arrowpanel-background: white;
  --theme-arrowpanel-color: -moz-fieldText;

Now, when we set Windows to high-contrast mode, -moz-fieldText may become white, while the background will remain white. I believe this is the cause of bug 1477417 too.

So, why are we using -moz-fieldText?

Basically, to match the behavior for other menus in Firefox. On a standard Windows install this gives rgb(0, 0, 0) whereas on a default Ubuntu install it gives rgb(60, 60, 60). On Mac, we hard-code the color values some reason.

You can see all the system colors here:

So why are we mixing system and fixed colors? I'm not really sure, but I suspect Firefox was doing it at the time and has since been fixed.

Firefox FE has the advantage that it can use the -moz-windows-default-theme media query to detect if we are in high contrast mode or not. (Naming here is a bit odd. So far as I can tell, that media query basically tells us if we are forcing Windows theme colors or not--and generally that is true when applying a high contrast theme, hence we often use it to switch to using system colors so that high-contrast mode works as expected.)

Unfortunately -moz-windows-default-theme is only available for UA and Chrome stylesheets and doesn't work in DevTools.

Nevertheless, it appears the colors for arrowpanels in Firefox have been tidied up and now look like:

Windows / Linux:

  --default-arrowpanel-background: -moz-field;
  --default-arrowpanel-color: -moz-fieldText;
  --default-arrowpanel-border-color: ThreeDShadow;
  --panel-disabled-color: GrayText;

  --panel-separator-color: ThreeDShadow;
  --arrowpanel-dimmed: hsla(0,0%,80%,.3);
  --arrowpanel-dimmed-further: hsla(0,0%,80%,.45);


  --default-arrowpanel-background: hsla(0,0%,99%,.975);
  --default-arrowpanel-color: hsl(0,0%,10%);
  --default-arrowpanel-border-color: hsla(210,4%,10%,.05);
  --panel-disabled-color: GrayText;

  --panel-separator-color: hsla(210,4%,10%,.14);
  --arrowpanel-dimmed: hsla(0,0%,80%,.3);
  --arrowpanel-dimmed-further: hsla(0,0%,80%,.45);

On the other hand in DevTools we have:


  --theme-arrowpanel-background: white;
  --theme-arrowpanel-color: -moz-fieldText;
  --theme-arrowpanel-border-color: var(--grey-90-a20);
  --theme-arrowpanel-separator: var(--grey-90-a20);
  --theme-arrowpanel-dimmed: hsla(0,0%,80%,.3);
  --theme-arrowpanel-dimmed-further: hsla(0,0%,80%,.45);
  --theme-arrowpanel-disabled-color: GrayText;

Mac overrides:

  --theme-arrowpanel-color: rgb(26,26,26);
  --theme-arrowpanel-border-color: hsla(210,4%,10%,.05);

I think we want to update this to:

  --theme-arrowpanel-background: -moz-field;
  --theme-arrowpanel-color: -moz-fieldText;
  --theme-arrowpanel-border-color: ThreeDShadow;
  --theme-arrowpanel-separator: ThreeDShadow;
  --theme-arrowpanel-dimmed: hsla(0,0%,80%,.3);
  --theme-arrowpanel-dimmed-further: hsla(0,0%,80%,.45);
  --theme-arrowpanel-disabled-color: GrayText;

:root[platform="mac"].theme-light {
  --theme-arrowpanel-background: hsla(0,0%,99%,.975);
  --theme-arrowpanel-color: hsl(0,0%,10%);
  --theme-arrowpanel-border-color: hsla(210,4%,10%,.05);
  --theme-arrowpanel-separator: hsla(210,4%,10%,.14);

I'm not sure why I set --theme-arrowpanel-color to rgb(26, 26, 26) instead of hsl(0,0%,10%) though.
Assignee: nobody → bbirtles
I also verified that Dark mode continues to show the same as before (since it uses fixed colors).
(In reply to Brian Birtles (:birtles) from comment #4)
> I'm not sure why I set --theme-arrowpanel-color to rgb(26, 26, 26) instead
> of hsl(0,0%,10%) though.

It turns out hsl(0,0%,10%) === rgb(26,26,26).

I guess I used rgb(26,26,26) since I just read the value from the computed style I was getting on Mac.
By mixing system colors and non-system colors we can arrive at a situation where
we have white text on a white background when using Windows high-constrast mode
or various themes on Linux.

This patch brings the colors used for DevTools doorhangers into line with the
colors used for arrowpanels elsewhere in Firefox.
Comment on attachment 8995440 [details]
Bug 1477407 - Consistently use system colors to define doorhanger styling; r=jdescottes

Julian Descottes [:jdescottes][:julian] has approved the revision.
Attachment #8995440 - Flags: review+
Pushed by
Consistently use system colors to define doorhanger styling; r=jdescottes
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
I retested this on Windows 10 and 7 with latest nightly. It is verified as fixed. Menu items are now visible in high contrast mode as well.

Test environment:
Version 	63.0a1
Build ID 	20180730100211
Update Channel 	nightly
User Agent 	Mozilla/5.0 (Windows NT 6.1; rv:63.0) Gecko/20100101 Firefox/63.0
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
Duplicate of this bug: 1477417
You need to log in before you can comment on or make changes to this bug.