Electrolysis/Accessibility/Windows

Overview

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."

Preliminary Design

Introduction

We start by observing that the non-e10s implementation starts with a WM_GETOBJECT message being received by a Firefox window. The message's reply is an 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 RPC. 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.

Proxy Creation

Unlike the chrome case, COM proxies for content processes must be explicitly created.

[1] Russinovich, Mark et al. Windows Internals 6ed, Part 1. Microsoft Press, 2012