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
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...?
> 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
> > the main process, so if the main process doesn't dupe DOM trees of
> > 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 <
> >> 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@example.com
> >> https://lists.mozilla.org/listinfo/accessibility
> > _______________________________________________
> > accessibility mailing list
> > firstname.lastname@example.org
> > https://lists.mozilla.org/listinfo/accessibility
> accessibility mailing list