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
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
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
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
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
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
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
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