From:  David Bolter <>
Date:  26 Mar 2014 22:08:01 Hong Kong Time

Re: IPC plans


On 2014-03-26, 10:04 AM, Alexander Surkov wrote:
> Hi, David.
> On Wed, Mar 26, 2014 at 9:17 AM, David Bolter  wrote:
>> Hi Alex,
>> Unfortunately when the processes are properly sandboxed I don't think it
>> is an option to have AT communication with each process
>> (
> Iiirc we wanted to get an expert opinion about whether some exception can
> be done for AT. Has been this idea rejected?

Right, the question came up at the SF meetup. Trevor was there any
further thinking since then? I'm skeptical :)


>> Trevor, we also need to figure out how to land this work. Do we want to
>> land pieces incrementally (on central) that don't really do anything
>> useful in the meantime, or work on a branch or...?
>> Cheers,
>> D
>> On 2014-03-26, 9:04 AM, Alexander Surkov wrote:
>>> Hi.
>>> 1) If you plan to make AT to talk to the main process only then it means
>>> the AT should see a whole MSAA tree as unique tree, the same trick can be
>>> done for XPCOM. I.e. the way XPCOM tree is implemented shouldn't be
>>> different from MSAA tree implementation.
>>> 2) I assume that you can have sync access to content process DOM tree
>> from
>>> the main process, so if the main process doesn't dupe DOM trees of
>> content
>>> processes then it's good to explain why accessibility tree is different.
>>> 3) Didn't you consider a scenario when AT communicates with each process?
>>> Thanks.
>>> Alexander.
>>> On Tue, Mar 25, 2014 at 5:33 PM, Trevor Saunders <
>>>> 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