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

Re: IPC plans

NNTP-Posting-Host:  63.245.216.66

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?


>
> 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
> >>
> >> _______________________________________________
> >> accessibility mailing list
> >> accessibility@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/accessibility
> >>
> >>
> > _______________________________________________
> > accessibility mailing list
> > accessibility@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/accessibility
> >
>
> _______________________________________________
> accessibility mailing list
> accessibility@lists.mozilla.org
> https://lists.mozilla.org/listinfo/accessibility
>