Summary: HTML Form listboxes that would be longer than the remaining distance to the bottom edge of the Windows NT display area do not display properly or extend beyond the canvas edge. To reproduce: 1. Begin entering a new bug into Bugzilla, arriving at http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser 2. Select something other than the default for Platform and OS, and note what you selected. Leave Severity at Normal. 3. Reduce the height of the browser windows to 400 pixels or so. 4. Move the browser window to a position where the bottom of the window is near to the bottom of the display. 5. Scroll until the Platform, OS, and Severity listboxes are just above the bottom of the canvas. 6. Click on the down-arrow at the right hand side of the "compressed" listbox widget or on the default value to request the widget to display the list. 7. Scroll the form so that the listboxes are just below the top of the browser window. 8. Observe the values shown by the listboxes, click on the control, and observe again. What happens: 1. The display of the list will be wrong in one of three ways: (a) The list will not be displayed. (b) A vertical scrollbar will be displayed below the down-arrow, but it will disappear again, and the list will not be displayed. (c) The list will be displayed, but it will extend not only beyond the pane, but beyond the Mozilla window, even on top of the Taskbar. (d) The list will be displayed, but it will extend not only beyond the pane, but beyond the Mozilla window, even on top of the Taskbar, and will be clipped by the display edge. Of these, only (c) can be considered correct behaviour. Inferences regarding "1": - If the list would not have a scrollbar, (a) happens if the height of the list is more than the remaining distance to the edge of the display, and (c) happens otherwise. - If the list would have a scrollbar, (d) happens if the click is made on the down-arrow part of the "compressed" listbox, and (b) happens if the click is made on the value part of the "compressed" listbox. 2. If 1(a) or 1(b) happens, the value displayed in the "compressed" listbox will not be the same as that selected in Step 2 above. Usually, the value shown will be the one at the top of the list. This will happen if the bottom of the list would be well beyond the bottom edge of the display. If you scroll the listbox away from the bottom edge and then click on the down-arrow again, the seelected value will still be highlighted. Which value will be submitted is left as an exercise for the reader, but I suspect that the "wrong" value is submitted. It is also possible for the value to be something other than that at the top of the list. If the listbox is exactly the right distance from the edge when the down-arrow is clicked, just beyond the point where behaviour 1(c) turns into behaviour 1(a), the list will not be displayed, but the display of the "compressed" listbox will updated to show a value between the selected value and the top value on the list. For example, if the scrollbar is nudged so that the Severity listbox is moved just a few pixels closer than it was when the list just barely fit on the display, the list will not be shown and the value will change from "Normal" to "Critical". If the listbox is moved closer yet, the value will always change from "Normal" to "Blocker". Here is the crazy part. If, after the value changes from "Normal" to "Critical", the down-arrow is clicked on again without moving the listbox further away from the edge of the display, the value will change again to "Blocker". I have reproduced this sequence several times. All of 2. is likely a dead issue if the issues in 1. are resolved. Expected behaviour: 1. The listboxes should display their lists when clicked so that a selection can be made. 2. Even though this should never happen if 1. is satisfied, if the list cannot be displayed, the state of the listbox should not ever change when the listbox control is clicked unless a selection is made. Also, if there is more room within the browser window above the "compressed" listbox than below, the list should be displayed above the listbox control rather than below it. Occurs with: M11 build 1999101109 on WinNT

The code changes necessary to fix this bug may be the same code changes necessary to fix Bug 16155

Reassigning to Rod.

Based on the disposition of bug 16155, and the content of bug 9454, this bug is probably a DUP of bug 9454.

What was I thinking? The display problem may need code being developed for Bug 9454, but the crucial element of this bug is mentioned under item 2 under "Expected Behavior": no matter what the display problems are, the selected item in a drop-down list or other combobox should never change unless the UA operator makes a new selection. This seems to be a real problem - see Bug 16719 Changing Severity to "Major"

This bug no longer seems the major contributor to Bug 16719.

*** Bug 16926 has been marked as a duplicate of this bug. ***

This is a regression, it isn't positioning the listbox above the combobox when there isn't enough room below.

removed the PR_MAX forcing the y offset to be zero or greater. Not sure why it was doing this.

Looks correct to me in the 1999110508 build under NT. Marking verified fixed.

Reopening due to bad results (clipping) with the extreme case: 640 by 480. Steps to Reproduce: 1. Change your desktop size to 640 by 480. 2. Launch Mozilla. 3. Go to Bugzilla and bring up any show_bug.cgi page. 4. Scroll to the point where the "Component" listbox is just below the top of the canvas area. 5. Click on the down arrow to show the list of components. 6. Nudge the scrollbar so that the listbox moves down on the canvas by its own height, then repeat step 5. 7. Repeat step 6 three or four times. Actual Results: After 2 or three iterations of step 7, the listbox is moved far enough down on the canvas that the list no longer fits on the desktop below. At that point, it switches to displaying above the listbox, even though there are even less pixels above, and the list is clipped. Expected Results: If the list will not fit on the screen either above or below the listbox, the number of items to be displayed should be reduced until the list will fit without clipping at the edge of the desktop. Tested with: Windows 98, mozilla.exe, 1999-11-07-08-M11 nightly binary Additional information: The source code Bugzilla provides for the <select>that this listbox is rendered from contains no attribute to control the number of options displayed by the UA (not sure if there even is such an attribute). Query: Should this be a separate bug report? ("Combobox option list length not adjusting for desktop size") If so, this bug would still depend on it. Or, is there already a bug for desktop size issues? If so, this bug would depend on that one.

Clearing FIXED resolution due to reopen.

changed to M14

QA Contact update.

moving to M15

changed summary

All the positioning is fixed and I have the dynamic sizing of the dropdown working for smaller screen resolutions fixed in my tree.

fixed

Verifying