1720543 - (ColorDialog) [meta] Color dialog fixes and improvements

Status: NEW

(Firefox :: Disability Access, defect, P3)

Description

[Morgan Reschenberg [:morgan]]

The color dialog (about:preferences > Language & Appearance > Colors) doesn't effectively communicate customisation options to users, and those customisation options aren't consistently respected by the browser.

Let's fix it!

I think this project will have a few phases, and we should get consensus on functionality before design or engineering changes are made.
Here's where things stand currently:

Dialog contents:

• Color selection for foreground, background, visited/unvisited links
• Checkbox for underlineing links
• Checkbox for using system colors
• Dropdown for enabling/disabling forced colors (HCM)

Dialog functionality:

• Users are able to select colors using their native color picker. Making a selection writes a value to browser.display.foreground_color, browser.display.background_color, browser.anchor_color (unvisited links), browser.visited_color for the respective colors.
• Checking or unchecking the underline links box sets browser.underline_anchors to the respective value
• Checking or unchecking the system colors box sets browser.display.use_system_colors
• Selecting an option in the dropdown causes the value of browser.display.document_color_use to change. This isn't very intuitive, since the dropdown labels essentially indicate the opposite of what gets written to the pref. Here's what happens:
  • "Always" > browser.display.document_color_use = 2 = Never
  • "Never" > browser.display.document_color_use = 1 = Always
  • "Only when using a High Contrast theme" (this option is called "auto" in the page markup) > browser.display.document_color_use = 0 = Only when an OS-level HCM is not enabled

Dialog Effects:

• If the "use system colors" checkbox is checked: background, foreground, and unvisited link colors are pulled from PreferenceSheet.h. Visited link color, however, is styled with whatever color the user set for visited link color in the dialog.
• If the "use system colors" checkbox is unchecked:
  • If the dropdown is set to Always AND the user's OS-level HCM is NOT enabled: the user's chosen background, foreground, visited, and unvisited colors are used to style content.
  • If the dropdown is set to Always AND the user's OS-level HCM is enabled: the user's chosen visited and unvisited link colors are used, but the background and foreground colors are pulled from PreferenceSheet.h.
  • If the dropdown is set to Never AND OS-level HCM is NOT enabled: the user's chosen background and foreground are used, but visited and unvisited are pulled from PreferenceSheet.h
  • If the dropdown is set to Never AND OS-level HCM is enabled: Everything is pulled from PreferenceSheet.h
  • If the dropdown is set to Only with High Contrast themes AND OS-Level HCM is NOT enabled: the user's chosen colors are used
  • If the dropdown is set to Only with High Contrast themes AND OS-Level HCM is enabled: the user's chosen visited and unvisited link colors are used, but the background and foreground colors are pulled from PreferenceSheet.h.

TODO: worth noting I'm testing on Mac right now -- I'll update when I have a chance to test on windows. I don't have access to a linux machine unfortunately :( so if someone wants to verify on there, that'd be great

I think some of the behavior above makes sense, but it might make more sense to respect the system colors checkbox independent of the user's HCM choices, so:

• If the "use system colors" checkbox is checked: all colors are pulled from PreferenceSheet.h
• If the "use system colors" checkbox is unchecked: use the user's selected colors

TODO: Does any OS have the ability to supply system colors such that checking "use system colors" styles the page with something other than the colors in PreferenceSheet.h? I can't find where that overriding would happen in our codebase, if it was possible. MacOS (verified) does not. If the behaviour I'm seeing is standard, we may want to rename this checkbox to "use default colors" or something more semantic.

On the topic of semantics, I think we should also consider untying these options from each other. This dialog allows a user to customise colors AND browser behaviour in a few different ways:

• Change the default colors, but allow pages to override them as they like. This demonstrates a weak preference.
• Change the default colors and do NOT allow pages to override them -- force all colors. (this is a strong preference by default in the sense that you can't say "I'd like to require link colors to ALWAYS be X and Y, but I only have a weak preference that background and foreground are A and B" -- maybe we should consider adding this though?)
• Override all colors with those chosen through the operating system, including colors for which the preferences dialog does not allow customisation (ie. windows lets you select a color for form controls, mac supplies an accent/highlight color).
• Override background, foreground, visited, and unvisited colors with the selections in this dialog, and override any OTHER colors the operating system allows.

To make these options more clear, we might want to annotate the colors section with text that says something like: "You can customise the colors Firefox uses below, note that pages may override your selections. If you'd like to require these colors, select "always" in the dropdown below".

We could add similar text to the default/system colors checkbox, or we could add a button that says "restore defaults" (it'd write the PreferenceSheet.h values back into the color selectors -- if we go this route, we could pull from the color selectors by default and avoid special handling when no OS-level HCM is detected).

ANYWAY thanks for reading this if you made it this far. TLDR; the colors dialog allows users to modify behaviour and color, but this isn't super clear. It also is currently inconsistent in its application of preferences. We should fix it.

Comment 1

[Morgan Reschenberg [:morgan]]

test case that's useful for visualising all the setable colors on one page if you've visited google before: data:text/html,<a href="https://google.com">I am a visited link</a><br><a href="">I am an unvisited link</a><br>Hello world

Comment 2

[Eitan Isaacson [:eeejay]]

Wow thanks for this writeup. This is so complex. If we don't fix the prefs matrix, at least we should hide most of this from users.

I think the "weak" default color preferences should be eliminated and not exposed as an option in a UI.

Good reasons for this:

1. Modern web content almost always makes explicit fg/bg/link/visited color selections via CSS. fg=black, bg=white, link=blue, visited=purple are a de-facto standard. For example, and author might not make an explicit selection for all colors, they might assume common defaults like black-on-white and might set a color of text to a dark grey. If the user chose "weak" inverted default colors, like white on black, the text will be ineligible because the background will be black.
2. With the introduction of color schemes the browser will use different colors altogether when color-scheme: dark. The current settable color set is only applicable in light schemes.
3. Users who want a customized color experience would benefit a lot more from web extensions that allow much higher granularity in styling with CSS origin, specificity and domain-aware tweaks (eg. dark reader).

Comment 3

[Eitan Isaacson [:eeejay]]

Attachment: Screenshot from 2022-10-19 12-32-15.png

Here is a proposed UI change: Remove the "Colors" section in Preferences and replace it with a "High Contrast" section. The section has a brief explanation of what high contrast mode is, and then a three button radio group:

1. Use platform settings (browser.display.document_color_use=0 and browser.display.use_system_colors=true)
2. Off (browser.display.document_color_use=2 and ui.use_standins_for_native_colors=true)
3. Custom (browser.display.document_color_use=1)

The Colors dialog button will only be enabled when "Custom" is selected, and it will only contain 4 color pickers with no other options.

I have no creative ability, but this obviously could look different like the combined radio/controls in the enhanced tracking protection section where the color choosers would be in the "Custom" section.

Comment 4

[Eitan Isaacson [:eeejay]]

Attachment: Screenshot from 2022-10-19 12-33-36.png

Comment 5

[Eitan Isaacson [:eeejay]]

Comment on attachment 9299346 [details]
Screenshot from 2022-10-19 12-33-36.png

This screenshot shows the pared down colors dialog that only contains 4 color pickers for text, background, unvisited link, and visited link.