![firefox dark theme fix firefox dark theme fix](https://www.intowindows.com/wp-content/uploads/2017/11/enable-dark-mode-theme-in-Firefox-pic2_thumb.png)
It's a rule of thumb that if you're specifying background color, you should also specify text color, and vice-versa. Illegible text, whether in form fields or elsewhere, is pretty much ALWAYS the designer's (or rather person's who did the CSS work) fault. On the other hand, form fields have always inherited the system-wide look by default. The option to "Use system colors" is NOT checked by default, and it has always been this way.ģ. Content colors are user-managed, and default to black-on-white.
FIREFOX DARK THEME FIX PATCH
Oh, and of course, you could have proposed a patch instead of complaining.Ģ. You know, because fixing "OMG NOTHING WORKS YOU ALL SUCK" is kinda more difficult than fixing "Checkboxes in this particular dialog are illegible when using dark theme, here's a screenshot and more info". The narrower the issue, the more chance you have of it being taken seriously and fixed. Similarly, bug 1425517 is about Calendar (built-in Thunderbird extension), and as such has very little relevance to Firefox.Īnother good thing to do would be to file new bugs if you stumble upon issues which aren't on the record yet.
FIREFOX DARK THEME FIX MAC
For example, this bug seems to have become a catch-all for anything dark_theme-related, and IMO is as good as closed by now anyways, whereas bug 119538 is actually about Firefox for Android, which is a separate product, has nothing to do with GTK, and is irrelevant in any discussion where particular issues on GTK, Windows or Mac are involved. I mean, it's surely the easy thing to do, whereas a much more constructive and useful thing would be to figure out which of these issues are duplicates of each other, or have lost focus over time, and propose merging or closing them. Putting same heated rant in multiple bugs is one good way to achieve two things: a) earn a ban from commenting on this Bugzilla, and b) decrease the likelihood of these bugs being fixed by blurring their scope. <- 17 years old report!!! Still "New"!ġ. Just a few tickets about problems with dark themes, in order: WORKS in pretty much EVERYTHING other than Firefox. Now several parts of the FF GUI have white on white checkboxes or disabled text, and everything in settings is blazing white as well as new tab page.Īll you need to do to fix the websites is to use the widespread defaults instead of system colors to render webpages.īut you can't do this for 17 years for reasons beyond comprehension. I hoped that finally Quantum will fix this. Webpages display partly in system colors causing white on white or black on black text/form elements, while parts of the Firefox UI defy every dark theme and stay eye-bruning white. The fact that Firefox cannot handle dark desktop themes was reported many times FOR SEVENTEEN YEARS. from the CSS3 working draft (not yet finalized)
![firefox dark theme fix firefox dark theme fix](https://www.partitionwizard.com/images/uploads/articles/2020/11/firefox-dark-mode/firefox-dark-mode-5.png)
+ aColor = GDK_COLOR_TO_NS_RGB(mStyle->fg) aColor = GDK_COLOR_TO_NS_RGB(mStyle->text) RCS file: /cvsroot/mozilla/widget/src/gtk/nsLookAndFeel.cpp,v Understand exactly what some of the system colors (e.g., WindowText,ĪppWorkSpace, etc) mean in Windows (since that's where they came from, and the I think if we really want to fix this we need to change some of the ways systemĬolors are used in the Classic skin. Use WindowText on a ThreeDFace background). Was intended for labels rather than large chunks of text) and LCARS (because we The following patch is arguably correct, and it improves the situation in theĭarkMarble theme, but makes it worse in Metal (because it's using a color that Is it a bug that we use the ThreeDFace color as aīackground on things other than buttons?) When buttons went from a single-border raised appearance to a double-border To be equivalent to ButtonFace - the ThreeD* colors were added in Windows 95 (In the Windows system colors, ThreeDFace was defined * there are places where text that is not ButtonText colored is used on a * there are places where -moz-field is used as a background, and it doesn't I think part of the problem is coming from our system color use conventions: To be used for bits of UI, but not the large chunks of text that it's used for (That's generally the problem, I think - that the |fg| color is made |fg| color is the same as the default button background) and Metal (where theĭefault text |fg| color is not really intended to be used for significant chunks It huts some other themes including LCARS (a dark theme where the default text Two places where we used the |text| color (WindowText and an equivalent non-CSSĬolor type) to use the |fg| color, then Darkmarble improves significantly, but
![firefox dark theme fix firefox dark theme fix](https://user-media-prod-cdn.itsre-sumo.mozilla.net/uploads/images/2020-04-30-13-22-40-5dcdd9.png)
![firefox dark theme fix firefox dark theme fix](https://hf-files-oregon.s3.amazonaws.com/hdppolicypak_kb_attachments/2019/03-22/bc12b4fa-db5d-4d23-9c6b-f61b7755c697/2017-10-11_1531.png)
I've experimented a little with what we could do to fix this.