1892053 - Firefox's "Override the colors specified by the page with your selections" settings label doesn't quite match the reality of what the feature does

Status: REOPENED

(Firefox :: Settings UI, defect, P3)

Description

[u753186]

Attachment: firefox-bug.html

Steps to reproduce:

Create a new clean profile.
In the Settings -> General -> Colours -> Manage Colours dialog, set "Override the colours specified by the page with your selections above" to "Always".
Ensure the visited and unvisited link colours in the above dialog are set to distinctive colours from the text and background colours
Visit the attached HTML file.

Actual results:

The following links in the attached HTML file are displayed correctly using the user defined link colours:

• Visited Link No Style
• Unvisted Link No Style
• Visited Link color: #888
• Unvisited Link color: #888

The following links are displayed in the text colour instead of the appropriate link colours:

• Visited Link color: inherit
• Unvisited Link color: inherit

Expected results:

All links should have been displayed in the appropriate link colours.

Comment 1

[u753186]

According to my testing with mozregression GUI the bug does not appear in "mozilla-central build: 2024-03-01" but does appear in "mozilla-central build: 2024-03-02".

Comment 2

[Daniel Holbert [:dholbert]]

Thanks for the bug report. I can reproduce the behavior-difference between 2024-03-01 and 2024-03-02, using latest Nightly on Linux (Ubuntu 22.04).

Push log for that range is:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=af32c3581b958ea86afab3e8d3b020fef3c794ec&tochange=8b7beaff4b9647b085c7b169353400a0d8b38cde

From that range, the new behavior you're reporting would be from this commit:

Emilio Cobos Álvarez — Bug 1882709 - Honor CSS-wide keywords in forced-colors mode. r=dshin

The "CSS-wide keywords" referenced there are a few special keywords that include inherit (also unset, initial, revert).

Previously we were ignoring those values when specified as colors, when you force pages to use your chosen colors; but apparently we need to honor them in order for GitHub to work, per bug 1882709 (which in this case means your testcase's color:inherit declaration is now honored and does successfully inherit the regular text color).

Closing as INVALID since this is working-as-intended; though if this is breaking some real-world content in a way that's not broken in other similarly-configured browsers, please let us know. Thanks!

Comment 3

[u753186]

I'm not sure how this bug can be rationalized as "working-as-intended", as it clearly is not. The "Override the colours specified by the page with your selections above" option when set to "Always" is no longer always overriding the colours specified by the page.

I'm not aware of any other browser except the now dead Internet Explorer that had a similar colour override feature, but I'm not sure why it should be necessary to demonstrate the lack of this bug in other browsers. Firefox is the problem here, and Firefox is now not displaying links in the correct colours with this setting enabled on "real-world" web sites like Tom's Hardware and The Verge.

Comment 4

[Daniel Holbert [:dholbert]]

Strictly speaking: Firefox is still overriding the colors specified by the page, but not overriding "inherit" (which is not a color -- just an expression of intent that an element should use the same color as its parent, whatever color that is).

(In reply to Ross Ridge from comment #3)

Firefox is now not displaying links in the correct colours with this setting enabled on "real-world" web sites like Tom's Hardware and The Verge.

That breakage is useful to know, thanks. I'll reopen. (On the flip side: with the old behavior, text was completely invisible under certain configurations at GitHub, which is also not-great and what motivated the change, per bug 1882709)

emilio, see above; do you have ideas for how to roll back this change that would fix these sites without breaking the GitHub use-case?

Comment 5

[Emilio Cobos Álvarez (:emilio)]

This "override colors" feature has a spec, it's in here and we follow that.

FWIW you can emulate this mode on any OS in Chrome and Edge using DevTools, and they behave like we do.

It seems like the behavior comment 0 is expecting is something like what would be achieved by having a user style like:

:any-link { color: LinkText !important; }
:any-link:visited { color: VisitedText !important }
/* optionally: * { forced-color-adjust: initial !important } */

Or so. That's trivial to do as an extension, but I don't think we should do it by default.

I think this is not a core bug, per se. This is working as intended. That said, I'd argue that our color dialog UI is, indeed, a bit confusing... If only, because pages can opt out of this behavior themselves by using something like forced-color-adjust: none.

So we should probably reword the settings UI to not be so strict (or adding another setting to "really really force them please").

Comment 6

[Daniel Holbert [:dholbert]]

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

That said, I'd argue that our color dialog UI is, indeed, a bit confusing... If only, because pages can opt out of this behavior themselves by using something like forced-color-adjust: none.

So we should probably reword the settings UI to not be so strict (or adding another setting to "really really force them please").

--> Updating the bug summary to reflect this new encapsulation of the problem-to-be-fixed here.

Comment 7

[Daniel Holbert [:dholbert]]

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

FWIW you can emulate this mode on any OS in Chrome and Edge using DevTools, and they behave like we do.

I just tested this, and it seems Chrome/Edge don't actually behave like we do on the testcase here (though that's not to say they're better).
They both render every link in the attached testcase as the same "link" color (regardless of visitedness, and regardless of color:inherit styling). This ends up meaning that they render sites from comment 3 with visually-distinguishable links, where we don't.

(Specifically, I tested Chrome 126dev on Ubuntu 22.04, with "Rendering | Emulate CSS media feature forced-colors" set to "forced-colors:active", and I tested Edge 124 on up-to-date fresh Windows 11 installation, with a High Contrast Theme activated in the Windows settings.)

emilio: do you know if there's another configuration where Chrome/Edge behave more like us? Is it worth filing a bug on them, or perhaps you're aware of changes on-the-way there?

Comment 8

[Daniel Holbert [:dholbert]]

(I also captured a screenshot showing how this affects The Verge articles. More details in bug 1892277 comment 3. It is pretty annoying over there, unfortunately, if there are links that the user wants to visualize in the article body.)

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I see inherit working as expected on this link if you specify a system color in an ancestor:

data:text/html,<html style="color: CaptionText">text<div style="color: inherit">text-inherit</div><a href="" style="color: inherit">link-inherit</a><br><a href="" style="color: captionText">link-explicit</a><br><a href="">link-no-rules</a>

So it seems like a blink bug off-hand?