Open Bug 428328 Opened 12 years ago Updated 4 years ago
Setting background color on form widgets should not disable theming
I can confirm this on Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5
Bug only seems to occur if the select element is in a table.
Reproducible on Windows and Linux, and it doesn't have to be a <select> -- any form widget can suffer this effect. What's going on, as far as I can tell: setting some CSS properties (at least background, border, and text color) on a form widget causes us not to use the system control theme at all for that widget. This can change not only the appearance but the dimensions of the widget. For border properties we may not have much of a choice here, but I would argue that we should be able to draw a different background color while preserving the rest of the system theme, we should *definitely* be able to draw a different text color, and even when we can't use the system theme at all we ought to be able to make the box dimensions match what they would have been if the theme were in use. So, confirming bug and retitling.
Severity: minor → normal
Status: UNCONFIRMED → NEW
Component: General → Layout: Form Controls
Ever confirmed: true
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → layout.form-controls
Hardware: PowerPC → All
Summary: select box visual features disappear when background color is changed → Setting text or background color on form widgets should not disable theming
> I would argue that we should be able to draw a different background color > while preserving the rest of the system theme, we should *definitely* be able > to draw a different text color I suspect that far too many web pages only set one of text and background color; the result is that doing what you suggest would make the form controls on these pages unreadable unreadable (e.g. page-set black text on OS-provided black background in common "reverse-video" themes used for users with poor vision). > ought to be able to make the box dimensions match what they would have been if > the theme were in use That might not be a bad idea. Note that we do have existing bugs on the dynamic change from themed to not themed not doing reflow properly...
> I suspect that far too many web pages only set one of text and background Exhibit A: the url from comment 0. Sets background, but not text color. Seems to me this should be a dup of the existing bug on <select> dropmarkers not working right when dynamically changing from themed to not.
I don't disagree with what you're saying, but consider this counterpoint: the common trick of putting grayed out text in a text field to hint at what should be typed there. (JS courtesy http://remysharp.com/) Focusing or unfocusing the text field (which makes the hint disappear and reappear) should not cause the border style and dimensions of the text box to change. [I should admit that I haven't persuaded *this* test case to do that, but I was seeing it with a more complicated test case on Windows. Don't have convenient access to Windows right now, unfortunately.]
Duh, it happens if you use background-color: instead of color: in the style. I retract the assertion that it happens for text color. > I suspect that far too many web pages only set one of text and background > color; the result is that doing what you suggest would make the form controls > on these pages unreadable unreadable (e.g. page-set black text on OS-provided > black background in common "reverse-video" themes used for users with poor > vision). We could reverse-video the text color setting if the OS-provided background has insufficient contrast with it, as we already do for selection highlight.
Summary: Setting text or background color on form widgets should not disable theming → Setting background color on form widgets should not disable theming
I think the problem with background color specifically is that the os widget look is all treated as background for painting purposes, but you might want to check with someone familiar with that code... This bug as originally filed is still a duplicate of the bug I mention in comment 5.
You need to log in before you can comment on or make changes to this bug.