Closed Bug 18598 Opened 25 years ago Closed 25 years ago

menus take focus on "alt," then behave in a non-standard way

Categories

(Core :: XUL, defect, P4)

Product:
Core
Component:
XUL
Platform:
Other
Other
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: frantb, Assigned: hyatt)

References

Details

(Whiteboard: [PDT+]) 

What happens is this:
I hit "alt" and the file menu gets focus as it should but two odd things can
happen. First, it seems that more things should remove that focus. In most
programs, moving the mouse is enough to take focus off the menu, but even
clicking the mouse elsewhere doesn't take that focus off of the file menu. This
is particularly anoying because if I alt+tab(in windows) through the list all
the way back to mozilla, when I release alt, the menu gets focus again, so when
I hit the down arrow to scroll down the page the file menu popps up instead.

What is more weird is this: If I'm typing in a URL (or any other text box) and
hit alt for whatever reason, both the menu and the text entry box get the
keybord strokes, so if my url contains one of the key letters for a menu, that
menu pops up *and* that letter gets typed.

I think 1) any mouse movements should take focus from the menu and 2) if the
menu has focus it shouldn't let an active text box or whathaveyou get keybrod
strokes as well.


Build: 1999111008 and earlier
OS: Linux, Windows 98
Assignee: trudelle → saari
reassigning to saari
spam: changing qa contact from ckritzer -> paulmac for xul bugs
Priority: P3 → P4
Target Milestone: M15
Mouse movement should only change the focus when you mouse over a different menu
title.  Clicking anywhere should remove the old focus, as should switching
windows. The other, wierd problem, is reported elsewhere.
targetting p4 for m15
Component: XUL → XPMenus
QA Contact: paulmac → sairuh
still a problem in 1999121509 (on winNT). Paul, shouldn't this go under XPMenus
instead? (otherwise, change back to XUL and reassign QA as needed.)
trudelle:  If by other weird problem you mean keystrokes going to both the URL
bar and the menu, I'd like to know what bug is specifically handling that.
That particular "feature" has been driving me up the wall and I've been looking
for the bug dealing with that.  If this isn't the one, I was hoping you could
point me to the right one.
Component: XPMenus → XP Toolkit/Widgets: Menus
BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus.  XP 
Menus component will be deleted.
Pink, I'm pretty sure most of these issues are fixed, but I'll let you make the call
Assignee: saari → pinkerton
Target Milestone: M15
Yes, this is fixed.  No more double keystrokes.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
just spoke w/paulmac, and he's still seeing this. moreover, the original
reporter still sees this too. here's the email frantb@rpi.edu sent:

Unless something has been modified within the last few days I still find one
problem with the alt menu behavior. Both in windows and Linux, if I alt+tab
from mozilla all the way through back to mozilla, mozilla behaves as thought
the user taped alt (the menu becomes active). Most programs ignore the alt
they recieve under those conditions.

--Ben FrantzDale

PS
I have one other issue with Mozilla's behavior around alt and menus. In all
programs that I can think of, if hitting alt activates the menus, then the
mouse moving by just a pixel takes the focus back from the menus. In mozilla
you have to hit alt again or escape. It looks as though the current behavior
is the one that is intended (so it's not exactly a bug) but I find it a bit
anoying especially because it's non-standard behavior.
Status: RESOLVED → REOPENED
Keywords: beta1
Resolution: FIXED → ---
to reproduce on windows 2/14, simply
1. launch mozilla
2. alt-tab to another app
3. alt-tab back to mozilla

Results: Focus will be in menus. You must Esc to get out
Expected Results: Shouldn't have focus in menus on alt-tab
this is yours hyatt.
Assignee: pinkerton → hyatt
Status: REOPENED → NEW
Oops.  I just regressed the ALT+TAB.  I'll get that one fixed again.

Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
I don't think this is a big deal.  You really want it PDT+?
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT]
Are you saying you can't fix it? :-)

I definitely think this is a big deal. Alt-tab is the main way I switch windows
and I don't want to press Esc every time I come back to mozilla. It would be
better if clicking in a text field removed the focus from the menus, but it
doesn't. That might even be a different bug. Plus it took me awhile to notice
that the focus had shifted up there, and then you have to know to press Esc.
Whiteboard: [PDT]
Ok, will try to fix it.
Whiteboard: [PDT+]
*** Bug 28119 has been marked as a duplicate of this bug. ***
so the pdt+ part of this bug is that clicking in the browser window doesn't 
steal focus back from the menus if you got there via the alt key. I really don't 
care too much if alt-tab puts focus up there as long as you can get it out with 
a click. Of course, you probably already knew this, but I like to hear myself 
think.
*** Bug 15048 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
fixed.
There are two bugs that deal specifically with key events going to both
menus and other objects after switching focus (and nothing else), depending on 
which way the focus moved.

For keys continuing to get to browser objects as well as the menubar after
giving focus to the menubar (by keying): bug 22782, "Arrow/letter keys get to 
browser when menu is active". This one no longer seems to be happening.

For keys continuing to get to the menubar after taking focus from the menubar:
bug 24335, "Keypresses continue to get to menu after focus moved away"
This also does not seem to be happening with 2000-02-17-08-M14 on WinNT;
instead, the focus just isn't moving away from the menu with a click elsewhere.

The ALT-focus from ALT-TABbing is explained to death in bug 15048... 
essentially, the menubar gets focus as Mozilla is ALT-TABbed *away from*.

But the menubar isn't either giving up *or* using focus after a single ALT 
typed on purpose either - ALT+F gets the File menu displayed, ALT,F is a 
no-op. That's another bug to be REOPENed unless you'd rather keep it all here.
Attempting to use arrowkeys to display menus after the bare ALT instead of
letterkeys creates a 100% CPU hang pretty quickly... another regression.
In general, if the menubar gets focus from a bare ALT, it's messing up badly.

Is the fix fixing all of that, or should I go looking for bugs to REOPEN?

This bug (as I read it) tracks problems with ALT, specifically

(1) ALT+Tab causing the menus to activate.
(2) not being able to mouse down in the menu's window to dismiss the menu.

Both of these were fixed.
I'd make separate bugs for any new issues.  Let's treat this as the ALT+TAB 
issue only.

Ok, I was suspecting that the other two problems may have been fixed by the
same fix, given that they regressed recently. Both are old bugs that had been
fixed once or twice before, so if they aren't fixed in the nightly binary for 
Win32, I'll track them down to reopen them.
verif on winNT and linux (n/a for mac) using 2000021808 opt comm bits. works
fine --alt+tab happily switches btwn app windows.
Status: RESOLVED → VERIFIED
Happily, both of the other problems noted (alpha key not popping up menu when
menubar has focus from ALT; arrowkeys causing 100% CPU hang in same 
circumstance) are gone in the 2000-02-18-08-M14 nightly binary on WinNT.
Just as glad not to need to REOPEN anything... thanks for fixing this right.
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: bugzilla → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.