22221 - Menu doesn't relinquish focus

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P2)

Description

[Stephen Anderson]

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.

Comment 1

[Peter Trudelle]

reassigning to saari as p2 for m13. cc'ing joki in case he really wants to fix
it.

Comment 2

[saari (gone)]

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?

Comment 3

[saari (gone)]

Fixed

Comment 4

[Stephen Anderson]

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.

Comment 5

[leger]

Clearing FIXED resolution due to reopen.

Comment 6

[saari (gone)]

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!

Comment 7

[Jan Carpenter]

verified

Comment 8

[[github robot]]

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.