428328 - Setting background color on form widgets should not disable theming

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Matthew Nagi]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

When a select box has its background color property changed via javascript it looses its "visual features" (the 'down arrow' button on the right side of the box).

Reproducible: Always

Steps to Reproduce:
1. Go to https://www.quickenloans.com/mortgage-calculator/home-value?q3=1
2. Submit the form on the left hand side of the page without entering any values in any of the fields
Actual Results:  
After failing validation, javascript changes the background color of each form element as a visual cue to the user.  This causes select boxes to loose their visual features.

Expected Results:  
Changing background colors on select elements shouldn't cause visual elements to disappear.

Comment 1

[Joe Bandenburg]

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

Comment 2

[Joe Bandenburg]

Attachment: Test case showing bug

Bug only seems to occur if the select element is in a table.

Comment 3

[Zack Weinberg (:zwol)]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> 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...

Comment 5

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 6

[Zack Weinberg (:zwol)]

Attachment: test case 2 (text areas) (uses external JS)

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.]

Comment 7

[Zack Weinberg (:zwol)]

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.

Comment 8

[Zack Weinberg (:zwol)]

Attachment: corrected test case 2

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.

Comment 11

[nordiskaflytt]

http://nordiskaflyttkompaniet.se/

Comment 12

[nordiskaflytt]

(In reply to nordiskaflytt from comment #11)
> http://nordiskaflyttkompaniet.se/

ok

Comment 13

[ChristaJocelyn]

CSS backgrounds square measure just about what the name implies. They’re one thing you boost the background of a part. additional specifically they're colours and pictures that sit behind no matter content is value-added within the part. once developing a css driven website these background colours and pictures square measure sometimes answerable for most of the planning parts in your example.

website page:-  http://www.acalculator.com/mortgage-loan-calculator.html

Comment 14

[nordiskaflytt]

Great article. It's always nice when you can not only be informed ....but also entertained!  http://www.xn--snabbalnen-75a.se/