Confirmed users
31
edits
Accessibility/CacheTheWorld: Difference between revisions
Jump to navigation
Jump to search
Rename "About" section to "What?". Add "Why?" section. Add Bugzilla sections for m2 and m3.
(Fix backlog query so it doesn't include resolved bugs.) |
(Rename "About" section to "What?". Add "Why?" section. Add Bugzilla sections for m2 and m3.) |
||
| Line 1: | Line 1: | ||
== | == What? == | ||
Firefox's current architecture for multi-process accessibility suffers from severe performance issues and is costly and difficult to maintain due to the massively different and specialised approaches necessary on different operating systems. In addition, it is currently impossible to support builtin Windows accessibility tools such as Narrator and Windows Speech Recognition. This project aims to re-architect our multi-process accessibility support to cache the entire accessibility trees for all content processes within the parent process. | Firefox's current architecture for multi-process accessibility suffers from severe performance issues and is costly and difficult to maintain due to the massively different and specialised approaches necessary on different operating systems. In addition, it is currently impossible to support builtin Windows accessibility tools such as Narrator and Windows Speech Recognition. This project aims to re-architect our multi-process accessibility support to cache the entire accessibility trees for all content processes within the parent process. | ||
== Why? == | |||
This will allow us to address several problems that are difficult or impossible to fix with the current architecture: | |||
# Performance, especially on Windows. While performance is acceptable for daily usage in most cases, there are many use cases which are far from delightful and some which are still completely unusable. Performance with the JAWS screen reader, which is used heavily in enterprise, is sluggish at best. A great deal of work has been done over the past few years to improve this, but we're approaching a point where we will not be able to improve this any further with the current architecture. Because software other than assistive technology uses accessibility APIs (e.g. Windows touch, East Asian input methods, enterprise SSO tools), this can impact even users without disabilities. The proposed new architecture will allow us to significantly improve performance across all operating systems. See [https://bugzilla.mozilla.org/show_bug.cgi?id=1737192 bug 1737192] for a list of performance bugs which we expect will be fixed (or at least improved) by Cache the World. | |||
# Stability. Because the current architecture makes heavy use of synchronous IPC, there is a high risk of deadlocks between accessibility and other Firefox components. While all known cases have been addressed as they have been discovered, the underlying cause remains and future instances of this problem are very likely. In addition, our use of obscure COM features on Windows has resulted in stability problems which are extremely difficult to diagnose and fix. One of these remains a problem today, despite months of investigation, and forces some NVDA screen reader users to forcibly kill Firefox (or worse, forcibly power off their computers) every few hours. The proposed new architecture will not suffer from these inherent stability risks and known problems. See [https://bugzilla.mozilla.org/show_bug.cgi?id=1737193 bug 1737193] for a list of stability/reliability bugs which we expect will be fixed (or at least improved) by Cache the World. | |||
# Complexity and cost. Our existing architecture is necessarily very different on each operating system, making it extremely complex and difficult to maintain. For example, the IPC layer on Windows (~8000 lines of code) has an entirely different architecture to other platforms. This also means that maintenance is very costly, especially when implementing support for new operating systems (e.g. Android, Mac) or major Gecko architectural initiatives (e.g. Fission). Furthermore, our use of esoteric operating system specific features, especially on Windows (where we depend on a whole separate ~11000 line module), makes it very difficult for this work to be distributed across the team because of the highly specific expertise required. In the proposed new architecture, most of the "heavy lifting" will be done in cross-platform code, decreasing complexity and maintenance cost. | |||
# Support for other builtin accessibility tools. It is impossible to support Windows Narrator and Windows Speech Recognition with our current architecture. The proposed new architecture will allow for this. As these builtin tools rise in popularity, we do not want Firefox to be left behind. | |||
== Meeting Notes == | == Meeting Notes == | ||
| Line 74: | Line 82: | ||
=== Milestone 2: June 2022 === | === Milestone 2: June 2022 === | ||
TBD. Opt-in user preview. Enable in Nightly? | TBD. Opt-in user preview. Enable in Nightly? | ||
==== Bugzilla ==== | |||
<bugzilla> | |||
{ | |||
"quicksearch": "ALL whiteboard:[ctw-m2]", | |||
"include_fields": "id, summary, assigned_to, status" | |||
} | |||
</bugzilla> | |||
=== Milestone 3: September 2022 === | === Milestone 3: September 2022 === | ||
TBD. Beta experiment? Release experiment? | TBD. Beta experiment? Release experiment? | ||
==== Bugzilla ==== | |||
<bugzilla> | |||
{ | |||
"quicksearch": "ALL whiteboard:[ctw-m2]", | |||
"include_fields": "id, summary, assigned_to, status" | |||
} | |||
</bugzilla> | |||
== Backlog == | == Backlog == | ||