DoH provider text is hard to read in system dark mode when the option is disabled

VERIFIED FIXED in Firefox 68

Status

()

defect
P1
normal
VERIFIED FIXED
4 months ago
2 months ago

People

(Reporter: Fanolian+bugzilla, Assigned: ke5trel)

Tracking

(Blocks 1 bug, Regression, {nightly-community, regression, reproducible})

68 Branch
Firefox 68
Unspecified
Windows
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox66 unaffected, firefox67 unaffected, firefox68 verified)

Details

Attachments

(5 attachments)

Posted image DoH option disabled

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Build ID: 20190503215639

Steps to reproduce

  1. Enable Windows 10 system dark mode in Windows Settings > Personalization > Colors > Choose your default app mode > Dark.
  2. Navigate to Nightly's DNS over HTTPS option.
  3. Uncheck Enable DNS over HTTPS.
  4. Observe the text in the menulist of Use Provider.

Actual result

The text is so faint. (Please refer to the attached screenshot)

Expected result

Either the text is more readable but still conveying the option is disabled, or omit the text when the option is disabled.

Notes

This may be a general bug regarding the dark mode for in-content pages. But I cannot find another example with this issue in about:preference.
Privacy & Security > Content Blocking > Custom has similar menulists. I guess the text is omitted when the option here is disabled. (Screenshot in next comment)

Another example in about:preference with menulist disabled.

When the option is disabled, the text (Only in Private Windows) is either omitted or completely unreadable. The dropdown chevron is still there.

Has Regression Range: --- → yes
Has STR: --- → yes
Regressed by: 1545242
Posted image menulist light mode

Menulist comparison in system light mode.

The changes from bug 1545242 should not have affected the other disabled dropdowns in Preferences. Can you please re-check the regression range using the disabled Trackers dropdown?

Flags: needinfo?(Fanolian+bugzilla)

Just to confirm comment 3, all bug 1545242 did was add the menulist for DoH providers and allow for it to be disabled or not. There was 0 CSS changed, and limited markup changes so if there's a dark-mode contrast issue there, the same should be true for any disabled menulist in the preferences subdialogs (or perhaps all in-content menulists)

It looks like while we're picking up the disabled-state's background color of -moz-Dialog, the foreground/text color's value is provided by an color: inherit!important which does not account for the disabled state. I'll try and untangle this.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #3)

The changes from bug 1545242 should not have affected the other disabled dropdowns in Preferences. Can you please re-check the regression range using the disabled Trackers dropdown?

The Trackers dropdown was introduced in bug 1501985. Before bug 1545242, Trackers/Cookies should be the only dropdowns in about:preferences that can have a disabled state.

I did not mean bug 1545242 changes other dropdowns' behaviour. Rather the (style of the) dropdown introduced in bug 1545242, i.e. DoH provider name, is not consistent to those that were introduced before, e.g. Trackers/cookies dropdowns.

In disabled state:
DoH provider: Dropdown label is still present. In dark mode it is barely noticeable.
Trackers/Cookies: Dropdown label is missing.
I attached a screen recording showing the dropdown label for Trackers being omitted when disabled, but not for DoH providers. (The barely noticeable label is lost due to video compression.)

Since Trackers/Cookies dropdowns are the only reference point, my questions are:

  1. Should all disable-able dropdowns in about:preferences share the same behaviour, regarding the label in disabled state particularly?
    1. If no, this bug (bug 1549142) is about making the disabled DoH providers label more noticeable in dark mode.
    2. If yes, should the label be visible in disabled state?
      • If yes, this bug is about making the disabled DoH providers label more noticeable in dark mode. A following regression bug for bug 1501985 should be filed to change Trackers/Cookies dropdowns.
      • If no, this bug is about making the DoH label disappear when the option is disabled.

Thank you.

Flags: needinfo?(Fanolian+bugzilla) → needinfo?(jaws)

All disabled dropdowns in about:preferences should share the same behavior. The label should be visible in the disabled state, though it should have a "disabled" appearance, usually that is a lighter text though in the case of "dark" mode we will need to make sure the "lighter" text still has enough contrast.

Flags: needinfo?(jaws)

Tim, can you investigate this?

Flags: needinfo?(ntim.bugs)
Priority: -- → P1
Assignee: nobody → ke5trel
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Unspecified → Windows
Attachment #9063816 - Attachment description: Bug 1549142 - Prevent the in-content menulist background color from being overriden when control is disabled on Windows → Bug 1549142 - Prevent the in-content menulist background color from being overridden when control is disabled on Windows

Looks like Kestrel is already on this, thanks Kestrel!

Flags: needinfo?(ntim.bugs)
Keywords: checkin-needed

Pushed by aiakab@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f5d5fc68b739
Prevent the in-content menulist background color from being overridden when control is disabled on Windows r=dao

Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68
Flags: qe-verify+

I've reproduced the initial issue on Windows 10 x64 using Firefox 68.0a1 (buildID: 20190503215639).
I tested on Windows 10 64-bit and Windows 10 32-bit using latest Nightly 69.0a1 (2019-06-12) and Firefox 68 Beta 9 (set "browser.in-content.dark-mode"= true to have dark mode for in-content pages): DoH provider text is now readable in system dark mode when the option is disabled (the label is visible in the disabled state and has "disabled" appearance, a lighter text).

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.