1539252 - Firefox on macOS with Dark Mode Enabled applies Light Mode style to form controls, causing contrast issues

Status: RESOLVED WORKSFORME

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

Description

[Sara Soueidan]

Attachment: Firefox's light dropdown background with inherited light text color and contrast issue.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36

Steps to reproduce:

• Create a custom <select> dropdown
• Apply a dark theme to the site. The dark theme will switch the colors on the site to a very light color (e.g. #fff)
• the color will be inherited by the <options> in <select>

Actual results:

Firefox's <select> dropdown uses the light text color (from the custom CSS) but does not apply a dark mode color to the <select> dropdown. This results in a light text on a light background contrast issue which makes reading the <select> content almost impossible.

Expected results:

Like Chrome and Safari, Firefox should apply a dark background color to the dropdown to ensure that the inherited light text (from custom CSS) is visible. OR Firefox should enforce a dark text color on the light dropdown background color to avoid any contrast issues. Chrome enforces a light text color on the dark mode dropdown at all times, which is expected behavior.

Comment 1

[Sara Soueidan]

I forgot to add that I'm on macOS dark mode. Firefox uses a light background color on the select dropdown and uses the inherited light text color from the custom CSS. Chrome and Safari use a dark select dropdown background and enforce a light text color inside it, regardless of custom styles. Chrome and Safari's behavior ensures no contrast issues arise when the user is on dark mode.

Comment 3

[Sean Voisen (:svoisen)]

ni? myself to discuss with product and in upcoming webcompat triage.

Comment 4

[Mats Palmgren (inactive)]

Sara, could you attach a small HTML testcase that demonstrates the issue please?
(or provide an URL that demonstrates the issue)

Comment 5

[Tim Nguyen :ntim]

There's a bit more context on the tweet: https://twitter.com/SaraSoueidan/status/1110621648321941504

Comment 6

[Mats Palmgren (inactive)]

Maybe the problem is that we're building with an old SDK? (bug 1475652)

Comment 7

[Tim Nguyen :ntim]

(In reply to Mats Palmgren (:mats) from comment #6)

Maybe the problem is that we're building with an old SDK? (bug 1475652)

Gecko doesn't use native Cocoa dropdown lists AFAIK. The current implementation tries to emulate the vibrancy and the appearance on the items however: https://searchfox.org/mozilla-central/source/widget/cocoa/VibrancyManager.h#24

I think we'd need to implement it manually on the relevant VibrancyType and return dark vibrancy when dark mode is on.

Anyway, mstange/spohl probably will know more about this.

Comment 8

[Tim Nguyen :ntim]

This might be relevant: https://searchfox.org/mozilla-central/rev/532e4b94b9e807d157ba8e55034aef05c1196dc9/widget/cocoa/VibrancyManager.mm#81

Comment 9

[Cameron McCormack (:heycam)]

Stephen, would it make sense to add a new VibrancyType value that means "LIGHT or DARK depending on the current system theme"? And then return that type for menus in ThemeGeometryTypeToVibrancyType.

Comment 10

[Stephen A Pohl [:spohl]]

(In reply to Cameron McCormack (:heycam) from comment #9)

Stephen, would it make sense to add a new VibrancyType value that means "LIGHT or DARK depending on the current system theme"? And then return that type for menus in ThemeGeometryTypeToVibrancyType.

We might want to stick to the existing light and dark vibrancy types but check the current system theme before assigning them. Unless there is a strong use case for having dark vibrancy when the system is in light mode, and/or vice-versa.

Comment 11

[Cameron McCormack (:heycam)]

(In reply to Stephen A Pohl [:spohl] from comment #10)

We might want to stick to the existing light and dark vibrancy types but check the current system theme before assigning them. Unless there is a strong use case for having dark vibrancy when the system is in light mode, and/or vice-versa.

I wrote a small patch to do that, and it works well for this case.

I am concerned that switching to the dark vibrancy for the menu will result in other sites having illegible menu items, if they have specified explicit dark colors on them. The reason why there is no problem in Chrome and Safari on macOS is that they do not support any custom colors of the <option>s on that platform, and so always use the default system color (white, when in dark mode, black when in light mode).

Comment 12

[Cameron McCormack (:heycam)]

Attachment: screen shot of sheet in dark mode

A related issue is that in macOS dark mode, sheets don't look right. We probably want to choose light or dark vibrancy for the some of the other VibrancyType values too.

Comment 13

[Cameron McCormack (:heycam)]

Split dealing with the other VibrancyType values out to bug 1541723.

Comment 14

[Mike Taylor [:miketaylr]]

From a webcompat perspective, let's revisit when we get more reports or have a better understanding of the scenario.

Comment 15

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

The priority flag is not set for this bug.
:jimm, could you have a look please?

Comment 16

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Comment 17

[Matei Stanca]

Attachment: Dark colour scheme + normalize.css

Comment 18

[Matei Stanca]

Attachment: Dark colour scheme + normalize.css + color: initial

Comment 19

[Matei Stanca]

Hi there. I'm actually encountering a similar issue on Windows 10 in dark mode, in combination with an older version of normalize.css that Drupal core 8.9 ships with which sets color: inherit; on select elements, and so if you have a light color higher up, Firefox uses that with the new-ish user agent styles for form widgets, which also have a light background colour, making them unreadable. A quick workaround for me is to use color: initial; and newer versions of normalize.css have this removed, but I'm wondering if that's relevant to this bug?

Seen in Firefox Developer Edition 90.0b9 (64-bit)
User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0

Comment 20

[Dennis Schubert [:denschub]]

macOS dark mode now works fine in my tests. Since this issue was a generic "it's not working" issue, I'll close this as WORKSFORME.

If you still see case where something is off, please file a new bug with detailed steps, and a testcase - if possible.