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.