Closed Bug 48237 Opened 25 years ago Closed 22 years ago

SELECT (combobox and listbox) is too big when right floats (align=right) are nearby

Categories

(Core :: Layout: Form Controls, defect, P2)

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

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.3beta

People

(Reporter: isaacg, Assigned: dbaron)

References

Details

(Whiteboard: [patch])

Attachments

(1 file)

patch
879 bytes, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
When displaying a SELECT form element, it's length is automatically adjusted to the right-aligned image's width. This only happens with right-aligned graphics. Height does not seem to make a difference. For example: http://ritesite.virtualave.net/temp/form.htm <IMG SRC="2007_08.jpg" HEIGHT="300" WIDTH="100" ALIGN="RIGHT"> <FORM> <SELECT SIZE="1" NAME=""> <OPTION VALUE=""> <OPTION VALUE=""> <OPTION VALUE=""> <OPTION VALUE=""> <OPTION VALUE=""> <OPTION VALUE=""> </SELECT> </FORM>
confirming, win95 080908
Status: UNCONFIRMED → NEW
Ever confirmed: true
Re-assigning 6 bugs from Clayton's list to Harish for further triage.
Assignee: clayton → harishd
Triaging Clayton's list: ------------------------- Mark, this looks like a layout bug. Could you please take a look at this. Thank you.
Assignee: harishd → attinasi
Rod, have you seen this before?
This doesn't come to mind, but I did just verify it is line-layout and nor the combo or listbox. I disabled my optimizations for the listbox and it does the same thing. Here is a reflow with my opt turned off (also I made the size="4" so it was just a listbox instead of a combobox, the listbox has the same behavior): -------------Starting BoxFrame Reflow ---------------------------- 0120A830 ** nsBF::Reflow 10 R: Ini AW: 9180 AH: 4470 CW: 9180 CH: 4470 * ****** nsBoxFrame W:9180 H:4470 MW:? MH:? Enabling Quirk StyleSheet -------------Starting BoxFrame Reflow ---------------------------- 0120A830 ** nsBF::Reflow 11 R: Inc AW: 9180 AH: 4470 CW: 9180 CH: 4470 * 0114B840 ** Id: 2 nsLCF::Reflow 4 R: Initia AW: 7440 AH: UNC CW: UNC CH: UNC LBX::Reset 4 nsListControlFrame ::Size=1980,1050 132, 70 Nav: 56, 70 Diffs: 76, 0 ** nsLCF Caching AW: 1920 ** Done nsLCF DW: 1980 DH: 1050 0114B840 ** Id: 2 nsLCF::Reflow 5 R: Resize AW: 7215 AH: UNC CW: UNC CH: UNC 4 nsListControlFrame ::Size=1980,1050 132, 70 Nav: 56, 70 Diffs: 76, 0 ** nsLCF Caching AW: 1920 ** Done nsLCF DW: 1980 DH: 1050 ****** nsBoxFrame W:9180 H:4470 MW:? MH:? Frame(img)(0)@0120B588: UpdateImage: status=4 -------------Starting BoxFrame Reflow ---------------------------- 0120A830 ** nsBF::Reflow 12 R: Inc AW: 9180 AH: 4470 CW: 9180 CH: 4470 * 0114B840 ** Id: 2 nsLCF::Reflow 6 R: Resize AW: 7215 AH: UNC CW: UNC CH: UNC 4 nsListControlFrame ::Size=1980,1050 132, 70 Nav: 56, 70 Diffs: 76, 0 ** nsLCF Caching AW: 1920 ** Done nsLCF DW: 1980 DH: 1050 ****** nsBoxFrame W:9180 H:4470 MW:? MH:? The last two reflows are a Resize and an Inc. As in the log above if the listbox returns a smaller size for the Resize reflow and the Inx still reflows the listbox with a larger Computed Width (9180 twips). But then maybe you knew all this already?
Thanks, Rod, for the data - very helpful. Now I can assign it to buster :)
Assignee: attinasi → buster
I've seen something like this before. I think it has to do with code around line 3213 in nsBlockFrame::ReflowLine(), when we try to incrementally recompute the max width of the contents of a line. See: http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsBlockFrame.cpp#3213
Status: NEW → ASSIGNED
Priority: P3 → P2
P2 bugs will not make RTM. Milestone -> Future.
Target Milestone: --- → Future
Assignee: buster → attinasi
Status: ASSIGNED → NEW
Build reassigning Buster's bugs to Marc.
The other layout bug I found has been inadvertantly fixed, but this one apparently hasn't. Still present on RC3 on WinXP. I can't believe I'm the only one that's ever come across this.
OS: Windows 95 → Windows XP
*** Bug 111641 has been marked as a duplicate of this bug. ***
*** Bug 154530 has been marked as a duplicate of this bug. ***
testcases in the bugs show this happens if anything is floated right (not just an image).
Summary: form size depends on image size when image is right-aligned → form size depends on image size when image is right-aligned (or anything right-floated)
*** Bug 161540 has been marked as a duplicate of this bug. ***
Is there an ETA for repair in the forthcoming Moz and Netscapes? Is there a known workaround? Our institution's new site design depends on a DIV floated right to place its navigation, and we do have quite a number of forms. Thanks!
Does this ever happen with listbox selects, or only combobox selects? Presumably this would be fixed by XBL form controls.
Assignee: attinasi → rods
Component: Layout → HTML Form Controls
QA Contact: petersen → tpreston
Summary: form size depends on image size when image is right-aligned (or anything right-floated) → SELECT (combobox) is too big when right floats (align=right) are nearby
dbaron: Adding the attribute size="5", say, to one of these selects did not reduce the extra spacing. Is that what you mean by "listbox?"
Yes
Summary: SELECT (combobox) is too big when right floats (align=right) are nearby → SELECT (combobox and listbox) is too big when right floats (align=right) are nearby
Carry over our simplified demo of the behavior from DUPed bug 161540. http://toaster.law.indiana.edu/tests/form_bug_demo.shtml
I've just been hit by this bug. To workaround it I have had to set a width on the <option> select[name="selectFrom"] option {width: 10em}
Another interesting (sort of) work-around for this is to set all options to clear:both. That makes the drop-down for the select higher than it should be, though. <beg>Is there any chance of a fix for this? I've been bitten by this bug twice in the past week with real-world pages, and it's quite annoying :/</beg>
Sorry for another note, but an even easier work-around for this is to just wrap all <select>s in an element set to position:relative. Hope that helps someone :)
Taking.
Assignee: rods → dbaron
Whiteboard: [patch]
Target Milestone: Future → mozilla1.3beta
Attachment #111975 - Flags: superreview?(bzbarsky)
Attachment #111975 - Flags: review?(bzbarsky)
Comment on attachment 111975 [details] [diff] [review] patch argh. I knew it had to be something simple, but I was looking in the wrong places! good catch.
Attachment #111975 - Flags: superreview?(bzbarsky)
Attachment #111975 - Flags: superreview+
Attachment #111975 - Flags: review?(bzbarsky)
Attachment #111975 - Flags: review+
Fix checked in to trunk, 2003-01-19 12:02 PST.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 118456 has been marked as a duplicate of this bug. ***
Looks fine using Win FF 1.5, marking VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: