Confirm
1,085
edits
Changes
Trevor guesses roughly half complete.
Accessibility clients require direct access to information about content. In non-e10s this information is queried directly using sync calls into the DOM. These calls generally arrive on the application main or UI thread and expect a response on return. With e10s, the chrome process generally communicates with content through asynchronous interfaces. This is incompatible with current a11y clients. As such the Accessibility Team is currently working on a two phase approach to getting accessibility working under e10s:
* Initial support with sync chrome -> content calls for most common apis, with light weight caching to cut down on the heaviest api traffic. (Mostly Partly complete.)
* A black list of clients known to have issues with e10s will be added for roll out to Aurora and beyond. When a blacklisted client is detected Firefox will prompt the user to disable e10s and restart. This work is covered by meta bug 1159326.
* Gradual improvement using chrome side caching of DOM state, working toward a mostly asynchronous interface.
