For remote content documents, select dropdowns (for <select size="1">) are rendered in the parent process using a XUL menupopup.
This means that the accessibility code for HTML selects doesn't apply.
In the menupopup, the optgroup is a sibling of its contained options.
For accessibility, we want to preserve the hierarchy such that the options are inside the optgroup.
We do this using aria-owns on the optgroup item.
This required some tweaks to XULMenuitemAccessible, as it couldn't previously handle grouping Accessibles between the menupopup and its items.
Differential Revision: https://phabricator.services.mozilla.com/D43901
--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
And also this patch moves `TextEditRules::HandleNewLines()` and
`TextEditRules::DontEchoPassword()` to `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D45298
--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
Having a full VPATH for the srcdir sometimes causes make to grab the
wrong prerequisite for a rule, in particular if we have a file in the
srcdir and also generate a file of the same name in the objdir. We don't
really need VPATH anymore though, since most of the information comes
from mozbuild, where we can explicitly list the path to the srcdir or
objdir as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D42968
--HG--
extra : moz-landing-system : lando
`WindowsErrorResult` is a class to hold either a value or a Windows error
code based on the `Result` template. We also have `LauncherResult` for the
same purpose, which was introduced as a part of the launcher process feature
afterward. The difference is `LauncherResult` holds a filename and line
number along with an error code.
This patch integrates LauncherResult.h into WinHeaderOnlyUtils.h so that we
can use `LauncherResult` more broadly.
Differential Revision: https://phabricator.services.mozilla.com/D44512
--HG--
extra : moz-landing-system : lando
This assures that a node that has already been inserted in a shadow root
subtree does not get erroneously reinserted into the top container.
Differential Revision: https://phabricator.services.mozilla.com/D44880
--HG--
extra : moz-landing-system : lando
focusChecker expects a unique focus event.
However, there might still be pending focus events not caught by previous tests.
Therefore, we specify our own checker so we can disable the uniqueness requirement.
This is a little ugly, but it's rather difficult to work around this within this declarative framework without potentially breaking other tests.
Differential Revision: https://phabricator.services.mozilla.com/D44615
--HG--
extra : moz-landing-system : lando
Pruning these meant that `<span><br></span>` wasn't represented in the tree or rendered text at all.
This meant that lines were merged together in NVDA browse mode; e.g. in CI build logs on Gitlab.
The reason we started pruning these is that they were causing invalid line offsets to be returned for affected lines (bug 899433).
This patch also fixes this problem in HyperTextAccessible::FindOffset.
Differential Revision: https://phabricator.services.mozilla.com/D44815
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
For labels inside buttons, The base implementation of DispatchClickEvent doesn't fire a command event on the button.
To fix this, override DispatchClickEvent to use nsXULElement::Click, which does fire a command event on the button.
Differential Revision: https://phabricator.services.mozilla.com/D44410
--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
We have an optimization to avoid an expensive reflow from SetFullZoom, see
mSuppressResizeReflow[1].
That was done because we used to do a full synchronous reflow right after. We no
longer do that, but due to that member we also don't invalidate!
My second patch in this bug changes the behavior of that flag so that we don't
synchronously reflow, but we do invalidate. So in turn this test before the
change wasn't really testing the zoomed code-path since it was using the clean
layout from before the zoom operation.
a11y getBounds and co. don't flush layout (they probably should), but since with
my patch we dirty the frame tree, and dirty frames return bogus offsets, the
test starts failing.
Flush layout explicitly to ensure we're testing the zoomed code path.
[1]: https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/layout/base/nsPresContext.cpp#952
Differential Revision: https://phabricator.services.mozilla.com/D43952
--HG--
extra : moz-landing-system : lando
This patch does several things:
1. If there is a change to a host or a slot, check the slottable
elements to see if they are rendered in the tree. Remove them if not.
2. Check slot elements' fallback content if it is rendered and remove if
not.
3. Allow accessibles to be reinserted into a different parent or index.
Differential Revision: https://phabricator.services.mozilla.com/D43489
--HG--
extra : moz-landing-system : lando
Converts ui.key.generalAccessKey, ui.key.chromeAccess, and ui.key.contentAccess to static prefs. Updates usages.
Differential Revision: https://phabricator.services.mozilla.com/D42392
--HG--
extra : moz-landing-system : lando
performAction, performActionOnRow and performActionOnCell are methods of the
nsITreeView interface that are never called. This is to remove these methods.
A comm-central patch will be along shortly.
Differential Revision: https://phabricator.services.mozilla.com/D39273
I replaced the values with -moz-inline-box in the crashtests
rather than removing them. I think they are still valuable
after replacing the display value.
Differential Revision: https://phabricator.services.mozilla.com/D42551
--HG--
extra : moz-landing-system : lando
1. As per the spec, if maxTargets is 0, return all targets.
2. Where maxTargets > 0, fix the loop condition so it doesn't incorrectly fetch one more target than requested.
Differential Revision: https://phabricator.services.mozilla.com/D42446
--HG--
extra : moz-landing-system : lando
The DOM mutation observer method is called during frame destruction
which is not a good state to be in when constructing and dispatching events.
Differential Revision: https://phabricator.services.mozilla.com/D41825
--HG--
extra : moz-landing-system : lando
(This basically addresses the review comments that I missed in
bug 1105868 part 4. My bad.)
Differential Revision: https://phabricator.services.mozilla.com/D42134
--HG--
extra : moz-landing-system : lando
This change will bring us on par with what Chrome does. However, if the author makes an error in applying a landmark role to an interactive element, or other element where the landmark role is illegal, as defined in the [WAI-ARIA in HTML specification section 2](https://www.w3.org/TR/html-aria/#document-conformance-requirements-for-use-of-aria-attributes-in-html), the accessible properties will now be that of the landmark role, no longer that of the native host language element. This might make some elements less accessible due to author error than before, but we currently do not know of examples in the wild that actually expose this problem. This could only be solved by applying the rules from said table also in the user agents, but that is not specified anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D41923
--HG--
extra : moz-landing-system : lando
For accessibility, the address bar is now exposed as a parent combo box which contains the input and the results list.
The combo box role on urlbarView-body-inner is no longer needed and has therefore been removed.
This means screen readers no longer report an extraneous combo box whenever the results list is opened.
Differential Revision: https://phabricator.services.mozilla.com/D40917
--HG--
extra : moz-landing-system : lando
All .xul files have been loading as HTMLDocuments for a few weeks now, so
it should be safe to remove the XULDocument implementation.
Differential Revision: https://phabricator.services.mozilla.com/D41238
--HG--
extra : moz-landing-system : lando
Removing an Accessible removes descendants in the a11y tree.
However, there may be DOM descendants which have been relocated elsewhere in the a11y tree.
Their DOM nodes are now hidden as well, so we need to remove those Accessibles too.
In addition to Accessibles remaining in the tree when they shouldn't, failing to remove relocated Accessibles caused problems later on when a relocated Accessible was shown with new descendants.
Differential Revision: https://phabricator.services.mozilla.com/D41178
--HG--
extra : moz-landing-system : lando
We need to visit the descendants of a container that has no accessible,
but has accessible children.
Also added a test for delayed removal where we can put all these nasty
cases.
Differential Revision: https://phabricator.services.mozilla.com/D41059
--HG--
extra : moz-landing-system : lando
For accessibility, the address bar is now exposed as a parent combo box which contains the input and the results list.
The combo box role on urlbarView-body-inner is no longer needed and has therefore been removed.
This means screen readers no longer report an extraneous combo box whenever the results list is opened.
Differential Revision: https://phabricator.services.mozilla.com/D40917
--HG--
extra : moz-landing-system : lando
The current test doesn't actually do anything because divs with IDs are
always created.
Differential Revision: https://phabricator.services.mozilla.com/D40674
--HG--
extra : moz-landing-system : lando
Previously, if a hidden, aria-owned subtree was shown and aria-activedescendant was simultaneously targeted inside it, aria-activedescendant would fail.
This occurred because when we processed insertions, the presence of aria-owns meant we didn't create the subtree.
This meant that when we processed aria-activedescendant (which occurred before relocations), the active descendant didn't exist yet.
To fix this, we now process generic notifications (including aria-activedescendant) *after* relocations.
Differential Revision: https://phabricator.services.mozilla.com/D40579
--HG--
extra : moz-landing-system : lando
Converts accessibility.AOM.enabled to static pref and removes the related mirror variable and static flag used to initially generate the varcache pref
Differential Revision: https://phabricator.services.mozilla.com/D40101
--HG--
extra : moz-landing-system : lando
Also reworked test_recreation.html to test/demo how these ergonomics
would work.
Differential Revision: https://phabricator.services.mozilla.com/D40124
--HG--
rename : accessible/tests/browser/events.js => accessible/tests/mochitest/promisified-events.js
extra : moz-landing-system : lando
We naively remove and then recreate accessibles when their content's
frame is reconstructed. By delaying the removal until we are certain the
content does not have a new layout frame, we can cut down on redundant
recreations.
When reconstructed content is re-inserted we can check it and its
subtree for missing frames and prune those accessibles from the tree.
Differential Revision: https://phabricator.services.mozilla.com/D38380
--HG--
extra : moz-landing-system : lando
This is the first step in making it possible to return remote WindowProxy
objects from window.open() and related APIs.
This patch also incidentally fixes a bug where getContentWindowOrOpenURI
returned the top-level browser window rather than the new content window when
passed OPEN_NEWWINDOW for the `aWhere` parameter. This was not the expected
behavior, and was a potentially major footgun for any new users who expected
to always get the content window for the URL they were loading, rather than
sometimes getting a chrome browser window instead.
For now, that case just returns null, which is only a minor footgun, rather
than the major one we had before.
Differential Revision: https://phabricator.services.mozilla.com/D35688
--HG--
extra : moz-landing-system : lando
Editor creates a `<br>` element when it's root element is empty.
Then, it's stored by `TextEditRules::mBogusNode` and used for checking
whether the editor is empty quickly. However, this `<br>` element has
`mozeditorbogusnode` attribute whose value is `true`. However, adding or
removing the attribute is not cheap and web apps can refer such illegal
attribute.
Therefore, this patch makes `HTMLBRElement` take a specific flag whether
it's a bogus node or not. However, this means that this hacky thing will be
exposed outside editor module. For making what is the bogus node clearer,
this patch calls the such `<br>` elements as "padding `<br>` element for
empty editor". So, this patch also includes a lot of renaming methods and
variables, and modifying related comments.
Differential Revision: https://phabricator.services.mozilla.com/D39857
--HG--
extra : moz-landing-system : lando
Normally, the OuterDocAccessible is created first and the DocAccessibleParent for a remote document is created after that.
So, we get the OuterDocAccessible and call DocAccessibleParent::SendParentCOMProxy when the DocAccessibleParent is constructed (BrowserParent::RecvPDocAccessibleConstructor).
However, sometimes, the OuterDocAccessible is created *after* the DocAccessibleParent.
This sometimes happens for extension popups, for example.
In that case, we previously never sent the parent COM proxy.
Aside from leaving the remote document with a null parent, this also meant we never sent any events for the document, since events are buffered for remote documents until the parent COM proxy is received.
This effectively left the remote document (e.g. extension popup) inaccessible.
Now, we also call SendParentCOMProxy in the OuterDocAccessible constructor.
Note that this doesn't result in duplicates because if the OuterDocAccessible was created first, there won't be a DocAccessibleParent for the remote document yet, so this code won't run.
That said, if the OuterDocAccessible is recreated (e.g. due to frame reconstruction), we may call SendParentCOMProxy again.
This should be okay, but it required an assertion in DocAccessibleChild::RecvParentCOMProxy to be tweaked.
Differential Revision: https://phabricator.services.mozilla.com/D40358
--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
It seems a bit more sensible to me that if any filtering needs to happen
from content insertions, it should happen in the doc and not the
notification controller.
Differential Revision: https://phabricator.services.mozilla.com/D40132
--HG--
extra : moz-landing-system : lando
In FocusManager::ProcessFocusEvent, after firing the event, we get the anchor jump from the target Accessible's document.
However, it seems the Accessible can be shut down during the call to nsEventShell::FireEvent, resulting in a crash when we try to get the anchor jump.
Protect against this by checking whether the target is defunct after firing the event.
Differential Revision: https://phabricator.services.mozilla.com/D39450
--HG--
extra : moz-landing-system : lando
Previously, we would always calculate the name for tr elements from their descendants unconditionally. Assistive technologies aren't using this information, moreover, it causes problems if the name gets too long, for example in layout tables.
We now only calculate the name if the tr element has an explicit ARIA role.
Differential Revision: https://phabricator.services.mozilla.com/D39314
--HG--
extra : moz-landing-system : lando
This was an oversight in the checkin for bug 1461244. tfoot was duplicated due to a copy and paste error, thead was not mapped at all. It is now properly mapped, and the test adjusted accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D39305
--HG--
extra : moz-landing-system : lando
Previously, the target element for aria-activedescendant was retrieved by calling GetElementById on the owner document.
This meant that aria-activedescendant inside shadow DOM looked for ids in the owner document instead of the shadow DOM.
To fix this, use IDRefsIterator::GetElem instead.
Differential Revision: https://phabricator.services.mozilla.com/D38833
--HG--
extra : moz-landing-system : lando
IDRefsIterator::GetElem was previously an instance method which could only be used if you instantiated IDRefsIterator.
This is overkill for attributes which can only take a single id reference (rather than an id reference list).
Now, there is a static version of IDRefsIterator::GetElem which can be called with an arbitrary source element.
Any accessibility code should henceforth be using this instead of calling GetElementById directly, as this deals with shadow DOM, etc.
Differential Revision: https://phabricator.services.mozilla.com/D38832
--HG--
extra : moz-landing-system : lando
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
In bug 1525101, autocomplete-richlistbox-popup was converted to a Custom Element.
This means we can no longer use do_QueryInterface to get nsIAutoCompletePopup.
Instead, we must use Element::AsAutoCompletePopup.
This fixes accessibility focus for these autocompletes.
Differential Revision: https://phabricator.services.mozilla.com/D38158
--HG--
extra : moz-landing-system : lando
OuterDocAccessible can return a DocProxyAccessibleWrap or RemoteIframeDocProxyAccessibleWrap as a child.
Accessible::ChildAtPoint on an ancestor might retrieve this proxy and call Bounds() on it.
This will crash on a proxy, so we override it on these document proxies to do nothing.
Differential Revision: https://phabricator.services.mozilla.com/D38256
--HG--
extra : moz-landing-system : lando
Even though a11y DLLs are not strictly "DLL blocking," I felt that it would
make sense to include them in our unified DLL blocklist. This patch delegates
much of that functionality to the unified blocklist code. Going forward, any
further blocklist entries for in-proc a11y DLLs should be added to
mozglue/build/WindowsDllBlocklistDefs.in via the A11yBlocklistEntry type.
Differential Revision: https://phabricator.services.mozilla.com/D37001
--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
386947-1.xul, now has one assertion since we take a different code
path with chrome URL's and XBL files. The assertion is triggered since the
binding is invalid.
Differential Revision: https://phabricator.services.mozilla.com/D34542
--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
`NS_FRAME_IS_DIRTY` being set on a frame has always meant that that
frame and all of its descendants need to be reflowed. What the main
patch on this bug is changing is when it gets propagated to descendants;
prior to that patch it gets propagated during reflow, whereas after the
patch it gets propagated when the bit is set. This means that
`NS_FRAME_IS_DIRTY` is now (after the patch) a somewhat more reliable
indicator of whether a frame requires reflow than it was before.
However, this has a strange interaction with the particular sequence of
operations that test_list.html performs. In particular, test_list.html:
(1) makes a style change that requires reflow,
(2) flushes style (but not layout), and
(3) gets the name of an accessible whose layout was dirtied by the style change.
Getting this name ends up here:
```
nsTextFrame::GetRenderedText at layout/generic/nsTextFrame.cpp:9600
nsTextEquivUtils::AppendTextEquivFromTextContent at accessible/base/nsTextEquivUtils.cpp:127
nsTextEquivUtils::AppendFromAccessible at accessible/base/nsTextEquivUtils.cpp:174
nsTextEquivUtils::AppendFromAccessibleChildren at accessible/base/nsTextEquivUtils.cpp:162
nsTextEquivUtils::GetNameFromSubtree at accessible/base/nsTextEquivUtils.cpp:39
mozilla::a11y::Accessible::NativeName at accessible/generic/Accessible.cpp:1991
mozilla::a11y::HyperTextAccessible::NativeName at accessible/generic/HyperTextAccessible.cpp:1760
mozilla::a11y::Accessible::Name at accessible/generic/Accessible.cpp:149
mozilla::a11y::xpcAccessible::GetName at accessible/xpcom/xpcAccessible.cpp:245
NS_InvokeByIndex at xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:106
```
What the main patch in the bug has changed is whether this `nsTextFrame`
has the `NS_FRAME_IS_DIRTY` bit set at this point. This means that
`GetRenderedText` will bail out without reporting the text, because the
frame is marked dirty.
On the assumption that this action -- getting accessible names while
frames are dirty -- is an artificial situation set up in the test and
not a real-world situation that we need to care about, I'm proposing
that we make the straightforward adjustment to the test: flush layout
in addition to flushing style at step (2) above, so that the test works
again. As long as that assumption is correct, I think this should be
fine. (I'd note that this is the *only* test that breaks as a result of
the patch.)
If, on the other hand, we actually do care about what accessible names
return while layout state is dirty and reflow is needed, we should
probably improve `nsTextFrame::GetRenderedText` so that it can somehow
report useful state even when `NS_FRAME_IS_DIRTY` is set, or something
else more complicated.
Differential Revision: https://phabricator.services.mozilla.com/D36423
--HG--
extra : moz-landing-system : lando
The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
extra : intermediate-source : a5c6deeda8a9475ac0268a4351417c8ff659c962
extra : histedit_source : 5eb8b3d14027f2aeca5c52534096837cd0343104%2Ca23a07ddd5e1fb8bd084644dd6db0ee028b7c4b4
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : source : f4e21e465f384b90fa1e768141c4db708748bf66
extra : histedit_source : 95d8a4242e8e04df9e29c2b647558d37e910b845
The conversion for "regular" <tabs> elements is straightforward, most of
the work here is to support the tab strip (the <tabs> element with the id
"tabbrowser-tabs"). The markup needed for the tab strip moves directly
into browser.xhtml and the construction/teardown logic is now explicitly
driven from gBrowser. There are many more little tweaks too numerous to
enumerate.
Differential Revision: https://phabricator.services.mozilla.com/D32855
--HG--
rename : browser/base/content/tabbrowser.xml => browser/base/content/tabbrowser-tabs.js
extra : rebase_source : 6b2b0ed9b01958d1b2db605ab300c4bebcaa461c
extra : source : c163881a80c9a032b40f7d965fad6a6850fcf8a4
A bunch of existing code assumes that <tab> elements are the immediate
and only children of a <tabs> element, and uses dom apis to traverse
relationships between these elements. To simplify conversion of <tabs>
to a custom element (and hopefully improve readability a bit at the same
time!), introduce new apis:
On <tab>
this.parentNode -> this.container
this.nextElementSibling -> this.container.findNextTab(...)
this.previousElementSibiling -> this.container.findNextTab(...)
On <tabs>
this.children -> this.allTabs
Differential Revision: https://phabricator.services.mozilla.com/D34648
--HG--
extra : rebase_source : affeda0295a5195124709f322de524aea3a28a3f
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
When a client wants to fetch all accessible children, the COM handler uses handlerProvider::get_AllChildren in the content process to optimize cross-process retrieval of all children.
This works fine for iframes rendered in the same content process, just as it does for other accessibles.
However, for out-of-process iframes, HandlerProvider::get_AllChildren will fail.
This is because we only send down an IDispatch COM proxy for the embedded document, but get_AllChildren will try to QueryInterface this to IAccessible2 to reduce QI calls from the parent process.
Because the content process is sandboxed, it can't make the outgoing COM call to QI the proxy from IDispatch to IAccessible2 and so it fails.
Since an iframe only has one child anyway, we don't need the bulk fetch optimization offered by HandlerChildEnumerator or even IEnumVARIANT.
Therefore, we explicitly tell the client this interface is not supported, which will cause the oleacc AccessibleChildren function to fall back to accChild.
Differential Revision: https://phabricator.services.mozilla.com/D34494
--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
The correct mapping for nsIAccessibleEvent::EVENT_TEXT_SELECTION_CHANGED
in ATK is text_selection_changed; not selection_changed. The latter is
meant for containers which support selection of child objects, such as
a menu or expanded select element.
Differential Revision: https://phabricator.services.mozilla.com/D34521
--HG--
extra : moz-landing-system : lando
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
The previous commit removed the dependence on the discriminant value, so we
don't need to keep discriminants different from text-align anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29361
--HG--
extra : moz-landing-system : lando
`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
We're going to stop propagating these flushes up since they're not observable by
content and it matches what would happen in a fission world.
This test relies on the parent document layout tree being up-to-date by the time
we run the iframe load handler. Also improve diagnostics in the case the
assertion fails.
Differential Revision: https://phabricator.services.mozilla.com/D28300
