Closed
Bug 16037
Opened 25 years ago
Closed 23 years ago
menus loose focus and close when using ActiveWindowTracking=1 (X-Mouse, "focus follows mouse")
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P3)
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: juhaj, Assigned: joki)
References
Details
Overview Description: Using the menubar menus with ActiveWindowTracking (a.k.a. X-Mouse), the menus will only work with the mouse button held down all the time you navigate the menus if you simply click the menu topic and start moving your mouse downwards, the menu vanishes as soon as you leave the menubar area, that is, you reach the menu itself. Is this possibly the intended behaviour? X Window menus usually behave this way. If the menu is invoked with Alt-<letter>, using keyboard to navigate the menus works fine. Also, if the menu is invoked with mouse click, keyboard navigation works as long as the mouse pointer is not moved meanwhile. Context (right-click) menus work fine both with mouse and with keyboard. Steps to Reproduce: As a little background information, ActiveWindowTracking makes windows's window manager change the focus as the mouse pointer moves from one window to another without the need to click on the new window. It also allows the user to type into a window which has focus but IS NOT brought to the foreground but stays in back. A click is needed to bring it to the foreground. This is quite like the X Window system behaviour and hence the nickname X-Mouse. Steps: 1) Run regedt32 and navigate to the following registry key (the path may be wrapped): "HKEY_CURRENT_USER\Control Panel\Mouse\" and add a new value, named ActiveWindowTracking, of type REG_DWORD and set it to 0x01. 2) Log out and log back in. (To reread the registry hive.) 3) Run apprunner.exe 4) Point to the menu, click (and release the button) and start moving mouse downwards. Actual Results: Menu vanishes, i.e. it is closed. Expected Results: First menu item is highlighted and menu is not closed until another mouse click. Build Date & Platform Bug Found: MileStone 10 Build ID: 1999100618, Apprunner.exe, Windows NT all builds Nightly Build ID: 1999100908, Apprunnere.exe, Windows NT 4.0 all builds. Bug NOT Found: MileStone 10 Build ID: 1999100618, Viewer.exe, Windows NT all builds Nightly Build ID: 1999100908, Viewer.exe, Windows NT 4.0 all builds. Additional information: An almost identical bug exists in the Bookmarks menu in the Location Toolbar in Communicator 4.x and Navigator 4.x! Also, viewer.exe does NOT exhibit this behaviour.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M15
Confirmed NT4. Note: to enable active mouse tracking (X-style mouse focus), change the following registry value [HKEY_CURRENT_USER\Control Panel\Mouse] "ActiveWindowTracking"=dword:00000001 one, and relogon. Or use the MS supplied X-mouse program. The problem propably exists in at least W2000, as well.
Assignee | ||
Comment 7•24 years ago
|
||
Mass-moving bugs out of M15 that I won't get to. Will refit individual milestones after moving them.
Target Milestone: M15 → M16
Assignee | ||
Comment 9•24 years ago
|
||
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M17 → Future
Comment 10•24 years ago
|
||
Please note that this bug also applies to Win9x as well as NT4. Please bump up the priority on this.
Comment 11•24 years ago
|
||
*** Bug 28550 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
Comment 13•24 years ago
|
||
I'm not seeing this on: - LinuxRH62 2000-08-22-06-M18 Commercial - Win98 2000-08-22-08-M18 Commercial - MacOS86 2000-08-21-08-M18 Commercial Marking WORKSFORME
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Comment 14•24 years ago
|
||
Marking VERIFIED WORKSFORME on: - LinuxRH62 2000-08-22-06-M18 Commercial - Win98 2000-08-22-08-M18 Commercial - MacOS86 2000-08-21-08-M18 Commercial
Status: RESOLVED → VERIFIED
Comment 15•24 years ago
|
||
Still broken under NT4 (Mozilla build 0822).
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Comment 17•24 years ago
|
||
*** Bug 56475 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
*** Bug 56891 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
still broken, build 20001119 mtrunk, as well as ns6. pure speculation - as mouse moves from menubar header to pulldown menu, window activation first deactivates header "window", in order to switch from hover:active to open="true", thus inactivating the separate pulldown "window". correcting a basic css state change in chrome, however, seems an unlikely way to approach this.
Comment 20•24 years ago
|
||
I've accidentally discovered a workaround for this problem (at last under Windows 98.) The TweakUI powertool supplied by Microsoft allows you to set not only the "Activation follows mouse" setting but also allows you to set an "Activation delay". If you set this delay to any non-zero value the problem goes away.
Comment 21•24 years ago
|
||
Reassigning QA Contact for all open and unverified bugs previously under Lorca's care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Comment 22•24 years ago
|
||
*** Bug 67145 has been marked as a duplicate of this bug. ***
Comment 23•24 years ago
|
||
9 direct dups plus one dup on bug 27047 -> mostfreq.
Comment 24•24 years ago
|
||
Can someone recheck this in the light of Blizzard's checkin on bug 16766? Gerv
Comment 25•24 years ago
|
||
Rechecked this bug under Mozilla 0.8, Windows 98 Second Edition. Bug still exists as described. Workaround suggested above to use TweakUI to set "Activation delay" to non-zero also still works as described.
Comment 26•24 years ago
|
||
*** Bug 69867 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
This will be fixed by my patch to bug 50798. Marking dependent on that.
Depends on: 50798
Comment 28•23 years ago
|
||
Try this again once tomorrow's builds spin.
Comment 29•23 years ago
|
||
Thank you for fixing this! This is fixed for me as of 0.8.1, on both 98 and NT. This was a huge bug for me, because I refuse to turn off X-Mouse.
Comment 30•23 years ago
|
||
marking fixed, from wayyy back
Status: REOPENED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 32•23 years ago
|
||
verifying based on gumby@best.com's comments from 2001-05-18.
Status: RESOLVED → VERIFIED
Comment 33•23 years ago
|
||
*** Bug 87967 has been marked as a duplicate of this bug. ***
Updated•5 years ago
|
Component: Event Handling → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•