Electrolysis/Accessibility: Difference between revisions

= Windows =

The main problem with accessibility on e10s is the need for a11y clients to access and manipulate information about web content -- information that will reside inside one or more sandboxed child processes.

Having said that, we are aware that many clients are injecting code into Firefox to process a11y events as quickly as possible; obviously ALPC will still be slower than a virtual function call to some degree. We would like to hear more from vendors about their use cases that require this injection. Perhaps we can develop additional COM interfaces to help satisfy the clients' needs and mitigate the necessity for DLL injection.

[[File:E10sA11yCOMProxyDiagram.svg|frameless|550px|A diagram of the proposed COM Proxy implementation for a11y on Windows e10s]]

This diagram demonstrates the state of a11y IPC connections after a content proxy has been returned to the client.

We start by observing that the non-e10s implementation starts with a [https://msdn.microsoft.com/en-us/library/windows/desktop/dd373892(v=vs.85).aspx WM_GETOBJECT] message being received by a Firefox window. The message's reply is an [https://msdn.microsoft.com/en-us/library/windows/desktop/dd318466(v=vs.85).aspx IAccessible] pointer.

This mechanism will also work in the e10s case, but with the IAccessible interface being provided by content processes. Clever management of the proxy objects by the chrome process will make this entire scheme completely transparent to the a11y client: the client does not need to be aware of which process it is communicating with.

Unlike the chrome case, COM proxies for content processes must be explicitly created. Microsoft COM provides APIs to create proxies and (de)serialize them, however this must be done with care. In order to take advantage of ALPC, the proxy for a content IAccessible must be created on a thread that has been initialized to run inside the multi-threaded apartment (MTA). Since our main thread runs in the single-threaded apartment (STA), any interaction with the "stub" (which is the server side of the proxy) must also occur on a MTA thread. Instead of calling straight into a11y APIs on the main thread, proxied calls will arrive on a background thread that is initialized for the MTA.

Inside Gecko, a serialized COM proxy will be encapsulated within a ProxyStream object. The ProxyStream class will be a first-class type in IPDL. The PBrowser protocol will be augmented with APIs to asynchronously transmit ProxyStream objects between chrome and content. This will allow serialized COM proxies to be moved between chrome and content processes. Once inside the chrome process, ProxyStream will deserialize the proxy and return an interface pointer that may be used in replies to WM_GETOBJECT requests. Since handling WM_GETOBJECT is synchronous, we want the proxied interfaces to be present in the chrome process ahead of time.

So far we have identified the following cases where we will need to resolve proxy objects:

* When DOM traversal crosses the threshold between chrome and content in either direction;

* When WM_GETOBJECT specifies an object identifier that resolves to an object that resides in content. The chrome process will need to maintain a mapping from object ids to proxy interfaces.

We need to be careful with the possibility of reentry when firing a11y events via [https://msdn.microsoft.com/en-us/library/windows/desktop/dd373603(v=vs.85).aspx NotifyWinEvent]. Provided that all interfacing with a11y clients is out-of-process, this might not be as serious a concern as originally thought, since NotifyWinEvent will return asynchronously and any incoming calls over COM interfaces will be proxied to the background MTA thread. We may encounter scenarios that we haven't yet thought of, however.