Re: IPC plans

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 f=
or
> 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.

> 2) I assume that you can have sync access to content process DOM tree fro=
m 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.

> 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.

Trev

>     Hi,
> =

>     =A0This mail is going to attempt to describe how accessibility will w=
ork
>     =A0in e10ns Gecko. follow ups to dev-accessibility is probably best.
> =

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

>     details:
>     The main process will have a tree caching data for each sub tree in a
>     content process. =A0The 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. =A0This m=
eans
>     caching the arrangement of accessibles in the tree is easy, and proba=
bly
>     makes things simpler in addition to faster. =A0At 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. =A0This
>     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
>     =A0 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 hand=
le
>     =A0 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() e=
lse
>     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
> =

> =

> =