which selects a menu, usually the File menu. Then usually I click to focus the URL bar, but the menu stays detented or even raised. /be
*** Bug 15983 has been marked as a duplicate of this bug. ***
reassigning to saari.
Mass-moving non-PDT+ bugs to M13
*** Bug 17749 has been marked as a duplicate of this bug. ***
Confirmed for all Win32 nightly binaries I've used since M10, exactly as reported. Based on the first 11/29/99 comment in bug 17749, this is likely XP for all Window Managers that use ALT-TAB to switch windows. * Steps to Reproduce: (There is an additional wrinkle that causes an inconsistency as annoying as the bug is.) 0. Be sure there are at least 3 active programs on a Win32 box. 1. Switch to any Mozilla window, press-and-release the ALT key iff the File menu is highlighted (currently, a subtle detent). 2. ALT-TAB away from Mozilla, ALT-TAB back. 3. Repeat (2) a few times, watching for the subtle highlighting of the File menu. 4. ALT-TAB-TAB away from Mozilla, ALT-TAB back. 5. Repeat (4) a few times, watching for the subtle highlighting of the File menu. * Actual Results: In steps 3 and 5, the Menubar will be activated upon arriving at a Mozilla windows by ALT-TABbing to it *every second time*. This must be because a spurious ALT event is being generated each time; the first time activates the menubar, the second time unactivates it. * Expected Results: The Menubar will never be active upon ALT-TABbing to a Mozilla App. * Additional Information: Normally in Win32, a single ALT activates the menubar, highlighting the first menu but not dropping it down; at this point a menu accelerator keys and cursor keys can be used to choose an item from one of the menus, or another press-and-release of ALT unactivates the menubar, returning focus to wherever it was.
There seem to actually be two bugs here, corresponding to the two sentences of the original bug report. The first is that a spurious ALT is happening upon ALT-TABbing to any Mozilla App - see the second 1999-12-05 comment for details. The other is that clicking inside an edit field does not take focus away from the menubar as it gives focus to the edit field. This part of the bug is much more general than the original summary. If the menubar has focus just before *any* edit field (Location bar, <input>, <textarea>, and just about any UI element in Message Compose or Composer) is given focus, typing in it will both add characters to the edit field *and* activate, in turn, any menu or submenu for which a typed character is an accelerator key that is valid in the current state of the menu expansion ("e","f" does Edit>Preferences, while "f","e" does File>New). Simplest way to reproduce: 1. Press-and-release the ALT key once or twice to give focus to the menubar (visible highlighting of File menu without it being raised). 2. Click anywhere that text can be entered. 3. Type some text including "f", "e", or another character that is a primary menu accelerator key. Actual Results: A. After step 2, the menubar still shows that it has focus. B. As above: typed keys affect both the edit field and the menubar. Expected Results: A. After step 2, the edit field has focus and the menubar does not. B. Text typed into the edit field in step 3 does not affect the menubar. Tested with: 1999-12-12-08-M12 nightly binary on Windows NT 4.0sp3 Additional Information: The second part of this bug looks like the converse of bug 18844, "Type ALT+F, L,N,O, to get "lno" appended in Location bar" -- which does exactly that iff text was being typed into the Location bar immediately before activating the menubar (also works for other edit fields). QA: should this bug be split into two bugs? Both parts can happen independently, but both are needed to reproduce the annoying part of the reported problem: raising of menus and submenus while typing after ALT-TABbing to Mozilla.
Summary: alt-tabbing to apprunner creates spurious ALT events → ALT-Tabbing away from Mozilla creates spurious ALT events
A telling detail about the "spurious ALT event" part of this bug: the spurious ALTs are not occuring when ALT-TABbing *to* Mozilla, but when ALT-TABbing *away from* Mozilla! To see this follow the following steps: Steps to reproduce: 1. Launch Mozilla (or Mozilla's Mail or Composer) and at least one other program, if another is not already running. 2. Resize and/or reposition the other program so that it will not obscure Mozilla's menubar when it is topmost. 3. Raise Mozilla's window and make sure that Mozilla's menubar does not have focus (Press-and-release ALT once iff it does). 4. ALT-TAB to the other program; observe the "File" part of Mozilla's menubar. 5. ALT-TAB back to Mozilla; observe the "File" part of Mozilla's menubar. 6. Repeat steps 4 and 5 at least 3 times to see the pattern. Actual Results: A. The first time and all odd times through step 4, Mozilla's menubar will receive focus from an ALT event *just before the task-switch to the other program* (you may need to use a very slow machine and load down the CPU or turn off graphics acceleration to confirm this ordering). B. The first time and odd times through step 5, the highlighting of the "File" part of Mozilla's menubar will be clearly visible in the inactive Mozilla window, *and* after returning to Mozilla. Note that the latter would not happen if the spurious ALT was created on ALT-TABbing *to* mozilla. C. In all even times through steps 4 and 5, the menubar will visibly lose focus *just before the task-switch to the other program*. D. Actual Result (A) can be absolutely confirmed by following the steps up to step 4, switching back to Mozilla by clicking on Mozilla's titlebar, then typing "e" to see the edit menu drop down. Expected Results: The ALT-TAB event will be passed off to the Win32 system without having any effect on Mozilla whatsoever. This detail is so easy to miss - after all, who ALT-TABs back to Mozilla without ALT-TABbing away first? Tested with: 1999-12-15-17-M12 nightly binary on Windows NT 4.0sp3 Changing summary from "alt-tabbing to apprunner creates spurious ALT events" to "ALT-Tabbing away from Mozilla creates spurious ALT events"
*** Bug 17167 has been marked as a duplicate of this bug. ***
added self to cc list.
*** Bug 21693 has been marked as a duplicate of this bug. ***
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 17653 has been marked as a duplicate of this bug. ***
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Regretfully REOPENing: this problem is back with the 2000-02-17-08-M14 nightly binary on Windows NT 4.0 - possibly a few days earlier. The File menu gets highlighted as soon as the window ALT-TABbed to appears in front of the Mozilla Window. This *was* fixed. Bug 24335, "Keypresses continue to get to menu after focus moved away", filed for the "Simplest way to reproduce:" set of steps above, has not come back - instead, a click in an edit field when a menu is active does not give focus to the edit field at all... this must have been reported by now.
Yeah, Hyatt went off and broke this. Assigning to him so he can see and use your great test cases.
Assignee: saari → hyatt
Status: REOPENED → NEW
Target Milestone: M13 → M14
dup. other is pdt+, so easier to dup in tha tdirection *** This bug has been marked as a duplicate of 18598 ***
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.