From:  Trevor Saunders <trev.saunders@gmail.com>
Date:  26 Mar 2014 05:33:06 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.accessibility
Subject:  

IPC plans

NNTP-Posting-Host:  63.245.216.66

Hi,

 This mail is going to attempt to describe how accessibility will work
 in e10ns Gecko. follow ups to dev-accessibility is probably best.

tldr:
- the operating system level accessibility API will only talk to the
  main process
- accessibility information will be computed in the same process as the
  content it is for.
- Where it is advantagious we will cache information in the parent
  process instead of blocking on IPC.

details:
The main process will have a tree caching data for each sub tree in a
content process.  The tree of documents in in each of these subtrees
will be updated with PContent::PDocAccessibleConstructor() and
PDocAccessible::__delete__(), and the tree of accessibles in each
document will be kept up to date with show and hide events.  This means
caching the arrangement of accessibles in the tree is easy, and probably
makes things simpler in addition to faster.  At least in theory we can
cache everything that always fires an event when it changes, but I
expect at first we'll only cache the tree and then add more caching
based on performance data.

I plan on having a set of ipdl actors per document and then using
integer ids to refer to accessibles within that document, we can
repurpose the mAccessiblecache which maps pointers to accessibles to
themselves to map ids to accessibles in a manor that is safe.  This
saves the over head we'd have if we had an actor per accessible which
would result in thousands of actors for sessions with many tabs.

unresolved issues:
- xpcom API should it be one tree or tree per process? afaik AccessFoo
  assumes tree per process and our test suite assumes one tree for
everything, so we need to reconsile this somehow, but I'm not sure it
needs to happen immediately.

- we need to use the ipc infrastructure in the platform layer to handle
  accessible objects for content in child processes I'm not exactly sure
how this should look some ideas would include sub classing accessible /
making it more generic and having a proxy and local implementation, or
maybe it would be better for platform API methods to explicitly handle
remote accessibles with something like if accWrap accWrap->FOobar() else
remoteDoc->Foobar(accWrapId) but I figure we can figure this out once we
have the plumbing either case will need to call sorted out.

question / comments / whatever welcome!

Trev