From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; m16) Gecko/20000505 BuildID: 2000050513 When an item or the scrollbar of a dropdown menu is clicked, it causes the mouse to go into "hilite mode". That is, when the mouse is moved around, it hilites the text that it is moved over Reproducible: Always Steps to Reproduce: 1.Go to http://www.mozilla.org/quality/help/bug-form.html 2.Click the down arrow for the "Component" pulldown menu. 3.Click the scrollbar for the dropdown menu once 4.Move the mouse around the page (over text) Actual Results: The text moved over is hilited Expected Results: The text is not affected

Reproduced this bug (sorta) in M15, Mac OS 9.0.4, MRJ 2.2, carbon libs 1.0.4. After linking to the above page, drop down menu scrollbar doesn't work. Scrolling in the menu field does work. Text *does not* highlight, however.

Win98SE build 50608 - Same behaviour

I've seen this for awhile. I assume it's a dup since I never reported it, but I'm not sure.

yes, this is really bad and I don't think it is a dup.

I am tracking this down, the regression occurred sometime between 4/8 and 4/15

The look horrible and really needs to be fixed.

After doing literally 15 or more date/time based pulls I narrowed it down to Mike Judge's MouseCapture checkin on 04/11/00 20:00. I am not sure why it took so long for someone to notice the problem. To reproduce, load the attachment I will be adding, click on the combobox, scroll the scrollbar with the mouse. Now, move the mouse off of the dropdown down. It is in some funky state and thinks we are trying to do selection in the document. Mike, your MouseCapture checkin has horked the dropdown. I am reassigning this to you because you know the capture code.

An additional point is that the dropdown list never gets the MouseUp call as a DOM lsietener. It used to get this.

hmm. ok i guess when D&D start we need to release the mouse capture both system wide and view wide. calling CaptureMouse(context,PR_FALSE) and following up with a selection->SetMouseDownState(PR_FALSE) will stop selection from continuing. the 'Widget(tm)' level capturing is kinda out of my league here. Curently the windows code captures the mouse for the given window when a mouse down occurs. I will fix what I can then you can tell me if thats good enough.

[nsbeta2+]

Is this why I cannot jump to a time at www.tvguide.com/listings/ web site? Go there and pull down the first list to select a different day. Notice nothing happens using mozilla. Now try netscape 4.72 and it works.

this should be fixed in this mornings builds. please verify

Very close! The original behavior is almost all gone. But try this out: (This happens with my 2000051520 build) On the URL associated with this bug, 1. click on the dropdown menu for "component" 2. Scroll the sidebar on this dropdown menu. (notice no text gets hilited) 3. Now, while the dropdown menu is still open, click at the very top of the web page area. All text between the "Component" dropdown menu and where you clicked is hilited. I believe this bug is still related do what was originally filed, and a new bug report does not need to be created, right? -WD

ok got this one fixed. please retest

I do not yet see the problem fixed as of 200051613 Is it just that the fix hasn't been incorporated into the nightly build yet? I tried the latest talkback and regular Win32 builds with the same result as above. I tried a Linux build, and it doesn't quite hilite the text as with Win32, but the behavior is not quite right there either. With the first click (which would have left text hilited on Win32), the drop-down menu disappears but leaves a thin line around where the edge of the dropdown was. A second click elsewhere on the page removes this "ghost outline". The Linux result sounds different than the Win32, but I believe that in both cases, it's caused by improper handling of clicking elsewhere while a dropdown menu is open. When testing, make sure that you move the scrollbar on the dropdown menu up and down before clicking elsewhere. (otherwise, I believe the behavior is normal) -WD

you have to wait for the check in to hit, Mike checked it in around 5:00 or so, your build was made at 1:00. Rule of thumb, wait till the next day to verify a fix.

Ok, Sorry if I'm jumping the gun here, but I'm still seeing this as of 2000051620. What's new about this build is that when I move the scrollbar on the dropdown menu, the *entire page* is scrolled along with it. (along with the text being hilited when I click elsewhere on the page) Re-Open? (I'm still kinda learning the ropes here with BugZilla... sorry)

No problem, and it is confusing as to when to reopen a bug. But, to answer your question - you need to check and see if the original stated issue was resolved. If the original issue is resolved, then go ahead and mark this as verified. Then open a new bug for the new issue. We try to keep one issue per bug, it makes it easier to track.

OK, I've filed the following bugs which I believe are both somewhat related to this original bug: Bug 39601 Bug 39603

39601 and 39602 are duplicates of this bug, because none of this behavior existed before mjudge's fix.

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

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

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

Another issue: after a couple of clicks dropdowns stop dropping down.

ahh i see. just adjust the style on the drop down combo box to be user-select: none. i will check this in when i can.

fixed

Verified