From:  Alexander Surkov <surkov.alexander@gmail.com>
Date:  26 Mar 2014 22:12:53 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.accessibility
Subject:  

Re: IPC plans

NNTP-Posting-Host:  63.245.216.66

I'm not optimistic either but it would solve huge problems like duping
trees and keeping them synchronized, it would cost no extra memory and
wouldn't affect on performance.


On Wed, Mar 26, 2014 at 10:08 AM, David Bolter  wrote:

> 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
> >> (https://wiki.mozilla.org/Security/Sandbox)
> >>
> >
> > 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 :)
>
> Cheers,
> D
>
> >
> >
> >>
> >> 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 <
> >> trev.saunders@gmail.com>wrote:
> >>>
> >>>> 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
> >>>>
>
>