From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020610 BuildID: 2002061108 This page is in dutch and the URL doesn't take you to exact page I mean without the user first ENTERING some information. Eventually you have to choose a "Regio" (=region or province) but there's no way to choose from the menu. Moz 1.0RELEASE has no problems with it. (Bugzilla Search returned many many similars so I suspect this is just another duplicate but the directions on what to do next in that eventuality are cryptic to me to say the least sorry ;) Reproducible: Always Steps to Reproduce: 1.Go to the URL 2.In the pink half of the screen, in the box titled "TREFWOORD" type 'motoren' (as i did) and in the box titled "WOONPLAATS" enter 'eindhoven' (as i did) 3.Click on "Zoeken"; the next page has that drop-down menu titled "GEBIED" which is borked.

wfm with win2k build 20020626.. It is possible that you retest with a nightly build ?

testcase exhibits the bug with linux build 20020625.

regression between builds 2002051621 and 2002051721 marking NEW ==> Form Controls (event handling?)

marking NEW

I backed out the change to EventStateManager and that didn't seem to do anything.

regression from bug 131841 (backed out of old CVS) cc'ing jst

Andrew, are you saying my fix for bug 131841 caused this to break?

It did appear that way (my 20020517 16:00 build seemed to work), but it now appears to be a regression from bug 126480 (verified by backing it in and out of old CVS!). backing out of current CVS also makes current builds work here. sorry for the confusion

-->

I want to get straight what's going on here: the dropdown should be black and not gray when you're hovering over the select, right?

> the dropdown should be black and not gray when you're hovering over the select, > right? I don't know about that... the bug here is that the dropdown will drop down when you click it, but if you then try to mouseover an element to select it, the dropdown will go back up (making it impossible to select anything). :hover works. the drop-down does not. I just tested again (20020721) and it actually worked the first time, but additional attempts did not work.

I'm not seeing that with Win32 2002072108. Perhaps this is Linux-only ...

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

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

from bug 162712: this seems to be triggered by any DOM event while the dropdown is down. in that bug it was onmouseout from the parent <tr>/<td> (attachment 95761 [details])

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

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

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

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

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

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

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

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

OK, the problem is that the GTK widget is calling Rollup() on ButtonPress: http://lxr.mozilla.org/mozilla/source/widget/src/gtk/nsWindow.cpp#1670 The question is why is it doing it in this case, and what do we need to set or check to ensure that it does *not*? Perhaps bryner or blizzard can shed light on this.

If you press a button outside of a popup window when there's a popup window, that popup should roll up. I don't know what the big mystery is.

blizzard, this appears when you click on the select and your mouse is still over the select.

I suppose the event must be targeted at the wrong widget when there is mouseover.

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

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

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

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

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

This html, together with message.css causes the bug to occur - if you get rid of the style (setting the hover color) it goes away.

The style in the stylesheet .smallheader:hover{color:white;} causes this bug to appear in Mozilla 1.3 removing the style gets rid of it.

More details about my investigations into this bug (which I believe should be a higher priority btw imho). I am using Mozilla 1.3 on Linux RedHat 8.0. The bug is easily reproducible by applying a style to the drop down. I have reduced the test case to the below. If you remove the style, the select works as expected. I imagine that this is because the rollup code is invoked by a buttonpress signal which it should ignore since it is caused by the style (wild guess here)? <html><head> <style type="text/css"> .smallheader:hover { color:red;} </style> </head> <body> <select class="smallheader" > <option value="">This message to</option> <option value="Tech-Contacts">Tech-Contacts</option> </select> </body></html>

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

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

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

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

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

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

JFTR: Here is the ~/.mozconfig from the reporter of bug #195329: http://die-moells.de/volker/tests/mozconfig

Maybe a problem concerning GTK-1? I use gtk-1.2.10, and I have this problem. Hartmut Figge confirms in <408EE055.2090502@hfigge.myfqdn.de> the problem. On the other side bug #195329 comment #1 sais that with GTK-2 it works.

(In reply to comment #43) > On the other side bug #195329 comment #1 sais that with GTK-2 it works. I disagree - I've seen this happen in two GTK2 builds including Firefox 0.8.

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

Is bug 149981 related (see attachment 96893 [details] for a testcase)?

P.S. Recently released Gallery 1.5 includes "select:focus" in all its CSS. As a result, all the drop-down menus (which is the main user interaction mechanism in Gallery) suffer from the "tripple-click" problem. See also http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&p=134051

(In reply to comment #47) > P.S. Recently released Gallery 1.5 includes "select:focus" in all its CSS. As a > result, all the drop-down menus (which is the main user interaction mechanism in > Gallery) suffer from the "tripple-click" problem. See also > http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&p=134051 BTW this (the triple-click problem in Gallery) seems to be a Linux-only problem. Now I generally don't believe in Linux-only problems, but this indeed does not seem to affect either Firefox on Windows or Firefox on Mac OS X.

BTW, the "triple click" in Gallery 1.5 is not always a triple-click. Say I am on a certain page and I triple-click a drop-down menu to pull it down. Until I access another page (such as the case when the menu in question has no Javascript and is really a menu), I can now single-click the same drop-down menu. Other drop-down menus still require triple-clicking, but they would also stop requiring triple-clicking after being triple-clicked once. So, if you triple-click all the drop-down menus on the page, then (assuming none of them has Javascript associated with them that will cause a new page to be loaded) the menus will become normal during the time the page stays in the browser window. Once I access another page (e.g., by the Javascript associated with the drop-down menu, by following a link, by pressing a button, etc.), the drop-down menus on the new page reverts to requiring triple-clicking. I hope this helps to pinpoint the problem.

Attachment 176682 [details] [diff] on bug 281551 is a patch that's supposed to fix the "tripple-click" problem.

Quite a few comments suggest it doesn't occur with GTK2. However I can confirm with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421 Firefox/1.0.3 (Debian package 1.0.3-2), that's a GTK2 build. I don't think it matters what the parent tag is either, I can reproduce with a <div> container (http://jon.dowland.name/code/bugs/select-parent-hover.html)

Fixed by the patch for bug 281551. The problem in the testcase that Jon linked to in comment 51 is not solved, but I think that's a different bug and/or needs to be filed as a follow-up bug.