Open Bug 379041 Opened 17 years ago Updated 2 years ago

Setting the background-image CSS property on a text input box or select element changes the border style

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows XP
Type:
defect

Tracking

()

People

(Reporter: greenie2600, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(2 files)

testcase from comment 0
356 bytes, text/html
Details
Minimalistic valid XHTML 1.1 Testcase
470 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Firefox's default border style for <select> and <input type="text"> elements is a solid, blue, one-pixel border. However, if the element's background-image property is set, the border changes to a two-pixel, inset, gray border.

This happens in both quirks mode and standards mode.



Reproducible: Always

Steps to Reproduce:
1. Create an HTML file containing the following code:

<html>

<head>
	<title>San Dimas High School Football Rules!</title>
</head>

<body>

	<p>Default border style:
	<input type="text" /></p>
	
	<p>Buggy border style:
	<input type="text" style="background-image: url('http://www.mozilla.com/img/template/moz-com-logo.png');" /></p>

</body>

</html>

2. Open this HTML file in Firefox to observe the difference in the rendering of the borders.

Actual Results:  
The unstyled <input> element was rendered with the default blue border. The styled <input> element was rendered with the anomalous border described above.

Expected Results:  
I expected Firefox to use the same default border style for both <input> elements, regardless of the background-image property.
I see the same with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/2007042103 BonEcho/2.0.0.4pre
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070427 Minefield/3.0a5pre ID:2007042708 [cairo]
Keywords: testcase
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
I'm not sure, but I think this is 'by design'. The heuristics to determine whether 'native' widgets (blueish border) or not works like this: if the author stylesheet specifies either border or background(-color), use gfx-styled form controls, if not use native (themed) form controls.
Both IE 7 and Opera 9.2 do the same on my install of Win XP.
I can confirm this issue, if setting background-{image,position,repeat} but not background-color and border, the blue xp widget border is used in IE7, but not in Mozilla.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This file is rendered properly by IE7, using the blue XP-border.
Mozilla draws it using the GFX borders, even though there is no background-color or border set.
Component: General → Layout
QA Contact: general → layout
same problem here:

latest trunk build of FF3: setting border:none and a background image causes a 1px white border to appear around the option element only, but not including the dropdown arrow in the listbox, as would happen if a border was set around the SELECT element normally.

see testcase here: http://www.onelonetree.org/test/selbordtest.htm
This is probably because of the -moz-appearance:menulist  style that is applied to this menulist.
When there is a -moz-appearance setting, background & borders ignore their style rules and just apply the system styling/theme.
If it's by design, then I question the design. What's the rationale behind this?
requesting for 1.9.1.
Flags: wanted1.9.1?
wait, is this fixed? it looks like it might be.

please confirm/mark as resolved, if yes.
The alternative design is making the background, border, and text color of form controls un-styleable by the author.  I'd be happy with that, but I suspect a bunch of authors wouldn't.  (We can't allow authors to style the text color but ignore backgrounds that they specify, since then we'll end up with unreadable combinations.  And we don't really know how to draw a system form control; all we can do is ask the system to draw it.)
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1-
I guess the main point on styling <input>s and <selects> is that their layout shouldn't completely change when you change specific CSS properties.
E.g. IE 11, Chrome 33 and Opera 20 use their own designs for <select>s instead of the OS theming, while Opera comes near to native theming (at least on Win8.1). Chrome and Opera seem to use the OS theming for <input>s, though, and fall back to custom theming like Firefox when you style them. IE 11 is more consequent here and always uses custom styling for its form elements.

So I think the best solution would be to always use a custom theme for form elements but try to imitate the OS theme as far as possible.

Sebastian
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: