1739920 - No a11y focus events after starting Firefox until you switch away from and back to Firefox

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P1)

Description

[James Teh [:Jamie]]

This was reported to us by the JAWS screen reader and ZoomText magnifier vendor (Vispero). It causes problems for both products.

Steps to repro with AccEvent:

1. Run AccEvent in MSAA mode (in or out of process).
2. Subscribe to OBJ_FOCUS event only.
3. Run Firefox.
4. Press Tab a few times, check if Firefox fires focus events.
5. Close Firefox.
6. Repeat steps 3-5 if the issue is not reproducible.

Results:

1. After the problem happens for the first time, it’s reproducible all the time during windows session.
2. The only focus event reported by Firefox is:
   OBJ_FOCUS        HWND=00000000000502E0 idObject=FFFFFFFFFFFFFFFC idChild=0 Window Class="MozillaWindowClass" [Error: getting object: hr=0xFFFFFFFF80004005 - Unspecified error]
3. Switching to another app and then back, fixes the problem and Firefox reports normal focus events:
   OBJ_FOCUS        HWND=00000000000502E0 idObject=FFFFFFFFFFFFFFFC idChild=0 Window Class="MozillaWindowClass" Name="Mozilla Firefox" Role=application State=read only,busy,sizeable,moveable,focusable
OBJ_FOCUS        HWND=00000000000502E0 idObject=FFFFFFFFFFFFFFFC idChild=FFFFFFFFFE7FFFBE Window Class="MozillaWindowClass" Name="Open context menu for mail.google" Role=menu button State=focused,floating,focusable,has popup
4. The problem is also gone if a dialog or file menu is opened with mouse or hot key.
5. The problem is also gone if a tool tip is shown and Jaws or ZoomText running.
6. The problem is not reproducible with AccEvent if there are some additional event subscriptions like OBJ_LOCATIONCHANGE.
7. There are no issues with AccEvent working in UIA mode.
8. There are no Firefox.exe instances after Firefox is closed.

here's what's happening here:

1. When the skeleton UI appears, Windows fires EVENT_OBJECT_FOCUS for the HWND as it always does when an HWND gets focus.
2. A client processing EVENT_OBJECT_FOCUS will send WM_GETOBJECT.
3. We return E_FAIL to stop clients from getting (and potentially caching) a generic oleacc client proxy which won't provide any useful info.
4. Since the skeleton UI HWND continues to be used once the real UI loads, no other focus event is fired by Windows.
5. Since WM_GETOBJECT is never received by the real UI, the Gecko a11y engine is never initialised.
6. Since the Gecko a11y engine is never initialised, we never fire most a11y events.
7. Since most a11y events are never fired, some clients never call WM_GETOBJECT, so this nasty situation continues until the user switches away from and back to Firefox, at which point Windows will finally fire another focus event.

This doesn't seem to affect NVDA. My guess is that this is either timing or perhaps NVDA responds to some other event (e.g. caret) that Firefox does still fire. However, we should not be relying on this; JAWS and ZoomText are not at fault here.

The intuitive solution is to avoid returning E_FAIL in the Skeleton UI. While this would mean clients do get an IAccessible for the initial focus, it would be useless to them (it might even cause a useless IAccessible to be cached by the client) and it still wouldn't initialise the Gecko a11y engine.

I think we can solve this by firing EVENT_OBJECT_FOCUS with the Firefox hwnd, OBJID_CLIENT and CHILDID_SELF once the real UI appears. Clients should pick this up and send WM_GETOBJECT, triggering the Gecko a11y engine as normal. Because the initial focus event returned E_FAIL, clients shouldn't ignore this as a duplicate. The main challenge will be figuring out where this code needs to go.

Comment 1

[James Teh [:Jamie]]

[Tracking Requested - why for this release]: Users of JAWS and ZoomText, two popular accessibility products, sometimes won't be able to access Firefox until they alt+tab away from and back to Firefox. While alt+tabbing is a simple workaround, this is far from ideal and some users may not understand they need to do this, rendering Firefox unusable to them.

Comment 2

[James Teh [:Jamie]]

Attachment: Bug 1739920: Fire a focus win event when the real UI replaces the skeleton UI.

Comment 3

[James Teh [:Jamie]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=107646f6522f9d988f475a2ce1a109d4470da363

Comment 4

[James Teh [:Jamie]]

Vispero tested a try build and confirmed the fix works for them.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/50fe91fffe4c
Fire a focus win event when the real UI replaces the skeleton UI. r=mhowell,dthayer

Comment 6

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/50fe91fffe4c

Comment 7

[Pascal Chevrel:pascalc (PTO until April 26)]

James, should this be uplifted to 95 beta or should it ride the 96 train?

Comment 8

[James Teh [:Jamie]]

I think it should be uplifted. I'm waiting for confirmation from the vendor who reported it to ensure it is fixed for them. That said, they already confirmed the fix in a try build and I verified the fix with testing tools in nightly myself, so if you'd prefer not to wait, I can submit the uplift request sooner.

Comment 9

[Pascal Chevrel:pascalc (PTO until April 26)]

We can wait for the vendor to confirm, thanks.

Comment 10

[James Teh [:Jamie]]

The vendor says:

There are no issues with Firefox 96.0a1 (2021-11-10) build.

Comment 11

[James Teh [:Jamie]]

Comment on attachment 9249668 [details]
Bug 1739920: Fire a focus win event when the real UI replaces the skeleton UI.

Beta/Release Uplift Approval Request

• User impact if declined: Users of the JAWS screen reader and ZoomText magnifier will sometimes not be able to access Firefox until they switch apps.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simply fires an additional a11y focus event for our main window.
• String changes made/needed: None.

Comment 12

[Dianna Smith [:diannaS]]

Comment on attachment 9249668 [details]
Bug 1739920: Fire a focus win event when the real UI replaces the skeleton UI.

Approved for 95.0b6

Comment 13

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/e84246ae81d5

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Did you want to nominate this for ESR91 approval also?

Comment 15

[James Teh [:Jamie]]

Comment on attachment 9249668 [details]
Bug 1739920: Fire a focus win event when the real UI replaces the skeleton UI.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Impacts users of the JAWS screen reader, which is often used in enterprise.
• User impact if declined: Users of the JAWS screen reader and ZoomText magnifier will sometimes not be able to access Firefox until they switch apps.
• Fix Landed on Version: 96, uplifted to 95
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simply fires an additional a11y focus event for our main window.
• String or UUID changes made by this patch: None.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9249668 [details]
Bug 1739920: Fire a focus win event when the real UI replaces the skeleton UI.

Approved for 91.4esr.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/d88fffc5376d

Comment 18

[Daniel Bodea [:danibodea]]

Can not be verified on QA Softvision side since we don't have a JAWS account (paid subscription).