Broken focus when returning to editable documents from menus

VERIFIED FIXED in mozilla10

Status

()

Core
Disability Access APIs
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: Jamie, Assigned: surkov)

Tracking

(Blocks: 2 bugs, {access, regression})

unspecified
mozilla10
x86
Windows 7
access, regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
Keywords: access
(Reporter)

Comment 1

7 years ago
Created attachment 430442 [details]
Test case.
(Reporter)

Updated

7 years ago
Keywords: regression
(Reporter)

Comment 2

7 years ago
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

7 years ago
I can confirm this bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 4

7 years ago
David, could you look into this and if the real focus is broken then cc right people?
Status: NEW → UNCONFIRMED
Ever confirmed: false
(Assignee)

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
A hunch: bug 457800 ?

Comment 6

7 years ago
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.
(Assignee)

Comment 7

7 years ago
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.
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.
(Assignee)

Comment 9

7 years ago
(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.
(Reporter)

Comment 10

7 years ago
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.
(Assignee)

Updated

7 years ago
Blocks: 375743
(Reporter)

Comment 11

7 years ago
Any chance of having this fixed before Thunderbird 3.1 gets released? This is *really* annoying in Thunderbird.
(Assignee)

Updated

6 years ago
Blocks: 632301
(Assignee)

Updated

6 years ago
Depends on: 673958
Flags: in-testsuite?
(Assignee)

Updated

6 years ago
Depends on: 684818
(Assignee)

Comment 12

6 years ago
I filed bug 684818 for shift+tab issue
No longer depends on: 684818
(Reporter)

Comment 13

6 years ago
I verified that this is fixed in the last try build for bug 673958.
(Assignee)

Comment 14

6 years ago
fixed by bug 673958
Assignee: nobody → surkov.alexander
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.