Last Comment Bug 550338 - Broken focus when returning to editable documents from menus
: Broken focus when returning to editable documents from menus
Status: VERIFIED FIXED
: access, regression
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: unspecified
: x86 Windows 7
: -- normal (vote)
: mozilla10
Assigned To: alexander :surkov
:
Mentors:
Depends on: 673958
Blocks: focuseventa11y a11ynext
  Show dependency treegraph
 
Reported: 2010-03-04 15:30 PST by James Teh [:Jamie]
Modified: 2011-09-29 08:07 PDT (History)
6 users (show)
surkov.alexander: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test case. (377 bytes, text/html)
2010-03-04 15:32 PST, James Teh [:Jamie]
no flags Details

Description James Teh [:Jamie] 2010-03-04 15:30:40 PST
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] 2010-03-04 15:32:21 PST
Created attachment 430442 [details]
Test case.
Comment 2 James Teh [:Jamie] 2010-03-04 15:34:38 PST
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) 2010-03-04 23:38:14 PST
I can confirm this bug.
Comment 4 alexander :surkov 2010-03-05 00:58:23 PST
David, could you look into this and if the real focus is broken then cc right people?
Comment 5 David Bolter [:davidb] 2010-03-05 06:48:09 PST
A hunch: bug 457800 ?
Comment 6 Marco Zehe (:MarcoZ) 2010-03-05 07:20:43 PST
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 2010-03-11 05:49:51 PST
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 2010-03-11 13:54:21 PST
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 2010-03-11 23:52:23 PST
(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] 2010-03-12 01:18:13 PST
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] 2010-05-31 22:53:39 PDT
Any chance of having this fixed before Thunderbird 3.1 gets released? This is *really* annoying in Thunderbird.
Comment 12 alexander :surkov 2011-09-06 04:09:55 PDT
I filed bug 684818 for shift+tab issue
Comment 13 James Teh [:Jamie] 2011-09-26 18:59:40 PDT
I verified that this is fixed in the last try build for bug 673958.
Comment 14 alexander :surkov 2011-09-28 02:22:56 PDT
fixed by bug 673958
Comment 15 Marco Zehe (:MarcoZ) 2011-09-29 08:07:20 PDT
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1

Note You need to log in before you can comment on or make changes to this bug.