VOOZH about

URL: https://bugzilla.mozilla.org/show_bug.cgi?id=1898096

⇱ 1898096 - Introduce Contrast Control Settings

Closed Bug 1898096 Opened 2 years ago Closed 1 year ago

Introduce Contrast Control Settings

Introduce Contrast Control Settings
Firefox
Disability Access
unspecified
Unspecified
Unspecified
enhancement
Points:
---
RESOLVED FIXED
RESOLVED
FIXED
138 Branch
Iteration:
---
a11y-review
Accessibility Severity
Performance Impact
Webcompat Priority
Webcompat Score
Tracking Status
relnote-firefox --- 138+
firefox138 --- fixed
Tracking Status
relnote-firefox
firefox-esr115
firefox-esr140
firefox-esr153
firefox138
firefox152
firefox153
firefox154
---
QA Whiteboard:
---
Has STR:
---
Change Request:
---
Bug Flags:
Signature:
None
This bug is publicly visible. 

 












 
 

 

 
 
 
 
48 bytes,
 text/x-phabricator-request 

 		
 
 
 Details |
 Review
 





 
















The colors section in preferences has been around in one form or another since early web days. It was originally meant to change the colors used in web pages, and precedes CSS. It is very uncommon in on the web today to encounter unstyled content. The ability to change the default colors without high contrast mode does not offer a good experience. Let's rededicate this section to contrast control and offer a straightforward way for users to toggle high contrast and tune it to their needs.





 
 
 
 
 


 
This patch changes the backing prefs by removing

browser.display.use_system_colors and relying on the tristate offered

by browser.display.document_color_use. This simplifies the color

decision tree.


The UI changes are a rough draft of what the preferences could look

like.


Attached above is a WIP. I'm curious if you think this is approach is worthy and something I should refine. To get a quick idea of what I did, I would just look at PreferenceSheet.cpp, the doc changes also give a high level overview. You can also try it :)


Flags: needinfo?(mreschenberg)
Flags: needinfo?(emilio)
So not opposed to this in principle, but this changes our behavior on Linux and macOS to default to system colors, which I don't think it'll be web compatible. In particular, on light mode, Canvas should be white by default and CanvasText black, otherwise you risk silly compatibility issues...




Flags: needinfo?(emilio)
Severity: -- → S4

 

 

 
 
 
 Assignee
 
 
 

 

 
 

 Updated
 

 •
 
2 years ago
 

 		
 

 

 
Type: defect → enhancement
The browser.* color prefs need to be rededicated to HCM exclusively. we should not read those in non HCM mode. we can't use system colors in non-hcm because of Canvas/CanvasText quirks in MacOS. We also cannot use standins because they do not respect system theming for things like accent color. I propose we use a subset of the standins for fg/bg/link/visited.


I refactored PreferenceSheet::Prefs::LoadColors to have 3 branches for color loading


    

  1. no-hcm OR use standins: Use the standin colors for text/bg and link/visited. This changes the current behavior in windows where those colors are retrieved from the system even in non-hcm mode. i don't think this is an issue.
    2. 

  2. hcm explicitly on: use pref colors
    3. 

  3. hcm on via OS settings: use system colors
    4. 



I think I'd expect HCM explicitly on to use system colors? At least when in high contrast mode...




When I say "hcm explicitly on" I mean turning on HCM in Firefox's settings, regardless of OS settings. So in that case we use Firefox's pref colors. If the firefox HCM settings are in "auto", and the OS has HCM, use the system colors.


Yeah, but if the OS has HCM, and HCM is explicitly on, then we should probably still use system colors?


Maybe a better description of these options is "Auto", "Off" and "Custom". The last one turns on HCM explicitly with colors customized in the browser. This allows users finer grained control over the palette. A use case for that would be Mac or Linux users who get a sub-optimal palette from the OS's HCM and want to use a better one in the browser, or a Windows HCM user who might want finer grained control for web content.


Just like right now, Linux and Mac would have "Off" by default, and Windows "Auto".


I'm a fan of this :) thanks for working on it !


Flags: needinfo?(mreschenberg)

 
 

 

 
 

 
 

 
 


 

 
 

 Comment 10
 

 •
 
2 years ago
 

 		
 


 
 


 
 
Newer versions of MacOS reworked the system contrast settings.


Increase contrast now takes light colors, and lightens them more. So if you needed to make outlines, edges, etc. bolder and more visible, it makes them fainter and eventually invisible.


I don't think Firefox should require certain system contrast settings.


(In reply to MarjaE from comment #10)




Newer versions of MacOS reworked the system contrast settings.


Increase contrast now takes light colors, and lightens them more. So if you needed to make outlines, edges, etc. bolder and more visible, it makes them fainter and eventually invisible.


I don't think Firefox should require certain system contrast settings.




The change here allows you to control the contrast settings and colors in Firefox regardless of system palette and preferences. The idea being that this is a very subjective area and web content can behave in all kinds of ways so the user needs better control than simply the OS settings.


Assignee: nobody → eitan
Status: NEW → ASSIGNED

 Attachment #9403081 -
 Attachment description: WIP: Bug 1898096 - Replace color settings with "contrast control". → Bug 1898096 - Replace color settings with "contrast control".
Blocks: 1950995
Pushed by eisaacson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f4d5303f5472
Replace color settings with "contrast control". r=emilio,fluent-reviewers,settings-reviewers,accessibility-frontend-reviewers,morgan,bolsson,masayuki,mossop,pdfjs-reviewers,calixte

 
 

 

 
 

 
 

 
 


 

 
 

 Comment 13
 

 •
 
1 year ago
 

 		
 


 
 


 
 
Backed out for causing ba failures @ browser_attributed_text.js



TEST-UNEXPECTED-FAIL | accessible/tests/browser/mac/browser_attributed_text.js | [["hello ","#000000","#ffffff","undefined","undefined",1,32,null,"undefined"],["world","#0066cc","#ffffff",1,"#0066cc",1,32,"a1","undefined"],["this ","#000000","#ffffff","undefined","undefined","undefined",16,null,"undefined"],["is","#ff0000","#ffff00","undefined","undefined","undefined",16,null,1],[" ","#000000","#ffffff","undefined","undefined","undefined",16,nu



Flags: needinfo?(eitan)
Flags: needinfo?(eitan)
Pushed by eisaacson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/72f28cbd8c22
Replace color settings with "contrast control". r=emilio,fluent-reviewers,settings-reviewers,accessibility-frontend-reviewers,morgan,bolsson,masayuki,mossop,pdfjs-reviewers,calixte
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 138 Branch
Release Note Request (optional, but appreciated)

[Why is this notable]: This revamps a 30 year old feature and adapts it to the modern web.

[Affects Firefox for Android]: No

[Suggested wording]: Rededicate old Colors settings to Contrast Control settings.

[Links (documentation, blog post, etc)]: https://blog.monotonous.org/2025/03/06/New-Contrast-Control-Settings/


Added to 138 nightly release notes and is on track for the final 138 release notes.


Blocks: 1957704
See Also: → 1976118
@eeejay Does browser.display.use_system_colors still remains in the static preference list for Thunderbird and Seamonkey only? As far as I can tell, it is no longer used in Firefox, is that correct?


Flags: needinfo?(eitan)
That is correct. They should probably be removed there.


Flags: needinfo?(eitan)
Oh, I see it is in mozilla-central.. it should probably be removed as a followup, yes.



 You need to log in
 before you can comment on or make changes to this bug.