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.
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.
*** Bug 20093 has been marked as a duplicate of this bug. ***
Summary: Type ALT+F, L,N,O, to get "lno" appended in Location bar → Typing in menu after editbox sends keypress to both
Whiteboard: [Steps are TESTCASE]
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
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 ***
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.