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)

x86
Windows NT
defect

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.
*** 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: 24 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: 24 years ago23 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.