1740850 - about preferences ignores users' color choices when selecting custom colours and "always override"

Status: NEW

(Firefox :: Settings UI, defect, P2)

Description

[MarjaE]

Attachment: I get a gray background with Firefox set to use a white background and "Always" override

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

Opened about:preferences

Searched folo "Color."

Set background color to white.

Set override to "Always."

Actual results:

Since Firefox 57, I've been unable to scroll about:preferences owing to the non-scrolling sidebar. bug 1658601.

Unfortunately that's even worse if I set my own colors for other screen readability issues. bug 1691138.

Now If I set Firefox to use a white background and various text colors, and overide page styles, ("Always" in the menu), about:preferences gets a medium-gray background with no contrast between the main section and the sidebar.

If I set it not to override page styles, ("Never" in the menu), it gets a white background with no contrast between the main section and the sidebar.

Expected results:

I wouldn't mind if it set some kind of visual separation between the sidebar and the main section, to enable scrolling for the first tme since Firefox 56.

But it doesn't.

It looks like the default colors are white backgrounds for both. And if users instruct Firefox to "Always" use white backgrounds for contrast or other reasons, it substitutes medium-gray backgrounds for both.

Comment 1

[MarjaE]

Attachment: I get a white background with Firefox set to use a white background and "Never" override

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Preferences' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[MarjaE]

The old color bugs go back to 57.

The new one goes back to https://phabricator.services.mozilla.com/D125271

Bug 1728187

Comment 4

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

Set release status flags based on info from the regressing bug 1728187

Comment 5

[Timea Cernea [:tbabos][inactive]]

Reproduced this issue as well on MacOS 10.15. on the latest Firefox Nightly 96.0a1 (2021-11-14). Thanks for reporting this issue and going through the mozregression process as well.

Comment 6

[:Gijs (he/him)]

Marja: I understand this is really frustrating and I'm sorry that Firefox isn't doing what you want here.

What I think is happening here is Firefox treats you setting custom colours and "always" override as "this person wants high contrast styling for Firefox itself" (which is what bug 1728187 did). Your colour preferences still don't affect most of the Firefox UI (ie the toolbar etc. doesn't change colour), but the high contrast mode being enabled does affect the preferences UI. In high contrast mode, we use system colours for the preferences/settings UI. That's where the grey is coming from. This doesn't reproduce for me (I get a white background) but I expect that's to do with the OS, its version and/or the system theme that's in use.

The background is white if you select "never" override because the default background colour in the settings (when high contrast mode or custom user colours aren't enabled) is already white.

Morgan, am I right here? I agree that the behaviour here is confusing but I don't see a good way to fix that. If we try to apply the user-selected colours to background/foreground here, but system colours in other places in the prefs, I expect they are likely to result in contrast issues on borders and/or other UI elements, ie depending on the user-selected colours you wouldn't be able to see some of the things, or the hover/active states or borders would disappear.

Comment 7

[:Gijs (he/him)]

The suggestion in bug 1691138 to invert colours in the sidebar might help here, though I expect in the circumstances it'd be very ugly (grey text on black background).

Comment 8

[Morgan Reschenberg [:morgan]]

(In reply to :Gijs (he/him) from comment #6)

What I think is happening here is Firefox treats you setting custom colours and "always" override as "this person wants high contrast styling for Firefox itself" (which is what bug 1728187 did).

I'd amend this to "Firefox treats you setting custom colours and 'always' override as 'this person wants high contrast styling for page content" which we further interpret as "web content". This is non-obvious from a user perspective, since there isn't a clear delineation between our about: pages and web content like https://mozilla.org. We should consider changing that phrasing (and the rest of the dialog... 😀) to better expectation-set with users.

:Marja, if you're looking to override things in a more uniform way, using your system's high contrast settings with 'only with high contrast themes' or 'always' should help. That tells us you're looking to override Firefox (content and UI) as well as web content. You probably also want to check the "use system colors" box.

In high contrast mode, we use system colours for the preferences/settings UI. That's where the grey is coming from.

I'd argue we should only be doing this with browser.display.use_system_colors set to True. Otherwise, we should be using their color dialog colors/standins/something else. In theory this is something that should Just Work ™️ based on some PreferenceSheet logic. I can look into what's going on there. I wonder if we're using FF-theme colors (dark/light) based on the system theme setting instead of directly using system colors?

Morgan, am I right here? I agree that the behaviour here is confusing but I don't see a good way to fix that. If we try to apply the user-selected colours to background/foreground here, but system colours in other places in the prefs, I expect they are likely to result in contrast issues on borders and/or other UI elements, ie depending on the user-selected colours you wouldn't be able to see some of the things, or the hover/active states or borders would disappear.

Yeah, this is a bit of a tricky one. FWIW, it used to be that we rendered about:preferences with (only) FF HCM colors, including it in that "page content" group. I think that changed when we started supporting prefers-contrast/forced-colors, since those respond to both OS HCM and FF HCM.
Also: we already have this problem -- enabling FF HCM does change the colors we use, suggesting we use some combination of system colors / user-selected colors. In some cases (as you guessed) contrast is actually decreased. I'll attach some examples from macOS.

As far as "what to do"... We should decide what the expected behaviour is here. Should FF HCM affect our about: pages? If no, why is it currently? Regardless, how can we better communicate our expectation to users, so they can make an informed decision when setting that dropdown?

Comment 9

[Morgan Reschenberg [:morgan]]

Attachment: macOS about:preferences, dark mode only

Comment 10

[Morgan Reschenberg [:morgan]]

Attachment: macOS about:preferences, dark mode and "Always" with default colors

Comment 11

[MarjaE]

I stopped using high-contrast themes, and just set colors, because they high-contrast themes don't work better in any apps, and result in no contrast in some other apps.

I tried dark mode, but it's even worse for me.

Comment 12

[:Gijs (he/him)]

(In reply to Morgan Reschenberg [:morgan] from comment #8)

(In reply to :Gijs (he/him) from comment #6)

In high contrast mode, we use system colours for the preferences/settings UI. That's where the grey is coming from.

I'd argue we should only be doing this with browser.display.use_system_colors set to True. Otherwise, we should be using their color dialog colors/standins/something else. In theory this is something that should Just Work ™️ based on some PreferenceSheet logic. I can look into what's going on there. I wonder if we're using FF-theme colors (dark/light) based on the system theme setting instead of directly using system colors?

We're using system colours because there's a prefers-contrast media query that then uses those colours for all in-content pages, and after bug 1728187 that media query now applies in this case (ie "FF hcm"). See this block, among other ones. I thought that this was known and part of the reasoning behind bug 1728187...

I have to admit I find labeling this "FF HCM" confusing, because it's not that intuitive that users selecting non-default background/foreground colours and requesting they override web author colours is equivalent to them wanting higher contrast.

I'd argue we should only be doing this with browser.display.use_system_colors set to True.

I don't think we can currently detect this in a straightforward fashion from CSS, but also, I don't think this would make the behaviour here more intuitive for users, the way the dialog is currently laid out? Ultimately, ISTM there are way too many variables here to present to the user in a straightforward way:

• whether OS HCM is on
• whether we're talking about Firefox-internal pages or webpages
• whether we're overriding colours based on HCM, always or never
• whether the user has configured alternative colours from the default
• whether the user is using system colours instead of custom colours
• whether Firefox-internal pages have CSS activated by OS or FF HCM being enabled

Is there any way to reduce this list without losing expressiveness for users? Am I missing some way in which we could make this more understandable or appear more reasonable?

Comment 13

[Emilio Cobos Álvarez (:emilio)]

FWIW, I think the non-"use-system-colors" codepath will basically never yield the right rendering, IMO. I don't think you can render most websites with just a foreground and a background color... And now we have different color-schemes and such, which makes it even funnier.

But anyways, we could avoid honoring system colors if by checking the pref value here: https://searchfox.org/mozilla-central/rev/1e5b6b30d96e9bd7d63eb22bda6f43cf212b5819/servo/components/style/properties/cascade.rs#426-429 (and in the similar block below).

Whether that's better behavior or not in practice, I just don't know.

Comment 14

[Morgan Reschenberg [:morgan]]

Sorry for the delay -- holiday PTO :)

I think there are a few issues here:

1. The colors dialog doesn't clearly communicate its behaviour (both what it can do and what it currently does) to users.
2. Chrome pages are treated differently than web content. Should they be? If so, how can we better communicate this?
3. Both FF HCM and Windows HCM users should always see styling in forced-colors:active blocks, but should only see prefers-contrast:more/less when appropriate, given their customization. This is tracked in bug 1658796.

We've had a redesign of the colors dialog on the backburner for awhile, ideally when we hire a new a11y frontend engineer, this would be something they take on. I've got a UX meeting on Wednesday where I can raise this and see if we can get design resources.

I've got some info on this locally, but it sounds like it'd be useful to document:
(a) What the colors dialog currently does, and the options it exposes to users for cusotmisation
(b) What we'd like the colors dialog to do, and the options we do/don't want exposed to users

emilio / gijs if you have thoughts on (b) lemme know, I'll clean up my documentation for (a) and post it here in a bit.

Comment 15

[Morgan Reschenberg [:morgan]]

preliminary docs at bug 1720543 and here

Comment 16

[:Gijs (he/him)]

bug 1736218 also seems related here, as UI is likely to end up in a similar place (either the colors dialog or next to the entrypoint or... something).

My understanding is that that bug is likely to be worked on in January/February. It'd probably be useful to ensure we don't do the same work of designing UI for this (and/or making behaviour changes) twice. Morgan, was this on the radar of your discussion with UX already? Or if not, would you mind setting up a sync-up with UX, the relevant engineering folks for the 2022 work (Dão/Amy) and product (Ray F.) to make sure we're not at cross-purposes? :-)

Comment 18

[George R. Goffe]

I filed a duplicate (apparently) of this bug as Bug 1747335.

Additionally, several other "pages" are affected as well. When you type in a mount point like /export/home, the filenames appear to have the same color as the background... which makes them VERY HARD to read. Argh.

George...

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Can you elaborate / post a screenshot / share your exact configuration (including GTK theme if you're on Linux)? The filenames are links, and that doesn't support dark color schemes so it should use the link colors that you set on the preferences page.

Comment 20

[Morgan Reschenberg [:morgan]]

(In reply to :Gijs (back Jan 4, 2022; he/him) from comment #16)

bug 1736218 also seems related here, as UI is likely to end up in a similar place (either the colors dialog or next to the entrypoint or... something).

My understanding is that that bug is likely to be worked on in January/February. It'd probably be useful to ensure we don't do the same work of designing UI for this (and/or making behaviour changes) twice. Morgan, was this on the radar of your discussion with UX already? Or if not, would you mind setting up a sync-up with UX, the relevant engineering folks for the 2022 work (Dão/Amy) and product (Ray F.) to make sure we're not at cross-purposes? :-)

I hadn't seen bug 1736218 -- good to know!

I've had a few conversations with UX folks re: redesigning the colors dialog, but I'm not sure if we have dedicated resources for doing so.
In any case, I'll touch base and set up a meeting.