Closed Bug 17450 Opened 20 years ago Closed 20 years ago
[BLOCK] Similar Combo-boxes layout badly
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 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 to M14
QA Contact update.
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!
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.
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.
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
This bug is invalid. There are two issues to be discussed. 1. combo-boxes being sized incorrectly by block reflow (comment from email@example.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]
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.