Setting background color on form widgets should not disable theming

RESOLVED INACTIVE

Status

()

Core
Layout: Form Controls
RESOLVED INACTIVE
10 years ago
2 days ago

People

(Reporter: Matthew Nagi, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
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

10 years ago
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

10 years ago
Created attachment 321585 [details]
Test case showing bug

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.
Created attachment 396166 [details]
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.]
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
Created attachment 396168 [details]
corrected test case 2
Attachment #396166 - Attachment is obsolete: true
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.

Updated

3 years ago
Duplicate of this bug: 1162633
Comment hidden (spam)
Comment hidden (spam)
Comment hidden (spam)
Comment hidden (spam)

Comment 15

2 days ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 2 days ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.