Closed Bug 154670 Opened 22 years ago Closed 19 years ago

drop-down select menu closed by DOM/CSS events.

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mbmarduk, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(2 files, 2 obsolete files)

screenshot
5.94 KB, image/gif
Details
testcase
732 bytes, text/html
Details 
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.
Attached image screenshot — 
wfm with win2k build 20020626..

It is possible that you retest with a nightly build ?
Attached file testcase — 
testcase exhibits the bug with linux build 20020625.
regression between builds 2002051621 and 2002051721

marking NEW
==> Form Controls (event handling?)
Assignee: sgehani → rods
Component: XP Apps → HTML Form Controls
Keywords: regression
QA Contact: paw → tpreston
Summary: drop-down menu doesn't work (Moz1.1alpha) → drop-down select menu does not work with :hover
marking NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Depends on: 131841
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
Depends on: 126480
No longer depends on: 131841
-->
Assignee: rods → jkeiser
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])
Summary: drop-down select menu does not work with :hover → drop-down select menu closed by DOM events.
*** Bug 164207 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
*** Bug 170447 has been marked as a duplicate of this bug. ***
Keywords: testcase
*** Bug 172111 has been marked as a duplicate of this bug. ***
Blocks: 163503
*** 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. ***
Summary: drop-down select menu closed by DOM events. → drop-down select menu closed by DOM/CSS events.
*** 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. ***
Priority: -- → P2
Target Milestone: --- → mozilla1.4alpha
*** Bug 177817 has been marked as a duplicate of this bug. ***
Blocks: 113492
*** Bug 199596 has been marked as a duplicate of this bug. ***
Attached file Simple test case caused by css style (obsolete) — 
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.
Assignee: john → nobody
Status: ASSIGNED → NEW
Depends on: 281551
QA Contact: tpreston → layout.form-controls
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)
Attachment #119060 - Attachment is obsolete: true
Attachment #119061 - Attachment is obsolete: true
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Priority: P2 → --
Resolution: --- → FIXED
Target Milestone: mozilla1.4alpha → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: