Native theme does not work on any page

REOPENED
Unassigned
(NeedInfo from)

Status

()

Core
Widget: Gtk
REOPENED
6 months ago
5 months ago

People

(Reporter: Kr1, Unassigned, NeedInfo)

Tracking

55 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 months 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 https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_checked


Actual results:

Page rendered, but no checkboxes


Expected results:

Checkboxes should be there
(Reporter)

Updated

6 months ago
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

Comment 1

6 months ago
Created attachment 8882907 [details]
Screenshot

This is what I see when loading that page.

Comment 2

6 months ago
Can you reproduce the problem also with a recent version of Firefox?
https://www.mozilla.org/en-US/firefox/

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

Comment 3

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

Comment 4

6 months 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
(Reporter)

Comment 5

6 months ago
I can still reproduce it with my default profile, but all addons, themes and language packs disabled

Comment 6

6 months ago
(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.
(Reporter)

Comment 7

6 months ago
Old prefs.js in a new profile doesn't break it. Weird

Updated

5 months ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 months ago
Component: Untriaged → CSS Parsing and Computation
Resolution: --- → DUPLICATE
Duplicate of bug: 1373417

Comment 9

5 months ago
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.
Status: RESOLVED → REOPENED
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

Updated

5 months ago
Duplicate of this bug: 1377922

Comment 11

5 months 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="file"],
a[class="dir"],
a[class="symlink"] {
   color: #2EB8E6 !important;
}

a:visited[class="file"],
a:visited[class="dir"],
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:

https://wiki.archlinux.org/index.php/firefox#Unreadable_input_fields_with_dark_GTK.2B_themes

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

5 months 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

5 months 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:
https://developer.mozilla.org/en-US/Firefox/Releases/54 )
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.