This is a good place to formalize the following naming convention:
* A "field" is and direct accessible getter method (name,
role, value, min, max, etc.)
* An "attribute" is a member of the "attributes" field.
With that said, I think AccAttributes should probably be named
AccProperties or something of the sort. Might leave that for another
time.
Differential Revision: https://phabricator.services.mozilla.com/D121924
Previously, when the cache was disabled, we had a RemoteAccessibleWrap for every RemoteAccessible.
This is no longer necessary and now only serves as an extra level of indirection and memory waste.
We still keep the stub MsaaAccessible to hold the id sent up from content.
Differential Revision: https://phabricator.services.mozilla.com/D117528
An OuterDocAccessible can be recreated, causing the embedder accessible for a BrowserBridgeParent (OOP iframe) to change.
However, changing the src of an iframe can also cause a new BrowserBridgeParent to be created.
Previously, if addition of the child document was still pending when this occurred (because the OuterDocAccessible hadn't been sent to the parent yet), this pending addition could remain, causing problems if the id was reused later.
To fix this (and to hopefully make this more robust given the continued problems we're seeing in the wild with this area of the code), I've completely refactored the way we handle these pending child doc additions.
Rather than tracking the pending additions by their accessible id and child doc, we track them by their BrowserBridgeParent.
This way, we're closest to a single source of truth.
We also remove a pending addition when an associated BrowserBridgeParent is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D117889
An OuterDocAccessible can be recreated, causing the embedder accessible for a BrowserBridgeParent (OOP iframe) to change.
However, changing the src of an iframe can also cause a new BrowserBridgeParent to be created.
Previously, if addition of the child document was still pending when this occurred (because the OuterDocAccessible hadn't been sent to the parent yet), this pending addition could remain, causing problems if the id was reused later.
To fix this (and to hopefully make this more robust given the continued problems we're seeing in the wild with this area of the code), I've completely refactored the way we handle these pending child doc additions.
Rather than tracking the pending additions by their accessible id and child doc, we track them by their BrowserBridgeParent.
This way, we're closest to a single source of truth.
We also remove a pending addition when an associated BrowserBridgeParent is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D117889
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:
1. 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.
2. 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.
3. 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.)
Differential Revision: https://phabricator.services.mozilla.com/D116191
Previously, if an OuterDoc was never sent to the parent process and its id was reused later, we ended up adding the document to that accessible, which usually wasn't even an OuterDoc.
Alongside the actual fix, add some assertions to make breakage in this area easier to debug in future.
Differential Revision: https://phabricator.services.mozilla.com/D115777
Returning an IPC failure causes a crash in the content process on Nightly.
However, the crash doesn't have a useful stack.
A diagnostic assert will cause a full browser crash instead of a tab crash, which isn't ideal.
On the other hand, it will hopefully allow us to get much more useful info about the crash.
Differential Revision: https://phabricator.services.mozilla.com/D115054
Removes NPAPI plugin support from accessible/, as part of removing all of NPAPI plugin support. This was the only reason for HTMLWin32ObjectAccessible was needed, so we get rid of that, too.
Differential Revision: https://phabricator.services.mozilla.com/D107143
Removes NPAPI plugin support from accessible/, as part of removing all of NPAPI plugin support. This was the only reason for HTMLWin32ObjectAccessible was needed, so we get rid of that, too.
Differential Revision: https://phabricator.services.mozilla.com/D107143
This is a collaboration between clang-tidy and clang-format.
clang-tidy uses compiled code paths, so this patch is linux specific.
Differential Revision: https://phabricator.services.mozilla.com/D105669
The COM proxy for a DocAccessibleParent at the top level in its content process really should never be null.
However, some systems seem to have a broken COM configuration which causes problems like this.
This does mean a11y is broken, but users who get a11y enabled because of something other than an AT (e.g. touch screen) probably aren't even aware.
Regardless, we shouldn't crash.
Instead, we assert (in debug builds) and null check.
Differential Revision: https://phabricator.services.mozilla.com/D102129
Besides the ARIA role invalidation, this fixes an issue where the mozAccessible's role is also incorrect when the aria role changes on a body tag.
Depends on D93439
Differential Revision: https://phabricator.services.mozilla.com/D93440
This includes 3 changes:
1. Add a lazy ranges getter to AccTextSelChangeEvent.
2. Create an XPCOM interface for testing purposes.
3. Add IPDL bindings for passing ranges in e10s.
Differential Revision: https://phabricator.services.mozilla.com/D80556
We can receive IPC events after a DocAccessibleParent is shut down if the BrowserParent is in the process of being destroyed (probably the tab closed) but there are still events in the IPC queue.
Most Recv*Event methods in BrowserParent check mShutdown, but a few don't.
For the events that don't, if the event is for a document, we'll successfully fire the platform event, and then successfully get and cache an xpcAccessibleDocument.
However, that xpcAccessibleDocument will never be removed from the cache because it's already shut down, so NotifyOfRemoteDocShutdown (which would normally remove it from the XPC cache) won't get called.
This results in a leaked object.
Thus, it's important that all Recv*Event methods drop the event if mShutdown is true.
This patch adds that check to the methods which didn't have it already.
Differential Revision: https://phabricator.services.mozilla.com/D79780
DocAccessibleParent::AddChildDoc sends a COM proxy for the embedded document to the embedder process hosting the iframe.
This gets returned as the child of the embedder OuterDocAccessible.
Whenever we send a proxy to a content process, we must hold a PreservedStreamPtr in the parent process.
Previously, we set mDocProxyStream on the parent (embedder) document.
However, if a document had multiple OOP iframes, this meant we ended up losing the PreservedStreamPtr for all but the last added child OOP document.
We now set mDocProxyStream on the child document instead, since there can only be one embedder OuterDocAccessible per child document.
Differential Revision: https://phabricator.services.mozilla.com/D74584
For OOP iframes, the top level document lives in a different process.
Previously, we incorrectly returned the top level document in the same process.
This was causing JAWS to incorrectly identify OOP iframe documents as separate tab documents.
To fix this, we must send the real top level document down from the parent process and return that when requested in the content process.
Differential Revision: https://phabricator.services.mozilla.com/D70162
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
3. Mac's implementation of ProxyCreated requires that AddChildDoc be called *before* ProxyCreated so it can invalidate the native children of the parent.
Because it's possible for an OOP iframe document to be added to its embedder after the document is created, we can't satisfy this requirement for OOP iframe documents.
Therefore, we now allow a null parent in Mac's ProxyCreated and use the reorder event fired later to invalidate the native children.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
For OOP iframes, sometimes, AddChildDoc gets called before the embedder sends us the OuterDocAccessible.
Previously, we crashed when this occurred.
Now, we add the child when the OuterDocAccessible proxy gets created later.
Differential Revision: https://phabricator.services.mozilla.com/D42798
--HG--
extra : moz-landing-system : lando
Previously, we expected that we'd always be able to get the COM proxy for the parent (outer doc), so we crashed if it was null.
For an out-of-process iframe, this sometimes fails.
That is probably because the outer doc died in the embedder process, but the parent process hasn't received a message to remove it from the ProxyAccessible tree yet.
Differential Revision: https://phabricator.services.mozilla.com/D40150
--HG--
extra : moz-landing-system : lando
For same-process iframe documents, this reorder event is fired by the content process.
This isn't possible when the document is in a different process to its embedder.
In this case, we need to fire it from the parent process when the embedded document accessible is added.
Differential Revision: https://phabricator.services.mozilla.com/D37352
--HG--
extra : moz-landing-system : lando
Previously, DocAccessibleParent::AddChildDoc used the presence of a BrowserBridgeParent to determine whether the child document was in a different process to the parent document.
While this is normally the case, there can be a point while the embedded document is loading where there is a temporary document in the same (embedder) process.
In this case, we tried to get the COM proxy for the child document.
For a child document in the same process, this isn't available yet, so this caused infinite recursion (stack overflow) in ProxyAccessible::GetCOMInterface.
Instead of using the presence of BrowserBridgeParent, first check whether the child document is at the top level of its content process.
If it isn't, the document is in the same process as its parent.
Also, add a DIAGNOSTIC_ASSERT to ProxyAccessible::GetCOMInterface which will fire if no COM proxy or MSAA child id has been set.
Previously, we just recursed infinitely and overflowed the stack in this case, which is painful to debug.
Differential Revision: https://phabricator.services.mozilla.com/D37344
--HG--
extra : moz-landing-system : lando
