Closed Bug 320940 Opened 19 years ago Closed 18 years ago

Select + Option without Width issue: too narrow option.

Categories

(Core :: Layout: Form Controls, defect)

1.8 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 302483

People

(Reporter: sgautherie, Unassigned)

References

()

Details

(Keywords: regression, testcase)

[Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915] (release) (WXpProSp2)

Works fine, as it does on W98SE,
as do SMv1.0b and SMv1.5a nighlies on W98SE too.

My colleague who found this bug tells me that ThunderBird v1.0.x works fine too.

[Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5] (release) (WXpProSp2)

Open the testcase attachment for bug 320640 (see URL);
expand the 4th/last select dropdown;
see that the first option, the one without width style, selection area is very narrow and on its left side only.

This regression would seem specific to FFv1.5 (branch).
Flags: testcase+
Flags: blocking1.8.0.1?
(In reply to comment #0)
> My colleague who found this bug tells me that ThunderBird v1.0.x works fine
> too.

He used TBv1.0.7.
Flags: testcase+
Keywords: testcase
Flags: blocking1.8.0.1? → blocking1.8.0.1-
I believe I'm seeing the same effect, though my option elements don't have an explicit width. In my case what I see in general (FF 1.5+) is that options in selects are only clickable over the option contents (i.e., the text node inside the option element) (I guess).  Therefore if one has a blank option there's only a very narrow area at the left edge of the select box where one can click to activate that option.

Firefox 1.0.x makes each option clickable to the width of the expanded select box, regardless of the option tag contents.  In my opinion that is the correct behavior.
(In reply to comment #2)
> I believe I'm seeing the same effect

... but as the original submitter noted, it's only when the options are wider than the parent select box.  The expanded box is rendered with the correct size, but the behavior is (in my opinion) wrong.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20050915] (release) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060403 SeaMonkey/1.5a] (nightly) (W98SE)

Work fine.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1] (release) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8) Gecko/20060419 SeaMonkey/1.1a] (nightly) (W98SE)

SMv1.0.1 and SMv1.1a have this bug too.
Confirming that this bug is specific to the Gv1.8 branch(s).
(Now, I'll have to try and narrow the regression timeframe...)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050705 SeaMonkey/1.0a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050801 SeaMonkey/1.0a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051101 SeaMonkey/1.1a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051108 SeaMonkey/1.5a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051109 SeaMonkey/1.5a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051110 SeaMonkey/1.5a] (nightly) (W98SE)
+/- [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051111 SeaMonkey/1.5a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051112 SeaMonkey/1.5a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051113 SeaMonkey/1.5a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051114 SeaMonkey/1.5a] (nightly) (W98SE)

Bad.
(NB: 20051111 build seems to have this bug fixed, but has another bug (wrt width) ... as if a first fix was checked in then reverted, then a second fix was checked in after 20051114.)

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051115 SeaMonkey/1.5a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051116 SeaMonkey/1.5a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051201 SeaMonkey/1.5a] (nightly) (W98SE)
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060101 SeaMonkey/1.5a] (nightly) (W98SE)

Good.
The Trunk fix should be among
<http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&sortby=Date&hours=2&date=explicit&mindate=2005-11-14+11%3A00%3A00&maxdate=2005-11-15+10%3A00%3A00&cvsroot=%2Fcvsroot>

Maybe
[[
2005-11-14 13:51	bzbarsky%mit.edu 	mozilla/layout/forms/nsComboboxControlFrame.cpp 	1.336 	24/22  	Make sure to do a constrained reflow after having done an unconstrained one.
Bug 305705, patch by Mats Palmgren <mats.palmgren@bredband.net>, r+sr=bzbarsky
]]

*** This bug has been marked as a duplicate of 302483 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
V.Duplicate, per bug 302483 testcase.
Status: RESOLVED → VERIFIED
No longer blocks: 320640
You need to log in before you can comment on or make changes to this bug.