Fission a11y: When an OOP iframe gets focus, a11y focus gets fired on iframe itself
Categories
(Core :: Disability Access APIs, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | verified |
People
(Reporter: Jamie, Assigned: Jamie)
References
Details
Attachments
(1 file)
Intermittent STR (with Fission enabled and the NVDA screen reader):
- Open this:
data:text/html,<body role="application"><button>foo</button><iframe src="https://google.com/notfound"></iframe><button>bar - Tab twice.
- Expected: NVDA should start speaking the Google 404 document.
- Actual: NVDA says just "frame".
This doesn't always happen, but it happens most of the time on my system. It's a race condition, so results may vary.
This occurs because when you tab into the iframe, the top level remote browser fires focus on the OuterDocAccessible, since from its perspective, there's nothing inside it to focus. The OOP iframe browser fires focus on the embedded document. Since we're racing between three processes, these two events can arrive in either order. If the iframe focus arrives last, the a11y client will see that as the correct focus instead of the Accessible inside the iframe.
This can also happen when shift+tabbing to the Google link inside the iframe. It is not specific to the embedded DocAccessible.
I think the solution is to disallow a11y focus events on OuterDocAccessibles. I don't think there's ever a reason for an OuterDoc to get focus without something inside it being focused.
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 1•5 years ago
|
||
|
|
Assignee | |
Comment 2•5 years ago
|
||
An OuterDoc shouldn't get accessibility focus itself.
Focus should always go to something inside it.
However, OOP iframes will get DOM focus because their content isn't in this process.
We now suppress the OuterDoc focus in this case.
The OOP browser will fire focus for the correct Accessible inside the embedded document.
Without suppression of the OuterDoc focus, the two focus events will race and the OuterDoc focus may override the correct embedded focus for accessibility clients.
Even if they fired in the correct order, clients may report extraneous focus information to the user before reporting the correct focus.
|
||
Comment 4•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
|
||
Comment 5•5 years ago
|
||
Reproduced the issue with Firefox 72.0a1 (20191106215426) on Windows 10x64.
The issue is verified fixed with Firefox 72.0a1 (20191109093718) and Firefox 76.0a1 (20200329214909) on Windows 10x64. Tested multiple times and "frame" is no longer said by NVDA.
Description
•