There seems to be several focus problems related to the menu bar. What I am about to describe I have most recently observed on buid 1999121915 on Win95. Observed behavior: If you hit "Alt" focus is shifted up to the menu bar. Then if you click in the URL address bar the address bar gains focus but the menu bar keeps focus as well. Or, if you clicked on the body of the html document the document will gain focus but the menu will keep it as well. Expected behaviour: Once the menu has focus, it should relinquish focus once another object (url bar or document) gains focus. Additional: This behaviour seems limited to giving the menu focus with the ALT key. If it gains focus through the mouse, it relinquishes focus. Secondary focus problems: These focus problems may have to do with this bug, or it may be duplicating bug# 18598 - I'm not sure. Anyway, it appears when the menu bar get's focus (through ALT or mouse) it does not stop keystrokes from going to the previosuly focused element. For instance, typing in the url, followed by focusing the menu, additional keystrokes will show up in the addr bar. If focus was in the main body, and then shifted to the menu, navigation of the menu with the up and down arrow keys will also scroll the document.
reassigning to saari as p2 for m13. cc'ing joki in case he really wants to fix it.
Menus never get "focus" per se. This is all interaction with the xpmenu listeners. Joki, I emailed you and vidur with some DOM changes I need (activate/deactivate) events to fix this stuff. Are those changes ok with you two?
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Severity: normal → major
Status: RESOLVED → REOPENED
Better, but not quite fixed. The following observations are all of build 2000011108 on Win95. While some of the orginal described problem has indeed been fixed, many scenarious still produce erroneous focus behavior associated with the ALT key. For all the below, start mozilla and come to this page (bug 22221) as it makes a nice test page. Case 1) Click on the URL bar. Type a few characthers (not really necessary). Hit the ALT key. Type the letter "j". The letter j appears on the URL bar instead of causing a no-action. Hit the letter "d". The letter d appears on the URL bar AND the debug menu activates. Both the menu bar and the URL bar are recieving the keystrokes. Case 2) While hitting the ALT key and then clicking somewhere usually results in the menu giving up focus, if the place clicked corresponds a text control (input or URL bar or whatever) AND if that same exact text control had the focus just before ALT was used to focus the menu, the menu will not relinquish focus. Subsequent keystrokes will be caught by both the menu and the text control as in case 1. Case 3) This is a little odd so follow closely. Start like all the other cases. Click and activate a text control (like the Whiteboard input). Type a little bit (probably optional). Hit ALT to bring focus to the menu. Type a letter that is a menu shortcut (like "v" for View). Now hit Escape to close the menu that should have dropped down. Now, clicking subsequent areas both fails to remove focus from the menu and fails to focus the clicked area. Focus has effectively been frozen on the menu and the formerly activated text control. NOTE: A second Escape seems to cause the menu to relinquish focus normally, but no amount of clicking (outside of the menu bar itself) seems to work. Case 4) I guess this really belongs in its own bug, but I believe it is a symptom of the changes made in response to this bug. If you select a text area, then ALT-Tab to task switch to another application, then Alt-Tab back, then finally select a different text area: you get a blinking text cursor in the newly selected text control plus the old blinking cursor remains in the previously selected text control, although it does not appear to recieve keystrokes. Finally, Case 5) This is a combination of case 3 & 4. The kicker is that it results in an incapacitation of the program. Click on a text control. Type a few characthers. Hit ALT. Type a menu letter (like "v"). Hit Escape to close the drop-down menu. Alt-Tab to another program. Alt-Tab back. Now no amount of clicking will grant focus anywhere. Keystrokes are ignored, mouse clicks are ignored. Most of the time I have to use ^C in the console window to recover. Case 5 Update) As I wrote this, I found that there is a way besides ^C to recover. If you click the program exit button (the big X) while it will not respond, it clears whatever constipation crept into the system and all subsequent keystrokes / mouse activity returns to normal. I was going to upgrade the priority to critical since I thought it was a lockup but now since you can recover (allbeit rather hard to guess way) I will upgrade it only to major. Most people probably wont come across the lockup but most that do wont find the way out either. Incidentally, if you're wondering how in the world I found all those different behaviours, it's from testing a little in mozilla then alt-tabbing to IE to type up the results. I don't usually just try insane combinations. <grin> Hope this helps.
Clearing FIXED resolution due to reopen.
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
Ok, I just checked in fixes for all of these issues, except for case 4, which is a duplicate of bug 12051. Keyboard navigation of menus is still broken in general, but hyatt and myself will hopefully get a bunch of fixes into M13 to address keybindings in general. Thanks for the excellent test cases! You caught quite a few nasty bugs!
Status: RESOLVED → VERIFIED
Commit pushed to master at https://github.com/mozilla/dxr https://github.com/mozilla/dxr/commit/5f57eda037138f168de20144e60dde442090e216 Added a wrapper around ast.parse to strip the encoding declaration comment. Due to Python issue #22221, compiling a unicode string that contains an encoding declaration comment raises a SyntaxError. Here we strip it out if there is a match in the first two lines of the file (since such declarations are only active in the top two lines) and replace with an empty line. The resultant modified file content lines are then passed to ast.parse after being rejoined. These modifications are not disruptive since there will be no further column offsets after the newline, and the encoding declaration line must contain nothing other than whitespace and the comment.
You need to log in before you can comment on or make changes to this bug.