Closed Bug 16037 Opened 26 years ago Closed 24 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)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
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.
*** Bug 20793 has been marked as a duplicate of this bug. ***
*** Bug 15255 has been marked as a duplicate of this bug. ***
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.
*** Bug 29075 has been marked as a duplicate of this bug. ***
*** Bug 27047 has been marked as a duplicate of this bug. ***
*** Bug 16048 has been marked as a duplicate of this bug. ***
Mass-moving bugs out of M15 that I won't get to. Will refit individual milestones after moving them.
Target Milestone: M15 → M16
Don't think this is a beta2 issue
Target Milestone: M16 → M17
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
Please note that this bug also applies to Win9x as well as NT4. Please bump up the priority on this.
*** Bug 28550 has been marked as a duplicate of this bug. ***
Mass update: changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer
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: 25 years ago
Resolution: --- → WORKSFORME
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
Still broken under NT4 (Mozilla build 0822).
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Updating QA Contact.
QA Contact: ckritzer → lorca
*** Bug 56475 has been marked as a duplicate of this bug. ***
*** Bug 56891 has been marked as a duplicate of this bug. ***
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.
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.
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
*** Bug 67145 has been marked as a duplicate of this bug. ***
9 direct dups plus one dup on bug 27047 -> mostfreq.
URL: any
Keywords: mostfreq
Summary: Apprunner menus loose focus and close when using ActiveWindowTracking=1 (X-Mouse) → menus loose focus and close when using ActiveWindowTracking=1 (X-Mouse, "focus follows mouse")
Can someone recheck this in the light of Blizzard's checkin on bug 16766? Gerv
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.
*** Bug 69867 has been marked as a duplicate of this bug. ***
This will be fixed by my patch to bug 50798. Marking dependent on that.
Depends on: 50798
Try this again once tomorrow's builds spin.
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.
marking fixed, from wayyy back
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
QA contact updated
QA Contact: gerardok → madhur
verifying based on gumby@best.com's comments from 2001-05-18.
Status: RESOLVED → VERIFIED
*** Bug 87967 has been marked as a duplicate of this bug. ***
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.