Brendan Eich [:brendan] Reporter
	Description • 25 years ago

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

	David Hyatt Assignee
	Comment 1 • 25 years ago

*** Bug 15983 has been marked as a duplicate of this bug. ***

	Peter Trudelle
	Comment 2 • 25 years ago

reassigning to saari.

	saari (gone)
	Comment 3 • 25 years ago

Targeting M12

	Peter Trudelle
	Comment 4 • 25 years ago

Mass-moving non-PDT+ bugs to M13

	Sean Richardson
	Comment 5 • 25 years ago

*** Bug 17749 has been marked as a duplicate of this bug. ***

	Sean Richardson
	Comment 6 • 25 years ago

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.

	Sean Richardson
	Comment 7 • 25 years ago

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.

	Sean Richardson
	Comment 8 • 25 years ago

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"

	saari (gone)
	Comment 9 • 25 years ago

*** Bug 17167 has been marked as a duplicate of this bug. ***

	sairuh (rarely reading bugmail)
	Comment 10 • 25 years ago

added self to cc list.

	saari (gone)
	Comment 11 • 25 years ago

*** Bug 21693 has been marked as a duplicate of this bug. ***

	saari (gone)
	Comment 12 • 25 years ago

Fixed

	Claudius Gayle
	Comment 13 • 25 years ago

*** Bug 17653 has been marked as a duplicate of this bug. ***

	Sean Richardson
	Comment 14 • 25 years ago

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.

	saari (gone)
	Comment 15 • 25 years ago

Yeah, Hyatt went off and broke this. Assigning to him so he can see and use your 
great test cases.

	David Hyatt Assignee
	Comment 16 • 25 years ago

dup. other is pdt+, so easier to dup in tha tdirection


*** This bug has been marked as a duplicate of 18598 ***

	Sebastian Späth
	Comment 17 • 25 years ago

VERIFY duplicate