182589 - Form checkboxes and radio buttons do not pick up userContent.css overrides for colors

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[alanjstr]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021119 Phoenix/0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021119 Phoenix/0.4

I changed my windows color scheme to have textboxes with a background color
other than white and a foreground color other than black.  Mozilla inherits
these colors via -moz-Field and -moz-Fieldtext in forms.css.  In forms.css, for
textboxes and radio buttons, these are set to !important.  In userChrome.css, I
set color and background-color to black and white respectively, both with a
!important, so that they would not be overridden.  It works for input and
textbox, but not for checkboxes and radio buttons.  DOM Inspector shows
forms.css and userContent.css with a weight of 257 for radio buttons and check
boxes.  

Reproducible: Always

Steps to Reproduce:
1.  Open Windows 'Display Properties'
2.  Go to the 'Appearance' tab
3.  Pick 'Window' from the 'Item' dropdown
4.  Set the top color (background) to blue
5.  Set the bottom color (foreground) to white
6.  Put overrides into userContent.css
6.  Open a web page with form elements.  

Actual Results:  
Check boxes and radio buttons have a blue background and white foreground

Expected Results:  
Check boxes and radio buttons have a white background and black foreground

Comment 1

[alanjstr]

Attachment: userContent.css to 'correct' form elements

Comment 2

[alanjstr]

Attachment: Example with some form elements

Comment 3

[alanjstr]

Attachment: Screenshot of the blue checkbox and white textbox

Comment 4

[alanjstr]

Attachment: Form elements before applying userContent.css

Comment 5

[R.K.Aa.]

dup of bug 79719?

Comment 6

[alanjstr]

Nope.  Bug 79719 is about a web-page being able to modify the setting.  In this
case, I want to change the colors via userContent.css.  forms.css should be a
higher priority than the webpage when !important is specified, but not higher
than userContent.css when !important is specified (IMHO).  

I can understand the problem with a malicious webpage having the foreground and
background of the same color.  

Comment 7

[Boris Zbarsky [:bzbarsky]]

UA sheet !important rules should be a higher priority than user sheet !important
rules, imo... (as in, forms.css should override userContent.css).

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We use UA !important when we don't want to support a property for a certain
element or when we don't want to expose that we're doing something internally
using CSS.  I think this case is the latter, and there are definitely reasons we
want the cascade order as-is.

Comment 9

[alanjstr]

Well, I certainly see a down-side, such as giving me checkboxes that are blue
that I can't change.  Is there a reason why the checkboxes and radio buttons are
of such high importance, but a regular textbox is not?

Comment 10

[Jon Henry]

I can confirm that this still occurs on Win 2000, 20030917 nightly build of
Firebird. Is this definitely the desired behavior, as Boris and David have
indicated? I won't pretend to know the reasoning behind it, but it seems to me
pretty counterintuitive for the color of checkboxes and radiobuttons to be
unchangeable while textboxes and buttons are fine. This should probably be
resolved either WONTFIX or be triaged to somewhere like Style System.

Comment 11

[Boris Zbarsky [:bzbarsky]]

The style system behavior here is correct, as David and I said.  The only
question is whether the rules that are listed are what's desired.  That's a form
controls problem, if a problem at all.

Comment 12

[Jon Henry]

-> Form Controls, although it sounds like this is headed for a wontfix designation.

Comment 13

[Joel Stevenson]

I hope this bug doesn't end up a wontifx.  I can't see any reason why the
background-color *and* color properties of radio and checkbox elements must be
unchangeable (short of hacking forms.css).  The ability to change these values
is very handy, most particularly in conjunction with the :checked pseudo-class.
 One thing I actually like about Aqua form elements is that the checked radio
and checkbox elements stand out visually, being able to provide a similar sort
of visual feedback in the Mozilla family would be really great.  

If the concern is a malicious page hiding "please send me boatloads of spam and
share my information with everyone" elements or any other sneaky behavior, I can
understand that, but the current (1.7b1) entry seems to get you half-way to
preventing that anyway with:

  border: 2px inset ThreeDFace ! important;

defined in the radio/checkbox styles.  On Mac OS X if background-color and color
are not defined as important and an additional radio/checkbox :checked selector
is defined with 'color: -moz-FieldText ! important;', then there is no case when
the radio/checkbox could be completely invisible on the page.  I don't know if
the behavior differs on Windows or Linux. 

With no similar restrictions on select boxes, text inputs, textareas, etc.,
their values can be easily obscured by a malicious page so I'm guessing that
there are other reasons for having the radio and checkboxes behave this way.  An
explanation would be helpful so that these reasons can be passed on to end
users, if the current ! important rules won't be changed.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> If the concern is a malicious page

Never attribute to malice what is adequtely explained by stupidity.  The problem
is that there are many pages out there that set those styles because they do
something totally different in IE and the end result was that controls were
disappearing, which was not desired by either the page or the user.

The explanations are given in grinding detail in the bugs that introduced the
!important rules; see the CVS log for forms.css.

Comment 15

[alanjstr]

(In reply to comment #8)
> We use UA !important when we don't want to support a property for a certain
> element or when we don't want to expose that we're doing something internally
> using CSS.  I think this case is the latter, and there are definitely reasons we
> want the cascade order as-is.

This is about userContent.css, not the web page itself being able to control the
appearance.  If the Mozilla code is that bad, then I would say this should be a
future thing.  I'm sure there are valid (internal) reasons for having forms.css
outrank userContent.css.