Native theme does not work on any page




a year ago
a year ago


(Reporter: kr4ssimir, Unassigned, NeedInfo)


55 Branch

Firefox Tracking Flags

(Not tracked)



(2 attachments)



a year ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170614094141

Steps to reproduce:

Go to

Actual results:

Page rendered, but no checkboxes

Expected results:

Checkboxes should be there


a year ago
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Created attachment 8882907 [details]

This is what I see when loading that page.
Can you reproduce the problem also with a recent version of Firefox?

It appears you're using v52 which is obsolete.
Flags: needinfo?(kr4ssimir)

Comment 3

a year ago
Created attachment 8882925 [details]
Bildschirmfoto zu 2017-07-02 23-07-36.png
Flags: needinfo?(kr4ssimir)

Comment 4

a year ago
I could reproduce it with Firefox 54, 54.0.1 and the 55 beta. Had to use the ESR to see checkboxes, but I just found out with a new profile or in safe mode they render

Comment 5

a year ago
I can still reproduce it with my default profile, but all addons, themes and language packs disabled
(In reply to Kr1 from comment #3)
> Created attachment 8882925 [details]
> Bildschirmfoto zu 2017-07-02 23-07-36.png

It looks like the native theme isn't working at all in your screenshot -
even the submit button looks wrong.

(In reply to Kr1 from comment #5)
> I can still reproduce it with my default profile, but all addons, themes and
> language packs disabled

Perhaps you can try copying prefs.js from your default profile to a newly
created profile and see if that breaks the new profile?
If so, just remove lines in that file (in the new profile!) until it
works again and you should be able to find out which line(s) breaks it.

Comment 7

a year ago
Old prefs.js in a new profile doesn't break it. Weird
Last Resolved: a year ago
Component: Untriaged → CSS Parsing and Computation
Resolution: --- → DUPLICATE
Duplicate of bug: 1373417
It's very unlikely this bug has anything to do with MSTHEMECOMPATIBLE
(since it occurs on *all* pages according to the reporter) and is
thus not a duplicate of bug 1373417.  If you read the comments above,
you'll see that the problem occurs due to some setting in
a non-default profile.

I'm interested in knowing what causes this problem.
Component: CSS Parsing and Computation → Widget: Gtk
Ever confirmed: true
Resolution: DUPLICATE → ---
Summary: Checkboxes and Radioboxes are not visible on any page → Native theme does not work on any page
Duplicate of this bug: 1377922

Comment 11

a year ago
Reading about the experiments with the new profile, I replicated the exercise, and found the same thing.  By copying the prefs.js on new profile, there's no problem.

Then as I use dark theme (Arc-Dark) both in GTK and in FF, then I need to get things readable since FF doesn't render correctly for dark themes...  For that purpose I use (yes it got broken at some point, but got back to working a few versions back) in .mozilla/firefox/<profile>.default/chrome/userContent.css:

input, textarea, select {
   -moz-appearance: none !important;
   background-color: white;
   color: black;

a[class="symlink"] {
   color: #2EB8E6 !important;

a:visited[class="symlink"] {
   color: #FF6666 !important;

I remember getting that recommendation from gnomish-dark theme (no longer works on gtk-3), but there are other hacks using same file recommended by others, like:

Looks like dark themes broken again?  AFAIK, by not using userContent.css, the fonts in drop down select items can't be read, as well as many other items, and so on...  Any recommendation for userContent.css that's not to just remove it?

I'll try Arch recommendations, but as I remember there was no difference...

Comment 12

a year ago
OK, Arch recommendations, seem to get checkboxes back...  Perhaps "not([type='checkbox'])" does the trick..  The one they recommend:

input:not(.urlbar-input):not(.textbox-input):not(.form-control):not([type='checkbox']) {
    -moz-appearance: none !important;
    background-color: white;
    color: black;

#downloads-indicator-counter {
    color: white;

textarea {
    -moz-appearance: none !important;
    background-color: white;
    color: black;

select {
    -moz-appearance: none !important;
    background-color: white;
    color: black;

Though I haven't tried how other sites look, rather than the one provide by the OP...  Oh, well I'll have to try some time later...  So it seems to be related to checkboxes being changed background/foreground colors under .mozilla/firefox/<profile>.default/chrome/userContent.css...

Comment 13

a year ago
In general, Arch recommendation seems to work fine, and brought checkboxes back, so I'm staying with it.  It still seem to handle dark themes...  So long for the gnomish-dark recommendations then, :)

I don't know what the OP uses, but perhaps filtering out the checkboxes from background/foreground fonts colors customizations, as Arch recommends, is the path to go, :-)
(In reply to Javier from comment #11)
> input, textarea, select {
>    -moz-appearance: none !important;

Thanks for tracking this down Javier!  The above rule will make
checkbox/radio controls in "disappear" in v54 due to bug 605985.
(This was mentioned in the release notes, fwiw: )
We intentionally made this change to be compatible with Chrome/Edge since
web sites now depend on their behavior.  Sorry for the inconvenience.
Kr1, do you also have such userContent.css changes?
Flags: needinfo?(kr4ssimir)
You need to log in before you can comment on or make changes to this bug.