Make Windows use RemoteAccessible for tree navigation and role
Categories
(Core :: Disability Access APIs, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox91 | --- | fixed |
People
(Reporter: Jamie, Assigned: Jamie)
References
(Blocks 1 open bug)
Details
Attachments
(11 files)
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details | |
(deleted),
text/x-phabricator-request
|
Details |
Once Windows has a separate class hierarchy, it should be possible to have it use RemoteAccessible for anything that doesn't require a sync IPC call. For now, this is only tree navigation and role. Of course, this should be done behind a pref.
This will require a lot of fail-early checks for other IAccessible methods to prevent crashes.
Assignee | ||
Comment 1•3 years ago
|
||
With the cache disabled (which was previously always the case), we create a RemoteAccessibleWrap for each RemoteAccessible, stored as the RemoteAccessible's "Wrapper".
This in turn creates an MsaaAccessible.
However, both of these are little more than stubs: the MsaaAccessible itself is never returned to clients and most of the methods would crash if called.
They exist only to store the MSAA id received from the content process and to return the COM proxy from the content process to clients.
With the cache enabled, we now create a real MsaaAccessible for each RemoteAccessible, stored as the RemoteAccessible's "Wrapper".
This MsaaAccessible is directly returned to clients.
Soon, it will generate its own id in the parent process and will delegate to the underlying RemoteAccessible to serve queries from clients.
As part of this:
- We stop managing COM proxies in the parent process when the cache is enabled, since we don't need those and can't store them anyway.
- We stop setting the id on the MsaaAccessible when the cache is enabled, since it will soon generate its own id like local MsaaAccessibles do.
- OuterDocAccessible::ChildCount had to be tweaked so it doesn't try to return a RemoteAccessibleWrap when the cache is enabled. (It previously called RemoteChildDocAccessible, which fetches a RemoteAccessibleWrap.)
Assignee | ||
Comment 2•3 years ago
|
||
- Add support for RemoteAccessible in MsaaAccessible::GetFrom.
- Add an overload of MsaaDocAccessible::GetFrom which accepts a (remote) DocAccessibleParent.
- Add MsaaDocAccessible::GetFromOwned to return the containing document's MsaaDocAccessible for a given Accessible.
- MsaaAccessible::LocalAcc now returns null for a RemoteAccessible, rather than just assuming the accessible is local.
- MsaaAccessible::NativeAccessible now supports retrieving a native client pointer for LocalAccessibles, RemoteAccessibles and RemoteAccessibleWraps.
Assignee | ||
Comment 3•3 years ago
|
||
- Make MsaaDocAccessible id maps contain Accessibles instead of AccessibleWraps. This allows us to put RemoteAccessibles in the id map.
- Make MsaaAccessible::MsaaShutdown and GetChildIDFor handle RemoteAccessibles. GetChildIDFor lazily generates an id, Just as it does for LocalAccessible.
Assignee | ||
Comment 4•3 years ago
|
||
- GetHWNDFor and FireWinEvent now take an Accessible and support RemoteAccessible.
- The Proxy*Event methods pass a RemoteAccessible instead of a RemoteAccessibleWrap, since RemoteAccessibleWraps aren't used with the cache enabled. FireWinEvent retrieves the RemoteAccessibleWrap if the cache is disabled.
Assignee | ||
Comment 5•3 years ago
|
||
For now, a lot of interfaces are disabled, since they don't support RemoteAccessibles at all.
Assignee | ||
Comment 6•3 years ago
|
||
Assignee | ||
Comment 7•3 years ago
|
||
Assignee | ||
Comment 8•3 years ago
|
||
Assignee | ||
Comment 9•3 years ago
|
||
Assignee | ||
Comment 10•3 years ago
|
||
Sending these doesn't really do any harm, as we already disregard them in the parent process.
However, it's certainly unnecessary and wasteful.
Assignee | ||
Comment 11•3 years ago
|
||
This isn't used and thus isn't necessary.
Also, we can currently only support 127 content processes because of this id allocation, so avoiding this removes that restriction.
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/56ac84b2eae0
https://hg.mozilla.org/mozilla-central/rev/517f726f1c3e
https://hg.mozilla.org/mozilla-central/rev/b441f1c4bf99
https://hg.mozilla.org/mozilla-central/rev/d52bb54ca76a
https://hg.mozilla.org/mozilla-central/rev/232ba8d9bcd2
https://hg.mozilla.org/mozilla-central/rev/b067a69fc41b
https://hg.mozilla.org/mozilla-central/rev/84745f573a55
https://hg.mozilla.org/mozilla-central/rev/55273d675037
https://hg.mozilla.org/mozilla-central/rev/52c836904523
https://hg.mozilla.org/mozilla-central/rev/185d685563d9
https://hg.mozilla.org/mozilla-central/rev/804044733a13
Description
•