1440083 - JAWS features broken if Firefox opens before JAWS boots up

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[jesse.greenberg]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce:

Happens frequently with the following steps:
- Launch Firefox
- Navigate to any webpage
- Enable JAWS

Also happens frequently with the following  steps:
- Launch JAWS
- Launch Firefox before JAWS finishes booting up
- Navigate to any webpage

Firefox version 52.6.0 (esr, since Firefox 57 and newer are not compatible with JAWS)
JAWS version 18.0.4104


Actual results:

Unable to read any HTML content with JAWS keystrokes. Alerts from aria-live regions are not read. The only elements that are read are those that receive focus from "Tab" navigation.


Expected results:

I would expect to be able to read content on an HTML page with JAWS keystrokes after launching JAWS and Firefox in the following order:

- Launch Firefox
- Navigate to any webpage
- Enable JAWS

Comment 1

[Marco Zehe (:MarcoZ)]

We know that this is a problem if you start JAWS after Firefox. The workaround is to run JAWS *before* Firefox and let it finish loading (when it starts speaking, it's done).

Note, too, that due to the E10S architecture, our window emulation code for JAWS that is the culprit here has been changed to acommodate the multi-process architecture and that JAWS 2018 (Version 19) is the only version supported going forward, and that a lot of circumstances will have changed once we have all the perf improvement and fixes for JAWS in place, currently slatted for JAWS 60. So this bug may be obsoleted by then.

Jamie, you hinted at some point that window emulation might not much longer be needed by JAWS anyway, is that something that's going to happen anytime soon?

Comment 2

[James Teh [:Jamie]]

(In reply to Marco Zehe (:MarcoZ) from comment #1)
> Jamie, you hinted at some point that window emulation might not much longer
> be needed by JAWS anyway, is that something that's going to happen anytime
> soon?

I discussed this briefly with VFO and there was some interest in updating JAWS to get rid of the need for window emulation. However, there's no ETA on this yet. It's not likely to happen before May given the more pressing performance concerns at present. I'll follow this up with VFO once Firefox and JAWS are playing well together again.

Comment 3

[jesse.greenberg]

Thank you so much for the swift reply and information.

Comment 5

[James Teh [:Jamie]]

I've tried a few times and I can try again, but i doubt we'll get very far with Vispero on this.

I don't really know if there's much we can do to fix this on our side. Firefox needs to make a decision about whether to enable the legacy window emulation (emulating old behaviour that was removed ~15 years ago) when the accessibility engine starts. That changes how accessibility events are fired, etc. To fix this, we'd need to:

1. Somehow detect when JAWS loads after the accessibility engine has already started.
2. Enable legacy window emulation, which will alter the window reported to accessibility objects and events. Aside from the implementation challenges, there's also a risk that this would break any existing accessibility clients that had already queried Firefox, since the window returned to them now would be different from the window they obtained before.

Comment 6

[James Teh [:Jamie]]

Somehow detect when JAWS loads after the accessibility engine has already started.

Implementation note: We can use DllServices::kTopicDllLoadedMainThread ("dll-loaded-main-thread") to get notified about when jhook.dll loads.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the following bug duplicate has higher severity:

• Bug 1840895: S2

:Jamie, could you consider increasing the severity of this bug to S2?

For more information, please visit BugBot documentation.

Comment 8

[James Teh [:Jamie]]

The severity should remain at s3, as this has a workaround and will not be experienced by most users who will run JAWS before Firefox. The duplicate bug has a higher severity because it was initially thought that it always impacted all JAWS users, rather than only impacting JAWS users who started JAWS after Firefox.