Whenever I have encountered a drop-down list on a web page... and clicked on it - if it has had a scrollbar the scrollbar has behaved in a difficult manner - (this occurs on most builds I have tried to date including 21st March 2000). What happens is, if I click on the scrollbar to move it, it works, but if I move the mouse outside of the scrollbar area, it stops moving and starts selecting an appropriate element in the drop down list (if I have moved in that direction). It will only then continue to move if I return the mouse to the scrollbar area. Also, on a particularly long drop-down list (some 1000 entries), when I began scrolling through the list (with the behaviour expressed above) the text behind the drop down list all became selected.

this is probably a dup

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

Moving

endah, can you provide the URL of a 1000-entry menu for use in testing? html32 forms UE b.c. nsbeta2 6/1-.

Could this be related to bug 32920, "Probably problem with displaying huge <select>s"?

Need info.

The described failure(s) appears to be fixed on Linux. Still a failure on WinNT: When you click a vertical scrollbar with the mouse and if you move the mouse to the left of the scroll bar area, it stops moving. If you move the mouse to the right of the scroll area, it keeps moving the scroll bar until the mouse is around one inch away from the scroll bar. Re-tested on 2000-05-25-09-M16 build for Win32 and 2000-05-25-08-M16 for Linux.

Changing Platform & OS to All. Adding dogfood keyword. Reason: On the MacOS9 2000-05-25-09-M16 Commercial Build, long drop down lists (such as the OS list on this form) is not scrollable.

Also: Upgraded severity to Blocker

Scrollbars aren't working on Mac for XUL popup menus either ... same bug, or different bug?

Putting on dogfood+ radar.

This is a bug in HTML selects which is a completely different codebase from XUL for scrollbars. Infact it uses native ones. Rod should probably be looking at this.

I think this is fixed, and it is a duplicate.

This is not a duplicate. I can recreate this on WinNT also. I will look into this. Setting severity to "Normal" this is NOT a dogfood bug. Native scrollbars on windows pretty much work the same way. In fact, if you test this on WinNT comboboxes have this EXACT behavior. This behavior may not be native on the other platforms. Inf fact, I don't think this is even an nsbeta2 bug.

I can comment on the cross-platformness of this. Using build 2000053011 on my Mac, activating a pop-up list brings up a list with a native scrollbar. Clicking on that scrollbar doesn't work. > Native scrollbars on windows pretty much work the same way. What same way--being inoperative? I'm not sure what the criteria for being dogfood or nsbeta2 are, but this is sure a pain in the ass! It seriously disrupts functionality of pop-up lists. The only workaround is to tap the arrow keys, and since it takes a good half-second for each tap to register, move the highlighting and scroll the scrollbar, if I had the permissions, I'd change this bug to "major" severity, as it certainly fills the requirements for it in my mind.

Removing the dogfood+ to get a re-eval per rods comment. Rods: Can you explain how this "works" on Windows in answer to Avi's question? Also added NEED INFO comment to whiteboard. Thanks, Jim

Feedback for 2000-05-03-20-M16 Commercial build: OS GFX Scrollbars ON GFX Scrollbars OFF MacOS9 Thumb & scroll widgets don't work Thumb works; scroll widgets don't Linux6 Thumb & scroll widgets work Thumb & scroll widgets work Win98 Thumb & scroll widgets work Thumb & scroll widgets work This is dogfood for MacOS. Upgrading severity to critical, since you can still use the scroll arrows to access the other items on the list. Rod, given the information above (and Avi's comments) what is expected behaviour for: - gfx scrollbars - native scrollbars

assigning back to waqar because it is a mac only issue.

Removing need info for re-eval

Putting on [nsbeta2+][dogfood-] radar. Does not need a fix ASAP for daily work, but we should fix this for beta2.

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

Changing the parity to Mac, since it is fixed on Linux and Windows.

M16 has been out for a while now, these bugs target milestones need to be updated.

[CC:ing self at MacHack, one bug participant is sitting here working on his hack. ;-] Target milestone is still M16.

Setting the Target milestone.

This is working for me with 20000705 build. I can click on OS dropdown list and click on the scrollbar and move the list up and down. I an click on the up and down arrow works fine as well. Eli could you please verify this for me I would like to close it, since it is working for me.

20000706 build is working for me.

Forgot to close

Waqar & Chris: I can reproduce a variant of the 2nd issue mentioned in the bug report, specifically, if you use the right-hand select list in the attached test case, the browser will not recognize your selection. Moreover, if you select an item and then open the list again, the selection will still be highlighted. This will continue to occur even if you have three items concurrently selected in the list. Finally, the page failed to fully display; the throbber never ceases. Shall I write a new bug report for this? --- I have not exhaustively looked at the first issue that most of this bug report was devoted to. Chris Kritzer has spent much more time on it, so I defer to him.

Tested on: - MacOS9 2000-07-12-15-M17 Commercial: works fine - Linux6 2000-07-12-21-M17 Commercial: horked; - response time to initial click on dropdown arrow is ~ 8sec - initial click in scrollbar takes ~ 2sec to respond - if you change direction of scrolling, it takes ~ 2sec to respond - Win98 2000-07-12-21-M17 Commercial: works fine Re-opening.

Works fine in mozilla. Only has problems with the Commercial tree on Linux. Changing OS to Linux, Setting ETA.

I was able to reproduce the slow dropdown performance on WINNT, but there should be a separate bug filed to address the speed issue. This bug started out talking about what happens when the mouse pointer is moved outside the scrollbar area and has ended up discussing the general performance of the combobox dropdowns with large number of items (1800+ items.) The speed issue is already covered by bug 44312. As far as I can tell all of the other issues within this bug have been resolved. Marking as fixed. If you have other issues with combobox dropdown please file a separate bug for each issue instead of reopening this bug.

Kevin, I'm confused by your last comments...you say all issues but the one residing in 44312 have been resolved, but you changed the bug to linux and put an ETA of 7/21 in the Status Whiteboard? Does the ETA 7/21 indicate that is build- date when the fix will show up? Or is it for something else? Any clue you could vend my direction would be great... -Kritzer

I put the date in before I realized that most of the bug was already fixed in the current build and that the remaining part of the bug was already covered by a new bug. I was only indicating on what date this bug would be resolved.(However, This does not include bug 44312)

While it is still very slow switching scrolling directions on Linux, it does work. Marking VERIFED FIXED on: - MacOS9 2000-07-25-11-M17 Commercial Build - Linux6 2000-07-25-08-M17 Commercial Build - Win98 2000-07-25-09-M17 Commercial Build