If window emulation is enabled, an out-of-process iframe document should use the same emulated window as its embedder.
Previously, we were setting this on DocAccessibleParent, but we weren't sending it to content to make it available on DocAccessibleChild.
This meant that accessibles in out-of-process iframe documents were reporting the wrong window handle.
Differential Revision: https://phabricator.services.mozilla.com/D32788
--HG--
extra : moz-landing-system : lando
It must be possible to retrieve any accessible by calling IAccessible::accChild on the RootAccessible (in the parent process) with the unique id of the desired accessible.
Among other things, this is the way accessibility events are targeted on Windows.
Previously, this code only searched remote documents at the top level of the tree.
In order to support out-of-process iframes, it must now also search embedded documents at the top level of their content process.
As part of this, the MSAA id must be set for out-of-process iframe documents, just as it is for top level documents.
This was already being sent from the content process, but previously, we didn't store this in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D32417
--HG--
extra : moz-landing-system : lando
Aside from the parent being needed by the client, this is also important because events from the embedded document are deferred until the parent COM proxy is received.
As part of this, we no longer try to send the parent COM proxy during construction of an OuterDocAccessible in the parent process.
This was previously a no-op anyway, as DocAccessibleParent::SendParentCOMProxy called DocAccessible::GetAccessible for the frame element, which would have returned null because the accessible isn't bound to the document until *after* it is constructed.
Changing this to directly pass the OuterDocAccessible was causing assertions in content processes, since it sometimes meant the parent COM proxy was sent twice, which is precisely what the assertion is protecting against.
Instead, the parent proxy is sent in Browserparent::RecvPDocAccessibleConstructor as it always was.
Differential Revision: https://phabricator.services.mozilla.com/D32284
--HG--
extra : moz-landing-system : lando
Previously, a COM proxy was only sent from content for top level documents.
Now, a COM proxy is also sent (and needed) for out-of-process iframe documents.
This change adjusts GetProxiedAccessibleInSubtree accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D32283
--HG--
extra : moz-landing-system : lando
DocAccessibleParent already has IsTopLevel(), which identifies a document at the top level of the hierarchy; i.e. it has no parents.
Now that we have out-of-process iframes, we need to be able to identify and retrieve documents at the top level of their content process, even if they are embedded by another remote document.
DocAccessibleParent::IsTopLevelInContentProcess() has been introduced to achieve this.
BrowserParent::GetTopLevelDocAccessible() now uses this instead of IsTopLevel(), since we want to be able to get the top DocAccessibleParent even for a BrowserParent for an out-of-process iframe.
Differential Revision: https://phabricator.services.mozilla.com/D32282
--HG--
extra : moz-landing-system : lando
I think this is a good change regardless of other discussion in bug 1552587. If
we decide to move `mColor` to the top-level of the struct that can be done
separately.
Differential Revision: https://phabricator.services.mozilla.com/D32726
--HG--
extra : moz-landing-system : lando
It must be possible to retrieve any accessible by calling IAccessible::accChild on the RootAccessible (in the parent process) with the unique id of the desired accessible.
Among other things, this is the way accessibility events are targeted on Windows.
Previously, this code only searched remote documents at the top level of the tree.
In order to support out-of-process iframes, it must now also search embedded documents at the top level of their content process.
As part of this, the MSAA id must be set for out-of-process iframe documents, just as it is for top level documents.
This was already being sent from the content process, but previously, we didn't store this in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D32417
--HG--
extra : moz-landing-system : lando
Aside from the parent being needed by the client, this is also important because events from the embedded document are deferred until the parent COM proxy is received.
Differential Revision: https://phabricator.services.mozilla.com/D32284
--HG--
extra : moz-landing-system : lando
Previously, a COM proxy was only sent from content for top level documents.
Now, a COM proxy is also sent (and needed) for out-of-process iframe documents.
This change adjusts GetProxiedAccessibleInSubtree accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D32283
--HG--
extra : moz-landing-system : lando
DocAccessibleParent already has IsTopLevel(), which identifies a document at the top level of the hierarchy; i.e. it has no parents.
Now that we have out-of-process iframes, we need to be able to identify and retrieve documents at the top level of their content process, even if they are embedded by another remote document.
DocAccessibleParent::IsTopLevelInContentProcess() has been introduced to achieve this.
BrowserParent::GetTopLevelDocAccessible() now uses this instead of IsTopLevel(), since we want to be able to get the top DocAccessibleParent even for a BrowserParent for an out-of-process iframe.
Differential Revision: https://phabricator.services.mozilla.com/D32282
--HG--
extra : moz-landing-system : lando
Windows accessibility clients talk directly to the content process via COM.
In order to expose an OOP iframe document accessible as a child of the embedder iframe accessible via COM, the embedder process needs a COM proxy for the iframe document accessible.
This is exposed on the embedder's BrowserBridgeChild, so we can use this when a client asks for the child of the OuterDocAccessible.
Differential Revision: https://phabricator.services.mozilla.com/D32281
--HG--
extra : moz-landing-system : lando
For an out-of-process iframe, we need to be able to return a remote embedder accessible as a child of an OuterDocAccessible.
For parent process OuterDocAccessibles, we use the ProxyAccessible for the embedded document.
In the case of out-of-process iframes, there is no ProxyAccessible for the embedded document, since the iframe is in a content process and ProxyAccessibles only exist in the parent process.
Like ProxyAccessibleWrap, the only real method that gets called is GetNativeInterface, which returns a COM proxy for the document.
Differential Revision: https://phabricator.services.mozilla.com/D32278
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEventWithCurrentEventInfo is the only possible
place will do such handling; other places pass either a nullptr or a
non-MouseDown/Up event.
Differential Revision: https://phabricator.services.mozilla.com/D32431
--HG--
extra : moz-landing-system : lando
For iframes in a different process to their embedder, when the embedded iframe content process tells the parent process about the iframe document, it does not have the actor for the parent document accessible, nor does it know the accessible id of the embedding iframe.
However, the embedder will have previously sendt the actor and id for the embedder accessible to the parent via PBrowserBridge, so we can use that to identify the parent accessible.
Differential Revision: https://phabricator.services.mozilla.com/D31395
--HG--
extra : moz-landing-system : lando
We do this when the OuterDocAccessible is constructed.
This will be used later in the parent process to link the trees together when the iframe's embedded document accessible is added.
Differential Revision: https://phabricator.services.mozilla.com/D31394
--HG--
extra : moz-landing-system : lando
Supporting out-of-process iframes requires us to hold onto a DocAccessibleParent in BrowserBridgeParent.
However, we can't guarantee the order of cleanup between the two content processes.
Therefore, we need reference counting to kee the object alive.
Differential Revision: https://phabricator.services.mozilla.com/D32277
--HG--
extra : moz-landing-system : lando
Accessibles can be shut down twice. For example, their doc might shut
them down in its own ShutDown, while a reference is still being held by
a dispatched event. When the event goes away, or the cycle collector
kicks in, the accessible may be finally released and shut down again via
LastRelease.
Differential Revision: https://phabricator.services.mozilla.com/D31815
--HG--
extra : moz-landing-system : lando
If the DOM focus is removed before something else is focused, the document gets DOM focus, but no blur event is fired (bug 559561).
This means that no a11y focus event is fired, so clients aren't notified.
This is particularly problematic for screen readers when dismissing some ARIA dialogs, as the screen reader doesn't know that focus has returned to the top level document.
Differential Revision: https://phabricator.services.mozilla.com/D31024
--HG--
extra : moz-landing-system : lando
The GECKOBUNDLE macros are useful to more than just a11y code, so let's move them into the jni package so that all jni consumers may drink of their sweet nectar.
Differential Revision: https://phabricator.services.mozilla.com/D30585
--HG--
extra : moz-landing-system : lando
This commit moves the actual implementation of nsIRemoteTab from BrowserParent
to BrowserHost, without any functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D31445
--HG--
extra : source : d25963c72ff7981990660050182a82ea3e935f53
This commit removes nsIRemoteTab as a parent class from BrowserParent,
so that BrowserHost is the only concrete implementation of nsIRemoteTab.
Some static_cast's are updated to cast to BrowserHost, and other places
have to be updated to pass a BrowserHost instead of a BrowserParent.
WindowGlobalParent had a getter to return it's managing BrowserParent
as a nsIRemoteTab. I couldn't find a use of this in-tree, so I've just
opt-ed to remove it. If there's a use-case, we can add something back
in.
Differential Revision: https://phabricator.services.mozilla.com/D31444
--HG--
extra : source : 810b7371987139844429d0206f9da6a7701a1efc
This commit moves the actual implementation of nsIRemoteTab from BrowserParent
to BrowserHost, without any functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D31445
--HG--
extra : rebase_source : 2e6533dfa69a3278300eb70d5258bcd0a3aba68b
extra : histedit_source : a26ba68b78eb6d16cdffbc630f4410c5dd46a367
This commit removes nsIRemoteTab as a parent class from BrowserParent,
so that BrowserHost is the only concrete implementation of nsIRemoteTab.
Some static_cast's are updated to cast to BrowserHost, and other places
have to be updated to pass a BrowserHost instead of a BrowserParent.
WindowGlobalParent had a getter to return it's managing BrowserParent
as a nsIRemoteTab. I couldn't find a use of this in-tree, so I've just
opt-ed to remove it. If there's a use-case, we can add something back
in.
Differential Revision: https://phabricator.services.mozilla.com/D31444
--HG--
extra : rebase_source : 63070e3c2b90c9134f9106028e124935c8dad009
extra : histedit_source : 807f2ff684d86008077be07b0894f39a925fe778
Emilio Cobos Álvarez
James Teh
Noemi Erli
Edgar Chen
Sylvestre Ledru
arthur.iakab
Eitan Isaacson
Daniel Varga
Brendan Dahl
Gijs Kruitbosch
Boris Zbarsky
Tim Nguyen
Coroiu Cristina
J.C. Jones
Hiroyuki Ikezoe
Dão Gottwald
Alexander Surkov
Masayuki Nakano
Ryan Hunt
Gurzau Raul
Mike de Boer