Closed
Bug 39276
Opened 24 years ago
Closed 24 years ago
ALT+F+TAB fails to dismiss menu if moused over
Categories
(Core :: XUL, defect, P3)
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: neil, Assigned: hyatt)
References
Details
Steps to reproduce problem:
1. Hold ALT.
2. Press F (or any other accelerator).
3. Move the mouse over the menu.
4. Press TAB to switch to another application.
Expected behaviour:
File menu is dismissed when TAB key is pressed.
Actual behaviout:
File menu remains over other application.
N.B. Even when the mouse is not over the menu,
the menu doesn't dismiss until after the TAB key is released.
Basically the WM_CANCELMODE message is being ignored.
Comment 1•24 years ago
|
||
Confirmed with the 2000-05-12-20 nightly binary on WinNT. This may be Win-only.
The serious part of this is that the menu ends up floating over the other
application window after the ALT+TAB takes effect, with no way to dismiss it
short of returning to the Mozilla window. No such problem with NN 4.72.
OTOH, ALT+F+{mouseover File menu}+TAB is surely rare compared to
ALT+F,{mouseover File menu},ALT+TAB
... in other words, someone who shifts from keyboard to mousing use of the
menubar will probably have let up the ALT, so if they decide instead to
ALT+TAB, that would entail a fresh press of ALT, and that works fine.
So this problem is indeed minor.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: 4xp
Summary: ALT+F,TAB faila to dismiss menu if moused over → ALT+F+TAB fails to dismiss menu if moused over
Reporter | ||
Comment 3•24 years ago
|
||
Another way to demonstrate the bug:
1. Move the mouse somewhere below the menu.
2. Hold down ALT.
3. Press the accelerator that drops the menu under the mouse.
4. Press TAB.
5. Release TAB and ALT keys.
Comment 4•24 years ago
|
||
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
Comment 5•24 years ago
|
||
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.
QA Contact: sairuh → jrgm
Comment 6•24 years ago
|
||
Sounds very similar to bug 45108. Marking this dependent on that.
Depends on: 45108
Comment 7•24 years ago
|
||
Like bug 45108, this transitively looks very similar to bug 39841,
and thus similar to who-knows-which bug blocking the meta bug 25684,
"[crash] modal windows/dialogs are not 100% modal".
Are menubar menus with :hover modal to the window they arise from? It appears
not -- a menu that ends up floating over all windows after reproducing this bug
can be dismissed by clicking on a /different/ Mozilla window! OTOH, without
:hover, a menubar menu *always* dismiss when the window it arose from is
switched away from.
This bug still exists in the 2000-09-01-10-M18 nightly binary on WinNT.
Reporter | ||
Comment 8•24 years ago
|
||
That would depend on how :hover is implemented. Unfortunately there are several
ways to do it:
1. Use TrackMouseEvent function from USER32.DLL in Windows NT4 or 98 but not 95
2. Use _TrackMouseEvent from COMCTL32.DLL (installed by IE3 or later?)
3. Use a timer as documented in Microsoft knowledgebase article Q183107
4. Use SetCapture and WM_CANCELMODE
N.B. This doesn't work properly with topmost windows.
WM_CANCELMODE must be caught to detect a task switch or system event.
I suspect that Mozilla is relying on SetCapture without WM_CANCELMODE...
Comment 9•24 years ago
|
||
You forgot using SetWindowsHookEx to set a mouse hook. Probably not highly
recommended, but it does work.
Comment 10•24 years ago
|
||
Requirements for _TrackMouseEvent:
Windows NT/2000: Requires Windows 2000 (or Windows NT 4.0 with Internet Explorer
3.0 or later).
Windows 95/98: Requires Windows 98 (or Windows 95 with Internet Explorer 3.0 or
later).
Comment 11•24 years ago
|
||
My patch for bug 45108 works for this as well.
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•