Electrolysis/Accessibility/Windows: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(moving this to the root accessibility page)
 
Line 1: Line 1:
= Overview =
[https://wiki.mozilla.org/Electrolysis/Accessibility#Windows Moved]
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.
 
The Windows kernel supports Asynchronous Local Procedure Calls (ALPC). ALPC is a scalable, high-performance IPC mechanism [1] that, while undocumented, is available to application software via Microsoft RPC (when using the "ncalrpc" transport). Since COM marshaling is built atop RPC, it is possible for properly configured COM proxies to take advantage of the performance that ALPC offers. Since MSAA is built atop COM, Gecko could configure its COM proxies to gain the benefits of ALPC "for free."
 
If a11y data must first be sent from chrome to content, it must be serialized by IPDL. It would then be serialized a second time, in a different format, by COM. Direct communication between the a11y client and content allows us to eliminate the IPDL serialization.
 
[1] Russinovich, Mark et al. Windows Internals 6ed, Part 1. Microsoft Press, 2012
 
== A11y Client Considerations ==
Given the fact that the content process is sandboxed and that e10s is a sea-change in many respects, now is a good time to review the interactions between a11y clients and Gecko. We will not be allowing DLL injection into the content process, and would prefer that this be avoided in the case of the chrome process as well. Instead, we would prefer that a11y clients stick to the COM-based MSAA interface outside of the Firefox chrome process. One major motivation for making our interface proxies work over ALPC is that ALPC was designed to support IPC for user-mode drivers. If ALPC is up to the task of supporting device drivers, we believe it will be more than sufficient for a11y IPC.
 
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.
 
= Preliminary Design =
[[File:E10sA11yCOMProxyDiagram.svg|frameless|550px|A diagram of the proposed COM Proxy implementation for a11y on Windows e10s]]
 
(Dashed arrows represent COM atop RPC, using the ncalrpc transport.)
 
This diagram demonstrates the state of a11y IPC connections after a content proxy has been returned to the client.
 
== Introduction ==
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.
 
When the WM_GETOBJECT sender is out-of-process, this IAccessible is implicitly proxied by Microsoft COM. The a11y client is not directly invoking the object's methods. Instead, the methods are being invoked via COM marshaling. Marshaling and IPC occur automatically and transparently to the caller.
 
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.
 
== Content Proxies ==
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.
 
To move data from a background thread to the main thread, we propose using a simplified IPDL protocol:
* We should avoid IPDL deferred message protection for stability and performance reasons;
* This protocol shall not serialize complex types. Since it is merely doing an in-process hand-off of data between threads, it should just pass pointers whenever possible (note that due to COM restrictions, any parameters that are COM interfaces will be exceptions to this);
* This protocol shall match its corresponding COM interface as closely as possible.
 
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.
 
== Proxy Resolution ==
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.
 
== Reentrancy ==
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.

Latest revision as of 16:19, 1 June 2016

Moved

Retrieved from "https://wiki.mozilla.org/index.php?title=Electrolysis/Accessibility/Windows&oldid=1135323"