User Agent: Mozilla/5.0 (Windows NT 6.1; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

Have: high constrast enabled on Windows.
Have: force text color: green
Have: force background color: black

Set:
Colors: Override with these colors (always)
Set: use system colors: off
Set: background: black
Set: text: white
Set: links: blue
Set: visited links: purple

Opened cnn.com

Visited links are green

Actual results:

Colors in Firefox were ignored; it tried to impute system colors. I'm not sure where the green visited links came from but it's clearly not what I asked for.

Partial regression from Firefox 69: that green visited links was purple. The resulting green text+green visited links is almost unusable.

Expected results:

Since use system colors was off, the four colors requested should have been used.

OS Versions: Windows 7 and Windows 10 both exhibit bug.

This is presumably a regression from bug 697836 although I didn't actually check this.

Sean, could you help us finding an owner for this regression please? thanks

I am familiar with bug 697836 and could have reported a decade ago. In fact bug 697836 is best fixed by tinkering with monitor brightness and contrast as many programs have the same behavior (including IE until quite recently). But if not, just changing the link and vlink colors always fixed it until this new bug.

This is all a bit of a mess.

When Windows high contrast mode (HCM) is enabled and "Override with these colors" is set to always or HCM, we override the user's colours with the system colours. The idea is that if the user is using Windows HCM, we want to honour the colours specified there so they get an experience consistent with their needs (as specified by the HCM theme).

Before bug 697836, we could do this for some colours (e.g. foreground and background), but not link colours. After bug 697836, we know how to fetch link colours from the system. So, the way we determine link colours is now consistent with the way we determine other colours: we use the HCM theme.

The "Use System Colors" option is only relevant if you do not have Windows HCM enabled.

One option would be to change the functionality of the "Use System Colors" option so that if it is disabled, it also ignores HCM theme colours. The problem with this is that it would break the "default" situation where a user turns on Windows HCM and expects things to be consistent with their HCM theme, since "Use System Colors" is disabled by default.

I wonder if we could rename "Override the colors specified by the page with your selections above" to "Override the colors specified by the page". The three options would then be: "Never", "Using system high contrast theme", "With your selections above". The last option would use the user selections even if Windows HCM is enabled. I think that allows us to leave the default situation alone while still being flexible for use cases like comment 0.

Note also that use System Colors is in the "Text and Background" section, so it's not meant to apply to "Link Colors".

IE's belief about colors

IE's colors in action

OS Colors

I'm not sure you know how to get link color, because the link color isn't green.

As I understand it, Windows HCM themes don't have a way to specify the colour for visited links. Visited link colour is produced by preserving the foreground's green and averaging the foreground and background for the red and blue. Apparently, this is also how IE and Edge do it as well. That said, this clearly doesn't fit with your experience, so I'm not sure what's going on here. Maybe the issue here is that we're doing the averaging using the fg/bg colours you've specified, rather than the fg/bg colours specified by the Windows HCM theme?

I wrote code for this a long time ago. There really is a place where the alink/vlink colors can be stored. You found the "unset" behavior.

The key is HKCU Software\Microsoft\Internet Exploer\Settings with values of "Anchor Color", "Anchor Color Hover", "Anchor Color Visited" which are comma separated RGB strings, and "Use Anchor Hover Color" which is a string saying "yes" or "no". Hilariously, setting these registry values does nothing unless "Custom Colors" exists, which is a REG_BINARY containing a long list of zeros.

But that's for the IE specific settings, not the HCM theme, right? It doesn't make sense for a user to open IE to configure Firefox.

I think you posted the best answer in comment 5 "I wonder if ..." becasue I think it should basically stop second-guessing colors.

Almost everything is set to single-channel colors for light-energy reduction. I should probably minimize use of blues too, but it hasn't quite come to that yet.

(In reply to James Teh [:Jamie] from comment #5)

This is all a bit of a mess.

agree.

The "Use System Colors" option is only relevant if you do not have Windows HCM enabled.

FWIW: I tried turning off HCM on windows, checking "Use System Colors", turning "override these colors, blah blah blah" to always, and then navigating to the same CNN page. I don't get any of my Windows colours reflected in Firefox's HCM. As far as I can tell, this button doesn't do anything? When Windows HCM is off, regardless of that checkbox I get Firefox rendering with the Firefox-specific HCM colours set in prefs.

Also: Where do we get the system colours from for users who aren't on Windows? MacOS doesn't allow users to specify HCM colours, as their HCM is done with colour filters and not per-use colours. If we're keeping this option we might wanna change how we expose it to users (based on OS?) or change the wording if the behaviour does differ across OS's.

One option would be to change the functionality of the "Use System Colors" option so that if it is disabled, it also ignores HCM theme colours. The problem with this is that it would break the "default" situation where a user turns on Windows HCM and expects things to be consistent with their HCM theme, since "Use System Colors" is disabled by default.

This is what I thought it was supposed to do when I first encountered it. If we go this route, I imagine we might want to have it default-enabled for windows users? And maybe grey'd out for Mac users? (disabled)

I wonder if we could rename "Override the colors specified by the page with your selections above" to "Override the colors specified by the page". The three options would then be: "Never", "Using system high contrast theme", "With your selections above". The last option would use the user selections even if Windows HCM is enabled. I think that allows us to leave the default situation alone while still being flexible for use cases like comment 0.

This sounds good to me, but I'm a little confused how this would allow you to do what you can currently do in FF, which is have your OS be non-HCM, but have firefox be HCM. How do these new options reflect that capability?

Where do we get the system colors from for users who aren't on Windows?

On Linux, the GTK colors are used, but see also https://bugzilla.mozilla.org/show_bug.cgi?id=1272332

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

FWIW: I tried turning off HCM on windows, checking "Use System Colors", turning "override these colors, blah blah blah" to always, and then navigating to the same CNN page. I don't get any of my Windows colours reflected in Firefox's HCM. As far as I can tell, this button doesn't do anything? When Windows HCM is off, regardless of that checkbox I get Firefox rendering with the Firefox-specific HCM colours set in prefs.

I think I recall Asa saying that this checkbox only affects the foreground and background colours (not link colours), which kinda sorta makes sense because it's in that section of the settings (but it's still far from intuitive). With all HCm (Firefox and Windows) disabled, I think they get used if the page doesn't specify its own foreground and background colours (e.g. plain HTML with no CSS)?

One option would be to change the functionality of the "Use System Colors" option so that if it is disabled, it also ignores HCM theme colours. > This is what I thought it was supposed to do when I first encountered it. If we go this route, I imagine we might want to have it default-enabled for windows users?

The problem is that we'd be changing the existing default, which is a backwards compat concern maybe?

I wonder if we could rename "Override the colors specified by the page with your selections above" to "Override the colors specified by the page". The three options would then be: "Never", "Using system high contrast theme", "With your selections above". The last option would use the user selections even if Windows HCM is enabled. I think that allows us to leave the default situation alone while still being flexible for use cases like comment 0.

This sounds good to me, but I'm a little confused how this would allow you to do what you can currently do in FF, which is have your OS be non-HCM, but have firefox be HCM. How do these new options reflect that capability?

My idea is that the "With your selections above" option would turn on Firefox HCM regardless of OS HCM. To be specific:

Override the colors specified by the page:

1. Never: No HCM, no override.
2. Using system high contrast theme (default):
   • if Windows HCM enabled, enable Firefox HCM and colour override; use colours from Windows HCM theme.
   • If Windows HCM disabled, no HCM, no override.
3. With your selections above: Regardless of Windows HCM, enable Firefox HCM and colour override; use colours as set in Firefox Options.
   • For colours you can't configure in Firefox, I guess we use the Windows HCM colours if Windows HCM is enabled?

Flagging 1593737 as something that might be worth considering with this; if we're talking about "how should system colours affect HCM", we might also want to think about which system colours we're inheriting and if we should maybe add more (namely the windows ones for button/select).

I checked. There are more than twenty security fixes I am unable to take because I am currently stuck on Firefox 69.

Please find a way to revert to previous method, or at least, a way to adjust link and visited link colors. Even if I have to go edit Windows Edge/IE colors.
I am a vision impaired impaired individual. I have mostly contrast issues.
I use a Windows HC theme that places most text color yellow on black.
I've always set links as a bright 'neon' type green, and visited links a bright 'neon' type 'pinkish-reddish' color.
It works for me very well.
Since 70, all links seem to become blue now. The color Blue that, wherever Firefox now gets it's colors, is difficult for me to focus on quickly.

Sean, this is a regression from Firefox 69 and affects accessibility. Can you help find someone to take this bug for 73? Thanks!

Taking this off tracking and marking P3 based on discussions. We are going to revisit wording in the dialog similar to comment 17 in the near-future.

Here's my assessment on what would need to be done on the backend to complement the new front-end changes:

(In reply to James Teh [:Jamie] from comment #17)

1. Never: No HCM, no override.

Nothing, this is already an option in the menu.

2. Using system high contrast theme (default):
   • if Windows HCM enabled, enable Firefox HCM and colour override; use colours from Windows HCM theme.
   • If Windows HCM disabled, no HCM, no override.

This also exists currently, but I'd argue this shouldn't show up on Mac, where we don't have colours to inherit. Maybe also on linux? I'm not sure what our HCM inheritance from them looks like, or how well it works. Emilio worked on this, I think? :emilio IIRC you have a GTK build somewhere? Do you know what colours are configurable in system HCM there?

To remove this in whatever cases we decide, we should read the platform from AppConstants in main.js (I think) and only add menulist items that are relevant to our platform. Technically, a user could still change things in config but, shrug emoji.
Maybe we also want to grey out the colour boxes above if this is selected, to indicate they're non-functional? It still feels weird to me that they're part of the dialog, and configurable, but this is the "on / off" switch for whether or not they affect the browser.

3. With your selections above: Regardless of Windows HCM, enable Firefox HCM and colour override; use colours as set in Firefox Options.
   • For colours you can't configure in Firefox, I guess we use the Windows HCM colours if Windows HCM is enabled?

This doesn't require changes, unless we wanna address the "what do we do for colours we don't have" thing: I'd advocate for taking stock of what colours Windows and GTK support in their system HCM's and making sure we mirror them here in our options. Specifically, adding support for button/select styling like Windows HCM has would let us do selected/active styling easier, I think? Also, if we replace colours we don't have with windows/gtk colours, we'll still be left with a sub-par mac experience :( so might be good to aim for something platform-consistent
We should probably also make sure our link colouring works the same on all platforms, since I think that was a lingering issue?

(In reply to Morgan Reschenberg [:morgan] from comment #23)
I'm not sure what our HCM inheritance from them looks like, or how well it works. Emilio worked on this, I think? :emilio IIRC you have a GTK build somewhere? Do you know what colours are configurable in system HCM there?

Yes, I do. Technically HCM in GTK is a different theme, so you can configure whatever colors you want. I'd need to look into what the built-in ones do. By default there are two variants ("Dark" and "Light", "Light" being the default). But I'm pretty sure that you can change any GTK color.

Can anyone point me to a reasonably easy method to fix version 70 and above to allow me to update so I can see using them?
Due to my vision impairment, I've stuck to v69 since 70+ is broken.
I use these settings.
In Windows, I use High Contrast setting (I forget, 1 or 2 wouldn't matter though)
In

In version 69, i can see/read every page with little difficulty like below.

Since version 70, anytime I try updating, I have to roll back because I can't view links easily, nor are background images blocked as in 69.

I'm unable to add images or even links to images in my post. Sorry, I'm also unable to edit my old post.

Firefox - Options - General - Language & Appearance:Colors button
https://jamminr.punked.us/bugs/SelectedColorOptions.jpg

Firefox version 69
https://jamminr.punked.us/bugs/GOOD_view_in_v69_and_below.jpg

Firefox version 70 and up to current 8/22/2020
https://jamminr.punked.us/bugs/BAD_view_in_v70_and_above.jpg

Hmm, that seems like it should have been fixed in bug 1617678, which is in Firefox 75... What website is the one from the screenshot? Maybe they're using background-image for their gradients...

In any case, changing browser.display.permit_backplate=false should restore the FF69 behavior exactly.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #28)

In any case, changing browser.display.permit_backplate=false should restore the FF69 behavior exactly.

Thanks for tip - I installed v75 as I had yesterday before rolling back and tried the setting.
It now ignores web page background images like previously. (site was https://forums.ulyssesmod.net - but any site with image backgrounds did same). I'm now closer to using latest Firefox again.

Windows 10 HCM allows setting of non visited Link colors, but unfortunately, doesn't allow setting of visited links. I've always used Firefox to set an off color for me for links, v70 and above do not do that.

Latest FF still ignores the 4 color settings - text, background, but, the visited/non visited links are what I'm most concerned.
No matter what combination of settings I use, be they 'use system' and ('always' or 'in HCM' or 'never'), or disabled 'use system' and ('always' or 'when in HCM' or 'never'), FF75 always uses link color set in Win HCM personalization (defaults to a blue, but I've changed that).

(and, great - now checkbox options no longer appear in v75 vs v68 - i can't tell if i checked 'clear needinfo' or not. - another discussion for another bug)

As of https://phabricator.services.mozilla.com/D104562, this bug also exists in MacOS. And relying on system colors doesn't leave users any way to specify the colors we prefer, or the colors we can most easily distinguish. So it might be a good idea to count this as a cross-platform bug and count bug 1720012 as a duplicate.

I think in light of bug 1720012, and the discussion here, I think we want to set the default for browser.display.use_system_colors to true on windows platforms, where we also set the dropdown default to "only with HCM themes", and false on all other platforms. That'll leave us with a state where:

• On Windows, when a user enables OS HCM, FF will (a) enable FF HCM and (b) inherit its colors from the operating system
• On MacOS and Linux, by default any changes a user makes to background/foreground or link colors in the colors dialog will be reflected in firefox.

As far as why this makes sense to do: It seems like users have different OS-based preconceptions of how HCM is supposed to behave. On Windows, it's expected that enabling HCM at the OS level automatically changes firefox, with no firefox-level preference changes. That doesn't seem to be the expectation on MacOS or linux (as we learned in bug 1713015). Users, simultaneously, expect that customisations in the colors dialog are automatically reflected in firefox without preference changes. This expectation doesn't necessarily come from HCM users, but it does come from users with color-related access needs, and we should be supporting them too. I think the proposed pref defaults above satisfy both of these expectations, at least, to the extent possible (non-HCM users on windows who wish to adjust colors will have to disable 'use system colors' where they previously didn't have to).

TLDR; in light of bug 1713015, I'm inclined to diversify our default prefs rather than standardise them across OSes where expectations are clearly different.

I'm going to pull some data on populations who don't have HCM enabled, but do have custom colors set in about:preferences, I don't have information right now on how big that group is. I think we should base this choice on the number of affected users, so if |windows users with OS HCM enabled and active in FF| > |windows users with no HCM but custom colors| we should change the default, otherwise leave it.

Emilio, I'm interested in your opinion on all this :)
Also flagging Jamie as an FYI/followup from our 1:1 convo yesterday

I'm baffled by this new discussion in light of the bug being fixed on Windows as of the FF release yesterday.

(The rendering broke pretty badly on a different machine that doesn't have a pinned FF version, five minutes into tracking down why I discovered this bug had been fixed without anybody touching the bug and my color settings had garbage in them. If I had seen the bug changed to fixed I would have known in five seconds what happened.)

:jhudson my apologies for not updating this bug sooner.
I think this bug is still valid insofar as there's an outstanding question about expected default behaviour on windows/with windows HCM.

Before the fix on bug 1720012, a windows user could expect their OS-HCM choices to be automatically reflected in firefox because we did not respect the system colors checkbox with windows HCM enabled. That meant, however, from a user perspective, the box was broken -- we didn't indicate that OS HCM had any effect on that preference. Now, by default, a windows HCM user has to go and enable that box before firefox adapts their HCM settings.

As an HCM user yourself, it sounds like you'd expect windows HCM to "just work" with firefox, out of the box, is that accurate?

"As an HCM user yourself, it sounds like you'd expect windows HCM to "just work" with firefox, out of the box, is that accurate?"

Yes I would; but that doesn't say which way to set the box. It could either be set to use windows colors or it could be set to use browser colors with the browser colors set to the windows colors during initialization.

That'll leave us with a state where:

That makes sense to me. That'd mean that users that enable HCM on mac / Linux would've also seen the checkbox. I agree the expected default on windows should probably be to follow OS theme as long as we honor OS HCM by default.

(In reply to jhudson from comment #34)

"As an HCM user yourself, it sounds like you'd expect windows HCM to "just work" with firefox, out of the box, is that accurate?"

Yes I would; but that doesn't say which way to set the box. It could either be set to use windows colors or it could be set to use browser colors with the browser colors set to the windows colors during initialization.

That's an interesting idea.

The reason (historically) we haven't done the latter is because we can't completely represent windows HCM theme colors in firefox -- windows lets you specify highlight color, button background/text, etc. in addition to the four colors we keep track of. We override firefox colors with /all/ the windows theme colors, but a user would only see the four we have in the dialog (so there still might be confusion around "why is my button text this color? don't see it set in about:preferences.")

I think we have a bug open about color parity, though, which could be one way to fix this.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #35)

That'd mean that users that enable HCM on mac / Linux would've also seen the checkbox.

yeah my thinking is if those users are already going out of their way to change the dropdown, they'll know to explore the dialog, whereas users who enable at the OS level might not.

Based on the comments here and conversation elsewhere, this seems reasonable to me. One question, though:

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

I'm going to pull some data on populations who don't have HCM enabled, but do have custom colors set in about:preferences, I don't have information right now on how big that group is. I think we should base this choice on the number of affected users, so if |windows users with OS HCM enabled and active in FF| > |windows users with no HCM but custom colors| we should change the default, otherwise leave it.

Did you end up looking at this data or did this turn out to be infeasible or were there reasons you decided the data wasn't going to be so useful in making this decision?

(In reply to James Teh [:Jamie] from comment #39)

Based on the comments here and conversation elsewhere, this seems reasonable to me. One question, though:

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

I'm going to pull some data on populations who don't have HCM enabled, but do have custom colors set in about:preferences, I don't have information right now on how big that group is. I think we should base this choice on the number of affected users, so if |windows users with OS HCM enabled and active in FF| > |windows users with no HCM but custom colors| we should change the default, otherwise leave it.

Did you end up looking at this data or did this turn out to be infeasible or were there reasons you decided the data wasn't going to be so useful in making this decision?

I did! Its an incomplete analysis, since we only capture telemetry for foreground/background colors, not link colors (or the use system colors checkbox). When I analysed the data on Windows, I found a substantial difference between count(clients with OS HCM enabled) and count(clients with OS HCM disabled AND customised colors) -- the former is much larger. This means by swapping the default here, we'd be requiring the smaller population to alter their preferences, instead of the larger population, which I think is the right move.

:Jamie not sure if I'm allowed to post telemetry stuff here, but I've added it to our a11y dashboard, if you'd like to see :)

Backed out for causing failures at test_default_background.xhtml.

Backout link: https://hg.mozilla.org/integration/autoland/rev/feeaea43b48a62e0422142416dbe0dadb1fd5538

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&selectedTaskRun=ftGBMGAhSby57-ym3v_jUg.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=f2f9361b8e5e4f992620d01fbba50d0ecc5daec9

Failure log: https://treeherder.mozilla.org/logviewer?job_id=351687807&repo=autoland&lineNumber=2248

https://hg.mozilla.org/mozilla-central/rev/6a3fb1d05e29