550338 - Broken focus when returning to editable documents from menus

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100304 Minefield/3.7a3pre
Build Identifier: 

When an editable document (e.g. designMode) has focus and you open and then close a menu, the accessible focus is often not returned to the document, even though keyboard focus does return to the document. Whether this works depends on the type of menu opened and whether a menu item was selected.

Reproducible: Always

Steps to Reproduce:
Menu bar:
1. Open the attached test case in Firefox.
2. Move focus to the editable document.
3. Press alt to activate the menu bar. The File menu item receives focus.
4. Press alt to close the menus.
  Actual: No accessible focus event is fired. The File menu item keeps the focused state. The editable document does not receive the focused state.
  Expected: An accessible focus event should be fired on the editable document and it should receive the focused state. The File menu item should lose the focused state.

Context menu:
5. Press shift+tab and then tab to restore focus to the editable document.
6. Press the applications key to open the context menu.
7. Press down arrow to move focus to the first item.
8. Press alt to leave the context menu.
  Result (correct): An accessible focus event is fired on the editable document and it receives the focused state.
Shift+tab weirdness:
9. Press shift+tab.
  Actual: Nothing happens.
  Expected: The focus should move to the previous item.
  Observation: When focus is correctly restored to the editable document, shift+tab must be pressed twice to move the focus.

Context menu and menu bar:
10. Press shift+tab and then tab to restore focus to the editable document in its initial state.
11. Press the applications key to open the context menu.
12. Press alt to leave the context menu.
13. Press alt to activate the menu bar. The File menu item receives focus.
14. Press alt to close the menus.
  Result (correct): An accessible focus event is fired on the editable document and it receives the focused state. The File menu item loses the focused state.
  Observation: Opening and then closing the context menu first seems to get focus working when returning from the menu bar as well.
Shift+tab weirdness:
15. Repeat steps 13 and 14 and confirm that the result is the same.
16. Press shift+tab. Nothing happens (as in step 9).
17. Again repeat steps 13 and 14.
  Actual: (as in step 4) No accessible focus event is fired. The File menu item keeps the focused state. The editable document does not receive the focused state.
  Expected: An accessible focus event should be fired on the editable document and it should receive the focused state. The File menu item should lose the focused state.
  Observation: Although opening and closing the context menu (steps 11-12) makes focus work when returning from the menu bar (step 15), pressing shift+tab (step 16), although having no apparent affect, again causes focus to break when returning from the menu bar (step 17).



This also happens in the message composition window of Thunderbird 3.1pre (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100303 Lanikai/3.1b2pre). This suggests that the issue is present in both Gecko 1.9.2 and 1.9.3. This used to work fine in Thunderbird 3.0.

Could this have broken around the same time that bug 512059 was introduced? That bug has since been fixed, but this might help in identifying the regression window.

Note that this is particularly annoying in Thunderbird 3.1.

Comment 1

[James Teh [:Jamie]]

Attachment: Test case.

Comment 2

[James Teh [:Jamie]]

Err... the "and whether a menu item is selected" from the top of the description is no longer valid. Sorry, forgot to remove from description before i submitted.

Comment 3

[Marco Zehe (:MarcoZ)]

I can confirm this bug.

Comment 4

[alexander :surkov (:asurkov)]

David, could you look into this and if the real focus is broken then cc right people?

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

A hunch: bug 457800 ?

Comment 6

[Marco Zehe (:MarcoZ)]

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e915fafc9ba5&tochange=fbea0edb9622
There are two interesting changes here having to do with focus: One is bug 512561, the other is bug 507592.

Comment 7

[alexander :surkov (:asurkov)]

If we choose between bug 512561 and bug 507592 then it mast be the last one because bug 512561 is not related with focus handling/firing. Cc'ing Enn and Olli.

Probably this is correct behavior from UI point of view since menus aren't focusable and actually focus is not changed. But it would be nice to know when it was changed.

Comment 8

[Neil Deakin]

Focus behaviour looks correct for steps 1-4. The focus doesn't change when a menu on the menubar is opened. Are you not receiving a DOMMenuBarInactive event?

The second set of steps (5-9) look like an unrelated bug, which has to do with confusion over what should be focused in editable documents. Bug 544277 is an example of a bug related to this.

Comment 9

[alexander :surkov (:asurkov)]

(In reply to comment #8)
> Focus behaviour looks correct for steps 1-4. The focus doesn't change when a
> menu on the menubar is opened. Are you not receiving a DOMMenuBarInactive
> event?

Yes, we do. The focused element is HTML body which is not accessible and therefore we don't fire focus event for it. I think we can fix this on our side.

Comment 10

[James Teh [:Jamie]]

This actually does occur for non-editable documents as well. I just didn't notice it because normally, a child in the document has focus. However, you can repro it as follows:
1. Open about:blank and focus on the document.
2. Press alt to activate the menu bar.
3. Press alt to close the menu bar.
Result: No focus event or focused state on document.

Comment 11

[James Teh [:Jamie]]

Any chance of having this fixed before Thunderbird 3.1 gets released? This is *really* annoying in Thunderbird.

Comment 12

[alexander :surkov (:asurkov)]

I filed bug 684818 for shift+tab issue

Comment 13

[James Teh [:Jamie]]

I verified that this is fixed in the last try build for bug 673958.

Comment 14

[alexander :surkov (:asurkov)]

fixed by bug 673958

Comment 15

[Marco Zehe (:MarcoZ)]

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1