Cannot dismiss menu by clicking on menubar

RESOLVED FIXED

Status

()

Core
Event Handling
RESOLVED FIXED
15 years ago
5 years ago

People

(Reporter: Warner Young, Assigned: Aaron Leventhal)

Tracking

Trunk
x86
All
Points:
---
Bug Flags:
blocking1.3b -

Firefox Tracking Flags

(firefox20 verified)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

15 years ago
To reproduce:
1. Click on any of the toplevel menu choices in menubar (File, Edit, etc.)
2. See the appropriate menu appear.
3. Click again in the same spot.

Expected results:
The menu should be dismissed.

Actual results:
The menu does not go away, and you have to click somewhere else entirely to
dismiss it.  Double-clicking seems to dismiss it, though, so possibly related to
 bug 174204?

This started somet time last week around 08-Nov-2002, I think.  I currently see
this with build 2002111108, Win98, with any theme.  The problem definitely does
not exist on build 2002102208.  I tried looking for dupes, but 174204 is the
closest things I can find.

Comment 1

15 years ago
I can still get this bug to happen on build 2002111108 on Windows 2000.
Click the Tools menu title, slide the cursor over to Window, and click
Window.

Actual results:
The recessed-ness of the Window menu title disappears, but the Window menu
remains active, and continuing to move the mouse among the menus opens menus.

Expected results:
The Window menu disappears, its title goes from recessed to embossed,
and sliding to other menus does not open them.

Workaround:
Click the menubar to the right of QA.  Result: Menu disappears.

Component -> XP Toolkit/Widgets: Menus ?
(Reporter)

Comment 2

15 years ago
This works correctly on build 2002103110.
(Reporter)

Comment 3

15 years ago
The problem exists in build 2002110608, but not 2002110508, so it's something
checked in between 05-Nov and 06-Nov.
(Reporter)

Comment 4

15 years ago
Possibly caused by the patch for bug 66834?

Comment 5

15 years ago
i'm also getting this problem using the nightly from mondays's (20021111) and
also from friday's, though i can't remember how many before that.  i'm using
winme.  it's replicatable always for me as well.

Comment 6

15 years ago
*** Bug 179800 has been marked as a duplicate of this bug. ***

Comment 7

15 years ago
As I commented in bug 66834 comment 81, if you drop down the menu and roll it up
quickly, it works.  If you wait after dropping it down, this bug happens.

Comment 8

15 years ago
I filed bug 179800 about this problem in Phoenix, and it was marked as a
duplicate of this bug. However, I do NOT have this problem in Mozilla, only in
Phoenix.

In other words, this bug worksforme, and bug 179800 should not be a duplicate of
this one.

Comment 9

15 years ago
David, I just repro'd this bug with mozilla on Windows 98, build 2002111204.

Comment 10

15 years ago
update from my end: i just downloaded the 20021116 nightly, and first thing i
try is this bug, and i still get it.  reproducable: always.  themes: all i've tried.

the double-click thing mentioned in the bug report gets rid of it for me. 
something interesting i've found, however, is that when you click on the "go",
then click again because you want to close the menu, the menu *shortens* to
back/forward/home/history only.  again, double clicking will completely close it
like i wanted in the first place.

Updated

15 years ago
QA Contact: rakeshmishra → trix

Comment 11

15 years ago
*** Bug 181521 has been marked as a duplicate of this bug. ***

Comment 12

15 years ago
I don't get this. I see this with every theme in Phoenix, but I simply cannot
reproduce it in Mozilla.

Comment 13

15 years ago
I can reproduce this on Mozilla 1.3a (build 20021119) and Phoenix 0.4 (build
20021128).

I also observe the following interesting effect wrt comment 10:

Clicking the Go menu opens fine, then waiting and clicking again (so as to have
it not close) the menu shrinks as per comment 10. Now, if I click the Go menu
item again, the menu stays visible, small (i.e. missing the history) but I see a
flash of the menu popup border for the full sized menu - like it was showing
full-size, then imediatly being reduced to the small version.

Not sure if that's any use to anyone, just found it a bit odd.

Comment 14

15 years ago
*** Bug 183249 has been marked as a duplicate of this bug. ***

Comment 15

15 years ago
At last, I'm able to reproduce this in Mozilla. I don't know what was "wrong"
before, but I only saw this on Phoenix.

OS > All
OS: Windows 98 → All

Comment 16

15 years ago
Aaron, did you cause this?  This is really bad, it needs to be assigned to
someone who will actually fix it.

Comment 17

15 years ago
problem continues in phoenix 0.5 (20021207), and i must say i'm disappointed
that a phoenix milestone shipped with this bug unfixed.  btw, i do _not_ see
this behavior in mozilla 1.2.1.
(Assignee)

Comment 18

15 years ago
Taking
Assignee: joki → aaronl
(Assignee)

Comment 19

15 years ago
Created attachment 108764 [details] [diff] [review]
Proposed fix, need pinkerton or hyatt 's input

I believe this is necessary now that win32 menus don't consume outside clicks.
(Assignee)

Updated

15 years ago
Attachment #108764 - Flags: superreview?(hyatt)
Attachment #108764 - Flags: review?(pinkerton)
Comment on attachment 108764 [details] [diff] [review]
Proposed fix, need pinkerton or hyatt 's input

ok, if you say so. 

r=pink
Attachment #108764 - Flags: review?(pinkerton) → review+
(Assignee)

Updated

15 years ago
Attachment #108764 - Flags: superreview?(hyatt) → superreview?(bryner)

Updated

15 years ago
Flags: blocking1.3b?

Updated

15 years ago
Flags: blocking1.3b? → blocking1.3b-
Comment on attachment 108764 [details] [diff] [review]
Proposed fix, need pinkerton or hyatt 's input

sr=bryner.  I tested this on Linux and didn't see any problems (the original
bug doesn't happen there either).
Attachment #108764 - Flags: superreview?(bryner) → superreview+

Comment 22

15 years ago
I caused a similar regression a while back when I first tried to fix bug 30841.
 Because of the regression, the fix was backed out.  Apparently there was a lot
of PR1 feedback about menus not dismissing (see bug 30841 comment 74).  We
should either get this fix in or back out the fix for bug 66834.

Aaron: See also bug 30841 comment 64 for some general ramblings, if you're curious.
(Assignee)

Comment 23

15 years ago
fixed
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
(Reporter)

Comment 24

15 years ago
Yup, seems fixed in build 2003010304, Win98.

Comment 25

15 years ago
I can now dismiss the menu by clicking on its name but can't dismiss it by
clicking anywhere else in the window.
Using Mozilla 2003010308 on Windows XP.

Comment 26

15 years ago
Very true.  I assume that problem is because of this, but can someone verify
that it is indeed this patch that causes that problem?  If so, we need to back
this out.

Too bad, because it looks like this also fixes bug 26550.

Comment 27

15 years ago
Comments 25 and 26 are bug 187631, "Menus not clearing when cursor is off menu
focus".

Comment 28

15 years ago
*** Bug 182436 has been marked as a duplicate of this bug. ***

Comment 29

15 years ago
Aaron, you need to back this out.  Menus are worse than before this check-in.
(Assignee)

Comment 30

15 years ago
Backed out, becuase of bug 187631.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 31

15 years ago
Created attachment 111456 [details] [diff] [review]
New fix that shouldn't regress anything. Keeps track of the last rolled up menu so we don't open it from the same click.
Attachment #108764 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #111456 - Flags: review?(bryner)

Updated

15 years ago
Keywords: mozilla1.3
(Assignee)

Comment 32

15 years ago
Created attachment 111545 [details] [diff] [review]
Minor changes
Attachment #111456 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
Attachment #111545 - Flags: review?(bryner)
(Assignee)

Comment 33

15 years ago
Comment on attachment 111456 [details] [diff] [review]
New fix that shouldn't regress anything. Keeps track of the last rolled up menu so we don't open it from the same click.

Removing review request for old patch.

Review newer patch isntead.
Attachment #111456 - Flags: review?(bryner)
Attachment #111545 - Flags: review?(bryner) → review+
(Assignee)

Updated

15 years ago
Attachment #111545 - Flags: superreview?(bzbarsky)
I will likely not be able to get to this till after the freeze.
(Assignee)

Comment 35

15 years ago
Comment on attachment 111545 [details] [diff] [review]
Minor changes

Okay, maybe Jag can get to it before the freeze?
Attachment #111545 - Flags: superreview?(bzbarsky) → superreview?(jaggernaut)

Comment 36

15 years ago
Comment on attachment 111545 [details] [diff] [review]
Minor changes

sr=jag
Attachment #111545 - Flags: superreview?(jaggernaut) → superreview+

Comment 37

15 years ago
Fix checked in.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 38

5 years ago
Verified fixed on the latest beta, Firefox 20 beta 6. (Build ID: 20130320062118)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0
User Agent: Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20100101 Firefox/20.0
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0
Setting this verified fixed based on comment 38. Thanks Mitza!
status-firefox20: --- → verified
You need to log in before you can comment on or make changes to this bug.