251032 - Floated SELECT loses drop-down widget

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Christopher Schultz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

[Short example w/screenshots forthcoming]

I have a small search "box" which I just switched over from tables to DIVs with
CSS. When floating a SELECT box (which apparently is required to get the desired
effect; I wouldn't have thought it necessary), the drop-down widget disappears.


Reproducible: Always
Steps to Reproduce:
1. Load the attached HTML document and accompanying CSS file.
2. Look at the result.
3. Frown :(

Actual Results:  
SELECT drop-down widget is missing.

(Less of an issue is that the margin-top and margin-bottom for the "span" (class
name, not SPAN tag) class are correctly identified as 0.5em in the DOM
inspector, yet ignored for rendering)


Expected Results:  
To see the drop-down widget.

(And have my spacing honored, but I'll settle for the drop-down widget ;)

Tested on the browser detected by Bugzilla, here (Firefox 0.9.2/win32 / Gecko
20040707).

Also tested with same results on Mozilla 1.7/Linux Gecko 20040616.

Comment 1

[Christopher Schultz]

Attachment: Test HTML document demonstrating this bug.

Note that this HTML attachment requires the CSS attachment to demonstrate the
bug.

Comment 2

[Christopher Schultz]

Attachment: CSS document which demonstrates this bug.

Comment 3

[Christopher Schultz]

Attachment: Screenshot of display in Firefox/win32 0.9.2

Comment 4

[Christopher Schultz]

Attachment: Screenshot of IE 6 rendering.

Not that IE should be considered "the right way", but this is what I had
expected given my HTML and CSS.

Comment 5

[Hermann Schwab]

Attachment: HTML using the attached CSS

hint: if you first upload the CSS, you can use the link in your HTML document,
so you´ve got a working HTML as attachment.

Seen with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040711

Dupe & testcase:
Bug 251057 floated labels + select gives no dropdown arrow on select
http://bugzilla.mozilla.org/attachment.cgi?id=152969&action=view

Comment 6

[Mats Palmgren (inactive)]

*** Bug 251057 has been marked as a duplicate of this bug. ***

Comment 7

[Brock Witherspoon]

My apologies on the duplication.  I *did* search! (although, hrm, I might have
only searched in Firefox but later decided to put it under Browser.)  Also
please note this also happens in Mozilla 1.7, and it did not happen in Mozilla
1.6 nor in Firefox 0.8.

Comment 8

[Mats Palmgren (inactive)]

The regression seems to have occured between the (Linux) builds
2004-03-07-09 and 2004-03-09-09

Comment 9

[Boris Zbarsky [:bzbarsky]]

More precisely, between 2004-03-07-09 and 2004-03-08-09

Comment 10

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

Attachment: Minimized testcase

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Frame dump

Here's a frame dump fo the minimized testcase (thanks Chris!). This is clearly
a reflow bug. Here's the relevant chunk:

		ComboboxControl(select)(3)@0xa4ef5b8 {1995,0,1680,330}
[state=00140124] sc=0xa4ef50c(i=1,b=0)<
		  line 0xa8339e0: count=2
state=inline,clean,prevmarginclean,impacted,not wrapped,nobr[0x1008] mew=1530
{1995,30,1920,300} <
		    Block(select)(3)@0xa8333d8 next=0xa833704 {30,30,1380,270}
[state=00800005] sc=0xa833458(i=1,b=0)<
		      line 0xa83354c: count=1
state=inline,clean,prevmarginclean,not impacted,not wrapped,nobr[0x800]
mew=1230 {60,15,1230,240} <
			Text(-1)@0xa8334e0[0,12,T]  {60,15,1230,240}
[state=40000004] sc=0xa833520<
			  "some bustage"
			>
		      >
		    >
		    ButtonControl(input)(-1)@0xa833704 {1410,30,240,270}
[state=00000024] [content=0xa82e458] [sc=0xa833658]<

Note that the line is entirely outside the bounds of the ComboboxControl. The
origin of the line area should probably be (0,0) and not what it is.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

So probably what's happening is that the ComboboxControl is using the space
manager of its parent...

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Indeed, the problem is that the SELECT gets its parent's space manager, so it
moves its display area and button to the right to make room for the left float 
(well, only partially and incorrectly, because nsComboboxControlFrame is not
set up to handle that). The solution is simply to make all SELECT elements have
their own space manager, because floats from other blocks should never affect
the positioning of the SELECT's children.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 153009 [details] [diff] [review]
fix

Fairly simple and safe fix...

Comment 15

[Justin Wood (:Callek)]

Comment on attachment 153009 [details] [diff] [review]
fix

Works for me! note: other than this patch, my build is 3 days old though.

Comment 16

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

WFM with your patch, my build is ~12 hrs old.

Comment 17

[Christopher Schultz]

Robets, you're the man! Thanks for the quick fix (less than 12 hours -- not bad).

Sorry, I don't have a win32 compiler handy. I guess I'll have to wait 'till this
gets into a nightly build to check it out.

Comment 18

[Brock Witherspoon]

Attachment: extra testcase - different broken behavior

Came across a *slightly* different bug that may be fixed with the same patch...
Look at the attached extra testcase (floated right this time).	With my Firefox
9.1/Linux and 9.2/XP, the dropdown arrow actually appears like it should, but
look at the justification of the list elements when you use the dropdown....
they're floated right.	Now, I don't know anything at all about Mozilla
programming, but as a layman looking at that patch and the discussion
surrounding it, it seems that it might take care of this problem as well.  I
don't know how to compile this stuff, so I can't test it out.

Comment 19

[Boris Zbarsky [:bzbarsky]]

In that last testcase the <option>s are floated.  <option> elements can in fact
be styled, and floating them should arguably have exactly the effect you're seeing.

Comment 20

[Mats Palmgren (inactive)]

(In reply to comment #18)
> Created an attachment (id=153088)
> extra testcase - different broken behavior

The current layout is correct in this case. The problem is that the selector
matches the <option>s, I guess what you want is "div.blah > *", see
http://www.w3.org/TR/CSS21/selector.html

Comment 21

[Brock Witherspoon]

Hmm, interesting, thanks.  Sorry to cause trouble. Look for my new book soon,
"Confounding Variables for Fun and Profit." ;)

Comment 22

[Mats Palmgren (inactive)]

*** Bug 251591 has been marked as a duplicate of this bug. ***

Comment 23

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in.

Comment 24

[Christopher Schultz]

Forgive my ignorance, but what's the best way for me to test this out? I don't
have a win32 compiler. Will the next nightly build of Firefox contain the patch?

Comment 25

[Boris Zbarsky [:bzbarsky]]

The next trunk nightly will, yes.

Comment 26

[Brock Witherspoon]

(In reply to comment #25)
> The next trunk nightly will, yes.

Still broken in 0.9.3 on Windows and Linux.... when will this fix be included in
a 'release'?

Comment 27

[Boris Zbarsky [:bzbarsky]]

Firefox releases up to 1.0 will be off the 1.7 branch.  This was checked in on
trunk.  So it's not going to be in Firefox 1.0 unless it gets ported to branch
(and accepted by the branch drivers).

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The fix would be trivial to port to 1.7 and the Aviary branch, and the risk is
extremely low. Brock, if you think this is important, try requesting Aviary and
1.7 approval.

Comment 29

[Justin Wood (:Callek)]

Had a few people ask about this, and nearly open a new bug, since this one is
resolved...

This should be on aviary imo, as Roc said, trivial fix.

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 153009 [details] [diff] [review]
fix

This has to either go in both 1.7 and Aviary, or neither.

Comment 31

[Mike Kaply [:mkaply]]

Comment on attachment 153009 [details] [diff] [review]
fix

a=mkaply for aviary and 1.7.3

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I can check into the 1.7 branch, but someone else should check into Aviary.

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Checked into 1.7 branch.

Comment 34

[Asa Dotzler [:asa]]

setting to blocking to make sure we get this into aviary.

Comment 35

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

*** Bug 257259 has been marked as a duplicate of this bug. ***

Comment 36

[Mats Palmgren (inactive)]

*** Bug 259092 has been marked as a duplicate of this bug. ***

Comment 37

[Christopher Schultz]

Okay, looks good in Firefox-1.0PR1. Woo hoo!