269674 - When specifying a background-color on a select box the border is set to inset

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Andy Richmond]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When defining a background-color style on a dropdown box, firefox forces the
border of the dropdown box to be inset.  Specifying any other border-style does
not change the dropdown box border.

Reproducible: Always
Steps to Reproduce:
1. Creat a select box
2. Specify a background color using a style

Actual Results:  
The border of the select box will be rendered as inset.

Expected Results:  
The border of the select box should not have been affected.

Comment 1

[Paul van Schayck]

Attachment: Testcase

I have created a testcase. Is this what you mean?

I'm not observing it. I see the border when a background color is set.

Comment 2

[Andy Richmond]

(In reply to comment #1)
> Created an attachment (id=165828)
> Testcase
> 
> I have created a testcase. Is this what you mean?
> 
> I'm not observing it. I see the border when a background color is set.

In your test case, on the select box with a background-color defined the border
looks inset, but on the select with no background-color defined the border looks
normal.  I would expect that defining a background-color would not change the
look of the border.  

I have posted an image of the actual results vs what I would expect.  On the
example of the hover: before the hover there is no background-color defined and
the border looks fine, after the hover there is a background-color defined and
the border looks inset.  This happends anytime you define a background-color on
a select box.  It is just easer to see in the hover example.
http://www.amrichmond.com/test/bug269674.jpg

Comment 3

[Boris Zbarsky [:bzbarsky]]

<select> has an inset border in forms.css.

If the <select> is unstyled, we do native theme rendering (rendering the
<select> using the default OS look, whatever it is).  If the page styles the
<select>, we fall back to our internal default rendering, with the page styles
applied (because we can't apply them to the bitmap the OS gives us).

So sounds like everything is working as it should.

Comment 4

[Andy Richmond]

Attachment: Firefox 0.8 rendering

Comment 5

[Andy Richmond]

(In reply to comment #3)
> <select> has an inset border in forms.css.
> 
> If the <select> is unstyled, we do native theme rendering (rendering the
> <select> using the default OS look, whatever it is).  If the page styles the
> <select>, we fall back to our internal default rendering, with the page styles
> applied (because we can't apply them to the bitmap the OS gives us).
> 
> So sounds like everything is working as it should.

If I understand your explanation correctly, firefox uses the default OS image of
a <select> until the <select> is styled, at which point it uses its own internal
rendering.  

What is still bothering me then, is that once firefox uses its own rendering
shouldn't I then be able to style the border to something other then the inset
border?  I know that firefox 0.8 did not have this problem and would render the
<select> the same way with or without a background color defined.  I included an
attachement of what firefox 0.8 looked like.  (notice the <select> border does
not change when a background-color style is defined.)

Comment 6

[Boris Zbarsky [:bzbarsky]]

> shouldn't I then be able to style the border to something other then the inset
> border?  

See bug 244370 (fixed on trunk, but long after Firefox 1.0 branched).

Comment 7

[Andy Richmond]

(In reply to comment #6)
> > shouldn't I then be able to style the border to something other then the inset
> > border?  
> 
> See bug 244370 (fixed on trunk, but long after Firefox 1.0 branched).

I am afraid that I am kind of new to this and am a little unclear on what
exactly that means?  Does that mean that this should be fixed in the next
release of firefox?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Yep.  It should be fixed in Firefox 1.1 (which will be based on Mozilla 1.8
code).   The milestone schedule diagram at http://www.mozilla.org/roadmap.html
is pretty old, but gets across the basic idea of the relationship of Firefox 1.0
with the current trunk....