305705 - Whitespace in <option> of <select> isn't selectable when width is specified.

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Build ID: 2005-08-23-06, SeaMonkey trunk and Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.9a1) Gecko/20050823 Firefox/1.6a1 of Deer Park.

This is a regression since Firefox 1.0.6.

Summary: Whitespace in <option> of <select> isn't selectable.

Steps to Reproduce:

1. Load http://www.ssaglobal.com/company/careers/index.aspx?region=A
2. Choose "The Americas" from the first dropdown
3. Then notice that whitespace isn't selectable; only the text in each value of
the <option>.

I tried making a testcase with just the form itself, but that didn't trigger the
bug.

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Minimal testcase

In this minimal testcase, if I remove the CSS width:175; portion, it displays
fine.

Comment 2

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 3

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

Comment 4

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1 (diff -w)

The problem is that "if (aDesiredSize.width > dropdownDesiredSize.width)"
is false so we never do the second pass reflow when the SELECT has a specified
width <= desired width of the widest option.

With this patch all the OPTIONs in Testcase #2 fills the SELECT, except for
6, 7 and 8 for the OPTION that has a specified 'width'. There is a gap at the
right the size of the combo button for those OPTIONs.
I don't see any way around that.
(Compare those with, 9, 10 and 11 where 'min-width' is used instead)

Comment 5

[Boris Zbarsky [:bzbarsky]]

So does that fix bug 302483 and bug 147143?  We also have other bugs with setting widths on select that this might fix, I think....

Also, does this allow us to re-fix bug 232540 without causing bug 252850?

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 200452 [details] [diff] [review]
Patch rev. 1 (diff -w)

Looks reasonable.  Watch Tp carefully, though!

Comment 7

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using both testcases with build 2005-11-15-08 of SeaMonkey trunk on Windows XP.

Comment 9

[Darin Fisher]

This bug is affecting Gmail in FF 1.5.  I think we should fix it on the Gecko 1.8 branch if the patch is safe enough.

Comment 10

[chris hofmann]

anyone know if tp was affected, and have comment on suitability of landing on 1.8.0.1?

Comment 11

[Boris Zbarsky [:bzbarsky]]

This is not suitable for 1.8.0.1 at all, in my opinion -- it's not a stability fix. It might be OK for 1.8.1.

There was no Tp impact that I saw.

Comment 12

[Daniel Veditz [:dveditz]]

going with bz's opinion, not blocking.

Comment 13

[Serge Gautherie (:sgautherie)]

Comment on attachment 200452 [details] [diff] [review]
Patch rev. 1 (diff -w)

(In reply to comment #11)
> This is not suitable for 1.8.0.1 at all, in my opinion -- it's not a stability
> fix. It might be OK for 1.8.1.

Per bug 320940, this fixes a Gv1.8 regression over Gv1.7.
I request approval for Gv1.8.1;
and would like to suggest to include it for Gv1.8.0.3 as well...

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 200452 [details] [diff] [review]
Patch rev. 1 (diff -w)

Please don't write using lots of abbreviations that nobody else uses.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(Is this at all related to bug 325680?)

Comment 16

[Serge Gautherie (:sgautherie)]

(In reply to comment #15)
> (Is this at all related to bug 325680?)

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3) Gecko/20060621 SeaMonkey/1.1a] (nightly) (W98SE)

Bug still there on branch, per testcases.

Comment 17

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.1a3) Gecko/20060623 SeaMonkey/1.1a] (nightly) (W98SE)

V.Fixed on MOZILLA_1_8_BRANCH.

*****

(In reply to comment #4)
> Created an attachment (id=200452) [edit]
> Patch rev. 1 (diff -w)
> 
> With this patch all the OPTIONs in Testcase #2 fills the SELECT, except for
> 6, 7 and 8 for the OPTION that has a specified 'width'. There is a gap at the
> right the size of the combo button for those OPTIONs.
> I don't see any way around that.
> (Compare those with, 9, 10 and 11 where 'min-width' is used instead)

In the meantime, I had filed bug 320640 about case 6+7+8 issue.

Comment 18

[Serge Gautherie (:sgautherie)]

For the record
[
2006-06-22 18:19	mats.palmgren%bredband.net 	mozilla/layout/forms/nsComboboxControlFrame.cpp 	1.324.6.3 	MOZILLA_1_8_BRANCH
]

Comment 19

[Peter Flynn (Oracle)]

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