Re: IPC plans

On Wed, Mar 26, 2014 at 03:13:58PM -0400, Alexander Surkov wrote:
> =

> =

> =

> 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 differen=
t 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 natur=
e. 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-platf=
orm
> bridges.

aiui they already deal with multiple processes because they work on b2g
and they deal with it with content scripts and stuff in JS.  So since
AcessFoo seems to already work in a multiprocess world I just assume
leave it as is unless we have a reason to change it.

>     > 2) I assume that you can have sync access to content process DOM tr=
ee
>     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 cont=
ent
>     > processes then it's good to explain why accessibility tree is diffe=
rent.
> =

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

I'm not sure what you mean "content plugins"

>     > 3) Didn't you consider a scenario when AT communicates with each pr=
ocess?
> =

>     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 pla=
tfrom

it looses on security and it would be a lot of pretty evil platform
specific code assuming it even works on mac and I'm pretty sure the
android stuff would need its own special IPC stuff anyway.

> specific code then it's worth to consider the option (it seems Hub agrees=
 on
> it).

I haven't seen him say anything...

Trev

> =A0
> =

> =

>     Trev
> =

>     > =A0 =A0 Hi,
>     >
>     > =A0 =A0 =A0This mail is going to attempt to describe how accessibil=
ity will
>     work
>     > =A0 =A0 =A0in e10ns Gecko. follow ups to dev-accessibility is proba=
bly best.
>     >
>     > =A0 =A0 tldr:
>     > =A0 =A0 - the operating system level accessibility API will only ta=
lk to the
>     > =A0 =A0 =A0 main process
>     > =A0 =A0 - accessibility information will be computed in the same pr=
ocess as
>     the
>     > =A0 =A0 =A0 content it is for.
>     > =A0 =A0 - Where it is advantagious we will cache information in the=
 parent
>     > =A0 =A0 =A0 process instead of blocking on IPC.
>     >
>     > =A0 =A0 details:
>     > =A0 =A0 The main process will have a tree caching data for each sub=
 tree in a
>     > =A0 =A0 content process. =A0The tree of documents in in each of the=
se subtrees
>     > =A0 =A0 will be updated with PContent::PDocAccessibleConstructor() =
and
>     > =A0 =A0 PDocAccessible::__delete__(), and the tree of accessibles i=
n each
>     > =A0 =A0 document will be kept up to date with show and hide events.=
 =A0This
>     means
>     > =A0 =A0 caching the arrangement of accessibles in the tree is easy,=
 and
>     probably
>     > =A0 =A0 makes things simpler in addition to faster. =A0At least in =
theory we
>     can
>     > =A0 =A0 cache everything that always fires an event when it changes=
, but I
>     > =A0 =A0 expect at first we'll only cache the tree and then add more=
 caching
>     > =A0 =A0 based on performance data.
>     >
>     > =A0 =A0 I plan on having a set of ipdl actors per document and then=
 using
>     > =A0 =A0 integer ids to refer to accessibles within that document, w=
e can
>     > =A0 =A0 repurpose the mAccessiblecache which maps pointers to acces=
sibles to
>     > =A0 =A0 themselves to map ids to accessibles in a manor that is saf=
e. =A0This
>     > =A0 =A0 saves the over head we'd have if we had an actor per access=
ible which
>     > =A0 =A0 would result in thousands of actors for sessions with many =
tabs.
>     >
>     > =A0 =A0 unresolved issues:
>     > =A0 =A0 - xpcom API should it be one tree or tree per process? afaik
>     AccessFoo
>     > =A0 =A0 =A0 assumes tree per process and our test suite assumes one=
 tree for
>     > =A0 =A0 everything, so we need to reconsile this somehow, but I'm n=
ot sure it
>     > =A0 =A0 needs to happen immediately.
>     >
>     > =A0 =A0 - we need to use the ipc infrastructure in the platform lay=
er to
>     handle
>     > =A0 =A0 =A0 accessible objects for content in child processes I'm n=
ot exactly
>     sure
>     > =A0 =A0 how this should look some ideas would include sub classing =
accessible
>     /
>     > =A0 =A0 making it more generic and having a proxy and local impleme=
ntation,
>     or
>     > =A0 =A0 maybe it would be better for platform API methods to explic=
itly
>     handle
>     > =A0 =A0 remote accessibles with something like if accWrap accWrap->=
FOobar()
>     else
>     > =A0 =A0 remoteDoc->Foobar(accWrapId) but I figure we can figure thi=
s out once
>     we
>     > =A0 =A0 have the plumbing either case will need to call sorted out.
>     >
>     > =A0 =A0 question / comments / whatever welcome!
>     >
>     > =A0 =A0 Trev
>     >
>     > =A0 =A0 _______________________________________________
>     > =A0 =A0 accessibility mailing list
>     > =A0 =A0 [email protected]
>     > =A0 =A0 https://lists.mozilla.org/listinfo/accessibility
>     >
>     >
>     >
> =

> =