1764939 - Clarify the affect color dialog selections have on default colors

Status: RESOLVED WORKSFORME

(Firefox :: Settings UI, task, P3)

Description

[scenariobug9]

Attachment: The selected color for "Background" leaks even setting "Override the colors specified by the page with your selections above" to "Never".mov

[Affected versions]:

99.0.1 (64-bit)
101.0a1 (64-bit)

[Affected Platforms]:

macOS 10.13.6

[Steps to reproduce]:

1. Open "Settings".
2. Open "Colors" under "Language and Appearance".
3. Choose a color for "Background".
4. Set "Override the colors specified by the page with your selections above" to "Never".
5. Click the "OK" button.
6. Click "hamburger menu".
7. Click "Add-ons and themes".

[Expected Results]:
When the page jumps, the selected color for "Background" doesn't show up.

[Actual Results]:
When the page jumps, the selected color for "Background" shows up.

[Notes]:

• Not only do Step 6 and Step 7 sometimes have this behavior, but also some other pages jump.
• When right-clicking the page, click "View Page Source". The background of the source is the selected color for "Background".

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey Morgan, I suspect this is less about about:preferences, and more about the underlying system for color overrides... do you know what component that fit into?

Comment 2

[Morgan Reschenberg [:morgan]]

This is a layout (specifically PreferenceSheet) thing.

The color inputs in that dialog affect our browser.display.*_color preferences, which are the prefs we pull colors from when we aren't using system colors, and we aren't using standins. Based on our current dialog UI, it's fair for a user to assume that if they aren't using system colors AND have the dropdown set to 'Never' that we'll use some other palette to paint web content. I guess that palette would be standins?

:emilio what're your thoughts here?
I think the general issue is that we understand that dropdown to control FF HCM -- which encompasses both color and style changes -- and users read it as a big enable/disable switch across all the color options in that dialog.

I don't have a particular opinion on whether or not we should expose the ability to use standin colors as part of this dialog -- it'd be easy enough to add a check for (browser.display.document_color_use != 1) in that conditional I linked above (or in the mUseStandins init). I do think we should reword the string above the dropdown to indicate it controls FF HCM specifically. But changing about:preferences is always a bigger undertaking than it seems.

Comment 3

[Morgan Reschenberg [:morgan]]

Also, FWIW, I don't think this is a regression.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Yeah, this is expected. If you have "Use system colors" unchecked, we use the preference colors. The override dropdown is only about whether we allow the page to override them, but defaults are still the pref ones. Not sure what's unexpected about this?

Comment 5

[Morgan Reschenberg [:morgan]]

I think the confusion stems from the fact that we aren't communicating that the colors chosen in this dialog also affect the default values of background/foreground/link color used for unstyled web content. The dropdown text says "Override the colors specified by the page with your selections above [Always, Never, Only with High Contrast Themes]", so selecting "Never" might imply that instead of using the colors in this dialog, we'd use whatever (immutable) defaults the browser supplies. We aren't doing that right now.

EDIT: Ah we do say they affect defaults -- on the preferences page itself "Override Firefox's default colors for text, website backgrounds, and links". I still think this could be clearer, but do have explainer text somewhere.

Comment 6

[Emilio Cobos Álvarez [:emilio]]

Well, the point is that there's no immutable defaults, there's only defaults, which the colors dialog reflects and allow you to change... But yeah maybe it's more of an issue about it being worded too subtly.

Comment 7

[Morgan Reschenberg [:morgan]]

Yeah agreed. I'm gonna reopen this, because I think it's an important data point in the "we need to redesign the colors dialog" effort.

Comment 8

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

The bug 1898096 has enforced selecting "Custom Colors" in order to proceed with the custom color selection and it also included the following on-screen clarification text preceding this choice (strings source):

Contrast Control
Websites have a variety of foreground and background colors. Configure Nightly to use the same colors across websites for improved readability.
[radio] Automatic (use system settings)
[radio] Off
[radio] Custom [next to it a button] "Manage Colors..."

Also, the section above the "Contrast Control" - "Website Appearance" gets the following status bar:

Your contrast control settings are overriding website appearance.

It seems to me this is probably resolves the issue described in this bug. WDYT, :scenariobug9?

Comment 9

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

Attachment: Nightly 142.0a1 Settings UI with Contrast Control being split from Website appearance and Font and with updated description text

Comment 10

[BugBot [:suhaib / :marco]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:mstriemer, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.