Re: IPC plans

On Wed, Mar 26, 2014 at 2:49 PM, Trevor Saunders <[email protected]>wrote:

> On Wed, Mar 26, 2014 at 09:04:36AM -0400, 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.
>
> I agree the xpcom tree *can* all be in one process, but I'm not sure I
> agree its either desirable or easier than the alternative.
>

AccessFu is not quite different from platform screen readers by its nature.
I'm pretty sure they will need a mechanism to cross the boundaries between
processes. So either it'll be one tree or multiple trees with
cross-platform bridges.


>
> > 2) I assume that you can have sync access to content process DOM tree
> from the
>
> you can't unless we add it, and we'd need to add sync access to the
> frame tree too...
>

> > 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.
>
> there's just no reason to have general access to the dom in the child
> process from the parent.
>

I'm curious though how content plugins are implemented. Their head should
be in chrome process but they operate on content.


>
> > 3) Didn't you consider a scenario when AT communicates with each process?
>
> not really, it would be hard to sand box, and it would require a bunch
> of tricky platform specific code for each platform, and its not even
> clear to me its possible on mac.
>

The stake is to win in memory and in performance. Even if it requires
platfrom specific code then it's worth to consider the option (it seems Hub
agrees on it).


>
> Trev
>
> >     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
> >     [email protected]
> >     https://lists.mozilla.org/listinfo/accessibility
> >
> >
> >
>