Closed Bug 17450 Opened 20 years ago Closed 20 years ago

[BLOCK] Similar Combo-boxes layout badly

Categories

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

defect

Tracking

()

VERIFIED INVALID

People

(Reporter: michael.j.lowe, Assigned: buster)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

The combo boxes on the left hand frame behave strangely, particularly the 2nd
and 3rd ones (under "Use our directory" title).   On the 2nd combo-box ("Select
Business Unit"), the combo box arrow button is not fully displayed.   With the
2nd, 3rd and 4th combo boxes, the pulldown list displays horizontal scrollbars.
For some reason the two button frames inside the combobox frame are not getting
reflowed properly or at all.
Attached file Testcase
Attached a testcase which approximates the actual page.
Thanks for the reduced testcase I was looking at this yesterday and was having a
lot of problems figuring it out. I think this may be a line layout bug. But I
will investigate some more.
Four more observations about the comboboxes in the testcase.

1. With 1999-11-06-08-M11 on Win NT, the 2nd and 4th comboboxes
show only part of the text until the drop-down arrow is clicked.
This was reported previously and fixed for the testcase reported then
(probably a bugzilla page); I'll try to find the bugzilla bug number for that
report.

2. In the 2nd combobox, once it is dropped down, clicking on the
scrolling area below the vertical scrollbar itself or trying to click-drag
the scrollbar down results in the dropped-down list disappearing.
When it is re-opened, the scrollbar is moved down and the corresponding
part of the list is in view.

3. After clicking *anywhere* on the vertical scrollbar or scrolling area,
whether there is any mouse motion during the click or not, one or more
of the <option> items is highlighted when the combobox is next dropped-down,
even though no option has been clicked on.

4. Using 1999-11-06-08-M11 on WinNT, only the 2nd combobox in either the
testcase or the original URL shows a horizontal scrollbar.
Summary: Combo-boxes behave strangely → Similar Combo-boxes layout badly
changed summary
changed to M14
QA Contact update.
Blocks: 21564
Blocks: 22176
Whiteboard: [Testcase needed]
The testcase provided on 11/1/99 does show the bug.  However, I could use help
finding a minimized test case. In a perfect world, the minimized test case would
have a single combo-box with a single entry that showed the problem.  Anything
between the 11/1 test case and this ideal would be much appreciated!
Attached file Very reduced testcase
Apparently, line layout is trying to squeeze the second combobox into the
remaining space (after the first combobox), then decides that it can't fit and
then moves the second combobox to the next line. At this point it is either NOT
reflowing it again or it has set the frame to be the smaller size instead of the
size the frame requested.

To correct the problem (work around) simply put a <br> after the first select.
Assignee: rods → kipp
Assigning to Kipp for now. Buster, this is the one we were looking at.
mass moving all Kipp's pre-beta bugs to M15.  Nisheeth and I will
prioritize these and selectively move high-priority bugs into M13 and M14.
Summary: Similar Combo-boxes layout badly → [BLOCK] Similar Combo-boxes layout badly
Happens on all platforms (tested 2000-02-08-17 builds).

Adding testcase to keywords field.
Keywords: testcase
OS: Windows NT → All
Hardware: PC → All
mine! mine mine mine!  all mine!  whoo-hoo!
Assignee: kipp → buster
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
Status: NEW → ASSIGNED
Priority: P3 → P2
This bug is invalid.
There are two issues to be discussed.

1. combo-boxes being sized incorrectly by block reflow (comment from 
rods@netscape.com 1999-12-20 15:31)

Block reflow is sizing combo boxes correctly.  I tried lots of variants of the 
test case, and Rod and I were unable to reproduce any problems.  Perhaps 
something got fixed that relates to this, but if so I don't know anything about 
it.


2. The combo-boxes on the original page (www.csiro.au) are not all the same 
width.

In IE, the 4 combo-boxes are the same width.  In Mozilla and Nav 4.x, they are 
not.  They get there intrinsic width (the width of the largest option.)  I 
believe Mozilla is doing the right thing.  The source has this pattern:
<select name="selList" size="1" class="dropdown" style="background-color: 
#e8f8ff;" onchange="selItem(2)" style="width: 165">
which boils down to:
<select style="background-color: #e8f8ff;" style="width: 165">
It is illegal to specify the same HTML attribute twice on the same element.  For 
all HTML attributes on a single element, Mozilla and Nav both process only the 
first occurance of an HTML attribute. All subsequent instances of the same 
attribute on that element are ignored, by design.  The HTML specs have little to 
say about this situation that I can find, although if I recall they do say that 
each attribute can only appear once per element. We process the first instance 
for backwards compatibility with Nav4.x.

If you disagree with this second point, please submit a new bug and we'll look 
into making an exception for "style" attribute.

cc-ing troy and pierre just in case they cares about the processing of the 
"style" HTML attribute.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Whiteboard: [Testcase needed]
No longer blocks: 21564
No longer blocks: 22176
Updating QA contact.
QA Contact: ckritzer → bsharma
Verifying. Also, on the testcases, the problems don't seem to appear anymore.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.