On Windows, OuterDocAccessible::GetChildAt can return a proxy wrapper for a remote document.
These aren't real Accessibles and shouldn't be returned except to the Windows a11y code (which doesn't use eDeepestChild).
Calling ChildAtPoint on these will crash!
Therefore, just return null in this case.
Differential Revision: https://phabricator.services.mozilla.com/D39135
--HG--
extra : moz-landing-system : lando
Previously, BrowserBridgeChild::SendSetEmbedderAccessible was only called when an OuterDocAccessible was constructed.
However, it's also possible that the BrowserBridgeChild is created *after* the OuterDocAccessible.
Therefore, we must also do this when a BrowserBridgeChild is created if the OuterDocAccessible already exists.
Differential Revision: https://phabricator.services.mozilla.com/D34474
--HG--
extra : moz-landing-system : lando
Previously, BrowserBridgeChild::SendSetEmbedderAccessible was only called when an OuterDocAccessible was constructed.
However, it's also possible that the BrowserBridgeChild is created *after* the OuterDocAccessible.
Therefore, we must also do this when a BrowserBridgeChild is created if the OuterDocAccessible already exists.
Differential Revision: https://phabricator.services.mozilla.com/D34474
--HG--
extra : moz-landing-system : lando
Fixes test 'accessible/tests/mochitest/relations/test_general.xul' when
loaded as XHTML.
Differential Revision: https://phabricator.services.mozilla.com/D34655
--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
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
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
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
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
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
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 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
`nsIPresShell::ScrollAxis` can be used anywhere and it's used by some
utils actually. So, it should be in `mozilla` namespace and perhaps,
`PresShellForwards.h` is a good place to move it rather than creating
new header file.
Differential Revision: https://phabricator.services.mozilla.com/D29110
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
For XULTreeAccessible, the ChildCount() is not only the mChildren, so check mChildren directly to make sure we stay within bounds
Differential Revision: https://phabricator.services.mozilla.com/D27553
--HG--
extra : moz-landing-system : lando
It's a bit useless, only has one implementation. Call into the shell directly
instead.
Differential Revision: https://phabricator.services.mozilla.com/D27910
--HG--
extra : moz-landing-system : lando
Sometimes, we use aria-activedescendant targeting something which isn't actually a descendant.
This is technically a spec violation, but it's a useful hack which makes certain things much easier.
For example, we use this for "fake focus" for multi select browser tabs and Quantumbar autocomplete suggestions.
This already worked previously; the accessible received a focus event and the focused state.
However, it did *not* receive the focusable state.
This is because the code which applies the focusable state for potential active descendants only works for descendants.
It really doesn't make sense for something to be focused when it isn't focusable.
In fact, this is an a11y test failure when it occurs.
So, if the active item has the focused state, ensure we expose the focusable state too.
Differential Revision: https://phabricator.services.mozilla.com/D27021
--HG--
extra : moz-landing-system : lando
This patch makes accessible module use `mozilla::PresShell` directly rather
than via `nsIPresShell`. Additionally, renames `DocAccessible::PresShell()`
to `DocAccessible::PresShellPtr()` for avoiding conflict with using
`PresShell` in it and its sub classes.
Differential Revision: https://phabricator.services.mozilla.com/D26663
--HG--
extra : moz-landing-system : lando
This patch marks some methods of nsCoreUtils which are found at writing the
following patches, as `MOZ_CAN_RUN_SCRIPT`.
Due to bug 1543294, some of them are marked as `MOZ_CAN_RUN_SCRIPT_BOUNDARY`
because `MOZ_CAN_RUN_SCRIPT` requires to change base class, but that's
other licenses header or used in our code too many places.
Differential Revision: https://phabricator.services.mozilla.com/D26926
--HG--
extra : moz-landing-system : lando
This patch makes `nsDocShell::GetPresShell()` and
`nsDocShell::GetEldestPresShell()` return `mozilla::PresShell*` and
some non-public methods use `mozilla::PresShell*` directly.
Differential Revision: https://phabricator.services.mozilla.com/D26424
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
A lot of files include `nsIPresShell.h` even though currently they don't
need it. This patch removes the unnecessary inclusions.
Differential Revision: https://phabricator.services.mozilla.com/D25744
--HG--
extra : moz-landing-system : lando
`nsICommandManager` isn't implemented by JS even in comm-central nor
BlueGriffon. Therefore, we can make it a builtinclass.
Additionally, this patch makes all users in C++ use `nsCommandManager` which is
the only implementation of `nsICommandManager`. This avoids QI from
`nsICommandManager` to `nsPICommandUpdater`.
Differential Revision: https://phabricator.services.mozilla.com/D25726
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
