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)

x86
Windows 95
defect

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.
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
oh hyatt....
Assignee: pinkerton → hyatt
Target Milestone: --- → M20
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.
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M20 → Future
*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
Sounds very similar to bug 45108. Marking this dependent on that.
Depends on: 45108
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.
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...
You forgot using SetWindowsHookEx to set a mouse hook. Probably not highly recommended, but it does work.
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).
My patch for bug 45108 works for this as well.
fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
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.