17450 - [BLOCK] Similar Combo-boxes layout badly

Status: VERIFIED INVALID

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

Description

[Michael Lowe]

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.

Comment 1

[rods (gone)]

For some reason the two button frames inside the combobox frame are not getting
reflowed properly or at all.

Comment 2

[Michael Lowe]

Attachment: Testcase

Comment 3

[Michael Lowe]

Attached a testcase which approximates the actual page.

Comment 4

[rods (gone)]

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.

Comment 5

[Sean Richardson]

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.

Comment 6

[rods (gone)]

changed summary

Comment 7

[rods (gone)]

changed to M14

Comment 8

[gerardok]

QA Contact update.

Comment 9

[buster]

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!

Comment 10

[rods (gone)]

Attachment: Very reduced testcase

Comment 11

[rods (gone)]

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.

Comment 12

[rods (gone)]

Assigning to Kipp for now. Buster, this is the one we were looking at.

Comment 13

[buster]

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.

Comment 14

[ckritzer (gone)]

Happens on all platforms (tested 2000-02-08-17 builds).

Adding testcase to keywords field.

Comment 15

[buster]

mine! mine mine mine!  all mine!  whoo-hoo!

Comment 16

[rickg]

moving all buster m15 bugs to m16.

Comment 17

[buster]

This bug is invalid.
There are two issues to be discussed.

1. combo-boxes being sized incorrectly by block reflow (comment from 
[e-mail] 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.

Comment 18

[bsharma]

Updating QA contact.

Comment 19

[Jonas Nagel]

Verifying. Also, on the testcases, the problems don't seem to appear anymore.