An Electrolysis Accessibility Plan
david bolter
A bunch of us met this morning as part of the Mozilla a11y work week in
Toronto to discuss accessibility changes required for multi-process content
on Windows (meta bug: https://bugzilla.mozilla.org/show_bug.cgi?id=646596).
We came away with agreement on a plan. Here is a summary of the problem and
our plan:
Problem statement:
Don't break assistive technology interoperation with unsandboxed
multi-process Firefox.
Background:
Assistive technology (AT) such as screen readers use desktop accessibility
API (MSAA/IA2) to gather information from Firefox. This API is implemented
on COM technology. This is too slow for interrogation of a complex
application so screen readers inject dlls into our processes so that they
can get around performance issues related to marshalling across processes.
This latter fact complicates possible solutions.
Solution:
We will have an instance of our accessibility engine run in each process,
and keep a copy of the accessibility tree that represents the information in
its own process. AT will get the information from each process directly.
Internally we will graft the accessibility tree in each child process onto
the main accessibility tree using COM remoting magic, via either
AccessibleObjectFromWindow or AccessibleObjectFromEvent system calls (see
https://bugzilla.mozilla.org/show_bug.cgi?id=649720#c3).
A scary bit. When AT code injected into the main process gets the accessible
object for the content root in a content process, we need to make sure that
traversing down into child accessibles doesn't happen from the main process.
This would incur a marshalling penalty as well as block the main process,
subverting the usability win of not blocking our chrome UI.
Notes:
Sandboxing will require more invasive changes to how we support
accessibility. There are a variety of options that involve various levels of
caching and/or mirroring of information. After serious consideration of the
tradeoffs between the shorter term solution described above, and the longer
term sandbox-ready solutions, taking into consideration engineering time and
the data we have we conclude this pre-sandboxed solution above is the way to
go right now.
For Linux, at least in the short term here, we're going with the atk
plug/socket technology (this work happening here:
https://bugzilla.mozilla.org/show_bug.cgi?id=669625).
Cheers,
David
Ehsan Akhgari
* Do we have any plans on how this is going to work with 64-bit
Windows builds in mind?
* Do we know if we need to do out-of-process COM or not? If we do, we
should figure out whether we should use the default COM marshaller
available in Windows, or if we need to take care of marshaling
manually ourselves.
Cheers,
Ehsan
On Jul 6, 11:49 am, david bolter <david.bol...@gmail.com> wrote:
> Hi.
>
> A bunch of us met this morning as part of the Mozilla a11y work week in
> Toronto to discuss accessibility changes required for multi-process content
> on Windows (meta bug:https://bugzilla.mozilla.org/show_bug.cgi?id=646596).
> We came away with agreement on a plan. Here is a summary of the problem and
> our plan:
>
> Problem statement:
> Don't break assistive technology interoperation with unsandboxed
> multi-process Firefox.
>
> Background:
> Assistive technology (AT) such as screen readers use desktop accessibility
> API (MSAA/IA2) to gather information from Firefox. This API is implemented
> on COM technology. This is too slow for interrogation of a complex
> application so screen readers inject dlls into our processes so that they
> can get around performance issues related to marshalling across processes.
> This latter fact complicates possible solutions.
>
> Solution:
> We will have an instance of our accessibility engine run in each process,
> and keep a copy of the accessibility tree that represents the information in
> its own process. AT will get the information from each process directly.
> Internally we will graft the accessibility tree in each child process onto
> the main accessibility tree using COM remoting magic, via either
> AccessibleObjectFromWindow or AccessibleObjectFromEvent system calls (seehttps://bugzilla.mozilla.org/show_bug.cgi?id=649720#c3).
Alexander Surkov
1) What special do you see in 64-bit support for e10s firefox?
2) Yes, we were asked for. I hope that can be done by COM marshaller.
Still need do testing.
Thank you.
Alex.
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>
Ehsan Akhgari
> Hi, Ehsan.
>
> 1) What special do you see in 64-bit support for e10s firefox?
David Bolter has mentioned to me that (at least some of) the ATs inject
their own DLL into Firefox's address space. That would break if they
inject a 32-bit DLL into a 64-bit process (assuming that we ship a
64-bit version of Firefox on Windows in the future).
Also, if we implement a single-threaded apartment COM server for
accessibility, which the ATs need to load in their address space, a
similar architecture match scenario should be considered.
(These are concerns with or without e10s, but if they're real problems,
and we're looking into rearchitecturing a11y for e10s, then we might as
well try to address these now too.)
> 2) Yes, we were asked for. I hope that can be done by COM marshaller.
> Still need do testing.
IIRC, the COM marshaller used to have performance problems, and in the
old days where everybody used to write COM code, you would write your
own marshaller if you wanted good performance (a similar situation to
XPConnect and quickstubs, the former is a general purpose dispatch
mechanism which can be slow, and the latter is a specific dispatch
mechanism which uses exact information about the call in question to
make the dispatch faster).
I'm not sure if this is going to be a bottleneck for us, but it's a good
idea to keep it in mind (and maybe do some benchmarks) in case we need
to worry about it later.
Cheers,
Ehsan
Alexander Surkov
1) a11y support in 64-bit Firefox is on track. But thanks pointing to
the issue. Btw, is it a problem if they inject 64-bit dll into 32-bit
process?
2) This can be a real problem since out-of-process AT are much slower
than in-process ones. So we might want to deal with COM marshaling
even out of context of multiprocessing support. Do you have links
where I can learn more about this practice?
Thank you.
Alex.
Ehsan Akhgari
> Hi, Ehsan.
>
> the issue. Btw, is it a problem if they inject 64-bit dll into 32-bit
> process?
Yes, it wouldn't work.
> 2) This can be a real problem since out-of-process AT are much slower
> than in-process ones. So we might want to deal with COM marshaling
> even out of context of multiprocessing support. Do you have links
> where I can learn more about this practice?
I believe you can find some resources about this on MSDN. It's been a
very long time since I've had to look into this stuff, but Essential COM
used to be the bible of anything related to COM, and it's a very good
book. You should probably take a look at it.
Cheers,
Ehsan
Benjamin Smedberg
>
> David Bolter has mentioned to me that (at least some of) the ATs
> inject their own DLL into Firefox's address space. That would break
> if they inject a 32-bit DLL into a 64-bit process (assuming that we
> ship a 64-bit version of Firefox on Windows in the future).
injection will have to deal with 64-bit processes.
>
> IIRC, the COM marshaller used to have performance problems, and in the
> old days where everybody used to write COM code, you would write your
> own marshaller if you wanted good performance (a similar situation to
> XPConnect and quickstubs, the former is a general purpose dispatch
> mechanism which can be slow, and the latter is a specific dispatch
> mechanism which uses exact information about the call in question to
> make the dispatch faster).
>
> I'm not sure if this is going to be a bottleneck for us, but it's a
> good idea to keep it in mind (and maybe do some benchmarks) in case we
> need to worry about it later.
we should worry about this. Some ATs will inject DLLs for performance,
and the others will use the default marshalling mechanism for
cross-process access.
--BDS