Closed Bug 11266 Opened 25 years ago Closed 25 years ago

[PP][DOGFOOD] XPMenus wont go away

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: icos, Assigned: pavlov)

References

Details

(Whiteboard: [BETA] All platforms done) 

After bringing down an XP Menu (say, the file menu), the dropdown wont go away
until you click something on it.

This is not normal Windows behavior, and it really needs to "cancel" the
dropdown after clicking outside of the menu.

1998080312 build. Also, the dropdown boxes stay on top even after switching
focus to another Windows task. This is bad. I'm sure you are aware of this, but
thought I'd report it anyway.
Assignee: trudelle → hyatt
Target Milestone: M10
I don't see an obvious dup of this, reassigning to hyatt as p3 for m10.
*** Bug 11006 has been marked as a duplicate of this bug. ***
*** Bug 11194 has been marked as a duplicate of this bug. ***
adding myself to cc: list.
Summary: XPMenus wont go away → [DOGFOOD] XPMenus wont go away
Adding DOGFOOD designation.  It's really hard to use the app with this problem
-- if you ever click on a toplevel menu, you're forced to choose an item in it,
because otherwise the menu will stay posted even when you switch to other
desktops.
a cheezy workaround is to click on the menu name to close a menu.
so click "File", and if decide you don't want anything in that menu, click
"File" again and it will go away.
*** Bug 11137 has been marked as a duplicate of this bug. ***
*** Bug 11664 has been marked as a duplicate of this bug. ***
*** Bug 11343 has been marked as a duplicate of this bug. ***
*** Bug 11338 has been marked as a duplicate of this bug. ***
*** Bug 12061 has been marked as a duplicate of this bug. ***
*** Bug 12014 has been marked as a duplicate of this bug. ***
adding myself and cpratt to the ridiculously long cc list. Sorry all.
*** Bug 12092 has been marked as a duplicate of this bug. ***
*** Bug 12606 has been marked as a duplicate of this bug. ***
Blocks: 12670
*** Bug 13209 has been marked as a duplicate of this bug. ***
*** Bug 13461 has been marked as a duplicate of this bug. ***
*** Bug 11851 has been marked as a duplicate of this bug. ***
*** Bug 12773 has been marked as a duplicate of this bug. ***
*** Bug 13542 has been marked as a duplicate of this bug. ***
*** Bug 13611 has been marked as a duplicate of this bug. ***
Just a thought:

why not have a routine to kill the menu (just use the same code as when the ESC
key is pressed) and have that routine called anytime:

1) a [left] Click is received within Mozilla that is NOT on the menu
2) a [left] click received on the menu toolbar but not on an actual menu trigger
(file, edit, etc)
3) Mozilla loses application focus
4) escape key is hit (taken care of)

It seems that this bug is a big thorn in the ass, but easy to pull out.

-andrew
Severity: major → critical
OS: Windows 98 → All
This is also a serious problem in terms of HTML form controls that use gfx. For
example, on Win32, if you go to http://schist/forms/select.html, drop down the
list, and then switch to another app, the list is displayed on top of everything
else.
mass targetting m11
Priority: P3 → P2
bumping priority to p2 due to the number of dups. CPratt, I don't think this
qualifies as Critical severity, which is for crashes, loss of data, severe
memory leaks.
Severity: critical → major
QA Contact: phillip → cpratt
trudelle, you're right. (my bad - didn't grok that.) resetting severity to major
'cuz it is a major usability problem. thanks!

also changing qa contact to self to ease the burden on phillip.
Blocks: 12649
*** Bug 14172 has been marked as a duplicate of this bug. ***
My hands have deteriorated to the point where I can no longer type.  I need
help.  If you think you can fix this bug on your own, please take it away from
me.  If you'd like to volunteer to be my hands for a specific bug, then I'll be
happy to come up to your cube and sit with you and fix the bug (assuming you
have the patience for that).
I can help with typing/debugging menu issues on Linux.
Whiteboard: [BETA]
A similar problem seems to have been fixed recently for combo-boxes, so maybe
Rod can provide some advice on this bug.
mass migration to m10
this bug is now fixed on windows.  it should now be split into two bugs.  one
for mac and one for linux.  the bugs may already be filed... rod would know.  On
linux CaptureRollupEvents is not implemented but Pavlov is working on it and on
Mac the widget bounds check appears to be #ifdef'd out which means menus only
dismiss if you click on the desktop.  I assume that the combo box has both of
these problems and so this bug is almost fixed.
Status: NEW → ASSIGNED
Whiteboard: [BETA] → [BETA] Win32 done. Dependent on bugs on Mac and Linux
Assignee: hyatt → pavlov
Status: ASSIGNED → NEW
Whiteboard: [BETA] Win32 done. Dependent on bugs on Mac and Linux → [BETA] Win32 and Mac done. GTK pending.
The bug that messed up menus on the Mac was my fault. I was using the wrong CID.
Only the Mac really cared.  saari will be checking in the fix.  This means GTK
is the only platform for which dismissal is still a problem.

Marking this bug as [PP] and reassigning to pavlov.
Summary: [DOGFOOD] XPMenus wont go away → [PP][DOGFOOD] XPMenus wont go away
*** Bug 9293 has been marked as a duplicate of this bug. ***
*** Bug 14937 has been marked as a duplicate of this bug. ***
OS: All → Linux
I can verify that the fixes are in and working for the 1999092609 build on Win32
and Mac, and the bug still exists on Linux (as hyatt stated). Changing platform
to Linux.
just checked in code to make them dismiss if you click somewhere in our app...
clicking elsewhere still causes problems
*** Bug 15023 has been marked as a duplicate of this bug. ***
Target Milestone: M10 → M11
moving to m11
partial fix checked in.  problem with capturing happening before the window is
visible.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
uh.. oh yeah.. i fixed this
Status: RESOLVED → REOPENED
umm, no. If I click on a menu and then click on a non-apprunner window
the menu does not go away, moreover it comes to the front of the other app.
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
this is fixed.  squiddy just verified it
Status: RESOLVED → VERIFIED
yeah, this seems fixed in the m11 branch. don't know about m10 though - perhaps
claudius was using a m10 build. marking verified fixed using the 1999100908
build, NT.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Dang it, I hate it when the problem shows up a few minutes after verifying it as
fixed. Using the 1999100908 M11 build, the problem is still there... eventually.
Trust me, it's really still there! For example, if you switch to another app and
then back to apprunner, click in the Location: control and start typing a URL,
eventually you'll probably type a key that will drop down a menu (File, Edit,
etc.). Reopening and clearing resolution.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Whiteboard: [BETA] Win32 and Mac done. GTK pending. → [BETA] All platforms done
you are seeing a different bug.  I can't find its bug number, but i saw it
yesterday.  The problem described in this bug is fixed.

Switching apps using ALT tab will cause ALT to be pressed which causes the menu
to become "active" so when you come back in the menu is still active so when you
start typing it applys those keys to the menu that is active.
see bug #15983
Status: RESOLVED → VERIFIED
This time, I really mean it. Marking verified (problem covered fine in other
bug).
*** Bug 15905 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.