Sean Richardson Reporter
	Description • 25 years ago

Overview:
Tried a variation on replicating bug 9903 with a current build,
got typing on location bar after typing ALT+F to activate File
menu.

Steps to Reproduce:
1. Start Mozilla, wait for the home page to complete loading.
2. Type a URL in the location bar, but do not type [ENTER]
3. Type ALT+F, then O, then [ENTER].
4. Repeat steps 1 & 2.
5. Type ALT+F, then L, then N, then O.
6. Repeat steps 1 & 2.
7. Type ALT+F, then N.

Actual Results:
1. In step 3, the "o" will appear in the location bar before the
   "Open Web Location" dialog appears.
2. In step 5, "l", then "n", then "o" get appended to the location bar
   and no dialogs are shown or browser windows launched.
3. In step 7, "n" gets appended to the location bar and no
   browser window is launched.

Expected Results:
1. In step 3, the "Open Web Location" dialog appears, nothing else.
2. In step 5, the "Open File" dialog appears, and the "n" and "o" appear
   in the "File Name" textbox.
3. In step 7, a new browser window is launched, nothing else.
4. If the menu system does not recognize or cannot do anything
   with a keystroke, that key should be eaten, rather than allowed
   to get passed to the previous UI component with focus.

Tested with:
1999-11-12-18-M11 nightly binary on Windows NT 4.0sp3

Additional Information:
1. The "L", "N", and "O" keyboard accelerators on the File menu currently
work only if [ENTER] is added.
2. This may be related to
bug 17683, "[Dogfood] ALTGr + NUM Pad key operation shifts focus to menu"
or bug 17749, "Menu activated after ALT key pressed and let go before alpha"
- both of which apply to the editor and <textarea>s, and seem like the
inverse case of this bug.

	Sean Richardson Reporter
	Comment 1 • 25 years ago

Additional information:
1. This bug occurs if the text typed in step 2 is typed into *any* edit
   field in any Mozilla App.
2. The same problem occurs if the File menu is activated by a mouse click
   rather than "ALT+F", so this is more likely to be a focus problem related
   o the second bug in bug 15048 "alt-tabbing to apprunner creates spurious
   ALT events" than the first part.
3. To avoid an interaction with bug 15048, make sure that no menu has focus
   before step 2.
4. It may not be necessary to restart Mozilla in steps 4 and 6.

This bug still seems to exist.

Tested with: 1999-12-12-08-M12 nightly binary on Windows NT 4.0sp3.

	Sean Richardson Reporter
	Comment 2 • 25 years ago

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

	Sean Richardson Reporter
	Comment 3 • 25 years ago

Updating Summary from "Type ALT+F, L,N,O, to get "lno" appended in Location bar"
to "Typing in menu after editbox sends keypress to both" to reflect the
fact that this is not specific to the Location Bar.

Still exists with: 1999-12-23-08-M13 nightly binary on Windows NT 4.0sp3

Adding notation "[Steps are TESTCASE]" to Status Whiteboard - no file-based
testcase is possible.

	Sean Richardson Reporter
	Comment 4 • 25 years ago

Resolving this bug as a DUP of bug 22782 because that bug describes the
entire problem in one coherent description, and shows that the problem affects
more than just text inputs and textareas. It seems that keypresses continue to
get through to *any* part of the browser that had focus just before focus is
given to the menu system, as well as getting to the menu system.


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

	Jan Carpenter
	Comment 5 • 25 years ago

verified