Closed Bug 183247 Opened 22 years ago Closed 22 years ago

CSS colored radio-buttons and checkboxes aren't colored

Categories

(Core :: Layout: Form Controls, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: Oliver.Siegmar, Assigned: dbaron)

References

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

<html>
<head>
<title>test</title>
<body>
<input type="checkbox" name="testbox" value="x" style="background: #AAAAFF;"/>
</body>
</html>

Mozilla 1.0, 1.0.1 and 1.1 shows this checkbox colorized...Mozilla 1.2 and 1.2.1
not. Why?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Actual Results:  
Stylesheeds don't take effect

Expected Results:  
Do the same thing as versions prior 1.2
->Style
oops, really reassigning

sorry for the spam
Assignee: asa → dbaron
Component: Browser-General → Style System
QA Contact: asa → ian
See bug 58755
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Component: Style System → Layout: Form Controls
*** Bug 191263 has been marked as a duplicate of this bug. ***
*** Bug 208456 has been marked as a duplicate of this bug. ***
*** Bug 253978 has been marked as a duplicate of this bug. ***
*** Bug 260907 has been marked as a duplicate of this bug. ***
If we're using this bug to track dupes, maybe these should be added ?
Bug 182256 (plus Bug 219644, which was marked a duplicate of that bug)
Bug 225575 (at least for backgrounds)

Also I tried reversing the forms.css patch from bug 58755, but this didn't bring
back the backgroundColors on radio buttons or checkboxes; So I'm guessing that
something additional has been changed since then that results in a straight
back-out not working.
> Also I tried reversing the forms.css patch from bug 58755

Make sure that you're not being screwed up by native theming of form controls
(on WinXP, say).  It may not get properly dropped for checkboxes/radios with
background set, since it may assume background can't be set on them.
Running Win2000, with appearance scheme set to "Windows Standard" (i.e. very
minimal and non-fancy). BackgroundColors on checkboxes / radios display OK in
Internet Explorer, and if I remember right they used to work in older versions
of Mozilla (I run a small web site that I checked worked OK a few years ago with
Mozilla, but I switched two months ago from IE to Firefox and noticed then that
the backgroundColors on these form elements weren't working) ... all of which is
just a long-winded way of saying that I don't think native theming is stuffing
things up ;-)
> Running Win2000, with appearance scheme set to "Windows Standard" (i.e. very
> minimal and non-fancy)

We do native theming on Win2k, and it doesn't matter _which_ native theme you use.

> all of which is just a long-winded way of saying that I don't think native
> theming is stuffing things up ;-)

None of what you said says that...  Test setting "-moz-appearance: none" on the
controls in question?
> > all of which is just a long-winded way of saying that I don't think native
> > theming is stuffing things up ;-)
> 
> None of what you said says that... 

OK ... Sounds like I've probably confused Windows themes with Mozilla themes.

> Test setting "-moz-appearance: none" on the
> controls in question?

OK, that works. I'm attaching a page with this set, with quick instructions, in
case it's of use to anyone else.

I've tried looking at the pages listed in bug 58755 with the forms.css patch
reversed (some of these are now 404 pages, and some no longer have radio
buttons). The easiest example though was to save the minimized test case from
bug 120021, and then add "-moz-appearance: none" to the style of the radio
buttons, in order to reproduce the original problem.

However, surely these are all problems in the original pages? The reason I say
this is that setting the background colour is not required for Internet
Explorer to work correctly - i.e. remove all styles on these form elements, and
they display exactly the same in Internet Explorer as they did before (at least
for me). Firefox on the other hand can be made to give the page authors what
they asked for - and if they get what they ask for they can hardly complain!

And on the balance of the numbers, there are 2 bugs (counting duplicates) about
pages that look strange (all due to the browser doing what was requested of
it), but there have been between 5 and 8 bugs (depending on what you count)
about the browser not doing what was requested of it.

So why wouldn't it make sense to classify this as a problem with those pages,
and to reverse the forms.css + require "-moz-appearance: none" patches?
> and if they get what they ask for they can hardly complain!

They get something in both Firefox and IE.  What they get is different in both
cases, reasonable in both cases.

If they such that they get what they want in IE, however, the radio disappears
in Firefox.  Since they only test in IE (like most people), they have no way to
know that.  Since what IE does is perfectly valid per the CSS spec and is
reasonable, we can't really evangelize them about it.

> So why wouldn't it make sense to classify this as a problem with those pages,
> and to reverse the forms.css + require "-moz-appearance: none" patches?

You're ignoring the fact that for the last 2 years, as Mozilla usage has gotten
more and more popular, there have been no reports of problems on pages where the
reversed forms.css would cause problems.  This is because the forms.css was not
reversed.  So you're comparing apples (number of bugs filed during a one-year
period when Mozilla was usable and its usage was low) vs oranges (number of bugs
filed during a 2-year period when Mozilla usage was much higher).

Finally, there is the question of what the sites are.  time.com, for example, is
a site that a lot of users end up seeing.  Not working with it is not really an
option for us...
*** Bug 309870 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: