When content analysis is on, pastes will be checked by the CA
agent while tab input is blocked. The synchronous nsIClipboard.getData()
method must block until the analysis result is received, so this
requires doing a SpinEventLoopUntil.
Differential Revision: https://phabricator.services.mozilla.com/D196997
Even when there is a valid popovertarget, per the spec, these relations must not be exposed in certain cases.
This requires some special case code.
The code for calculating the DETAILS relation for popover invokers has been encapsulated in its own function.
We also use this to validate the reverse DETAILS_FOR relation on popovers.
Normally, when pushing cached relations to the parent process, we use IDRefsIterator so that we don't push implicit reverse relations.
For popover invokers, this wouldn't validate the other conditions.
To avoid duplicate special case code in RemoteAccessible, we use RelationByType for the DETAILS relation instead of IDRefsIterator when pushing the cache.
This leverages the LocalAccessible special case code for popover invokers.
This is fine for the DETAILS relation because nothing ever exposes an implicit reverse DETAILS relation.
Differential Revision: https://phabricator.services.mozilla.com/D199954
A popover can have multiple invoker buttons.
Previously, we only fired a state change event on the button which was invoked.
This meant that the cached expanded/collapsed state of any other invokers was stale.
To facilitate this:
1. Add popovertarget to DocAccessible's kRelationAttrs so that we track reverse relationships. This will also later be used for exposing relations.
2. When an Accessible is shown or hidden, if it is a popover, use RelatedAccIterator to get all the invokers and fire appropriate state change events on each of them.
3. This also means we can get rid of nsAccessibilityService::PopovertargetMaybeChanged, since this explicit notification from DOM is no longer useful.
4. Add popovertarget to LocalAccessible::AttributeChangesState so that we fire an event for the expandable/expanded/collapsed state change if appropriate when that attribute is changed.
Differential Revision: https://phabricator.services.mozilla.com/D199842
This revision adds role mappings for the 'time' ARIA role by implementing HTML
markup mapping, adding platform mappings, and adding the role info itself. This
revision also enables the previously-failed wpt tests and fixes other tests.
Differential Revision: https://phabricator.services.mozilla.com/D200132
This revision implements mapping for the ARIA 1.2 'strong' role by adding a
markup mapping, a role definition, and platform mappings. This revision also
removes the expected failures in the wpt test suite and fixes other tests.
Differential Revision: https://phabricator.services.mozilla.com/D200131
This revision implements the mapping for the ARIA 1.2 emphasis role, which was
unsupported in Firefox until now. This change addresses a web platform test
failure. To accomplish this, the revision adds the WAI-defined role, adds a role
enum value, adds platform mappings, and adds a markup role mapping. The change
requires a new static atom for the word "emphasis," also added in this revision.
Finally, this change removes the expected wpt failure and updates other tests.
Differential Revision: https://phabricator.services.mozilla.com/D200130
This revision adds role mappings for the 'time' ARIA role by implementing HTML
markup mapping, adding platform mappings, and adding the role info itself. This
revision also enables the previously-failed wpt tests and fixes other tests.
Differential Revision: https://phabricator.services.mozilla.com/D200132
This revision implements mapping for the ARIA 1.2 'strong' role by adding a
markup mapping, a role definition, and platform mappings. This revision also
removes the expected failures in the wpt test suite and fixes other tests.
Differential Revision: https://phabricator.services.mozilla.com/D200131
This revision implements the mapping for the ARIA 1.2 emphasis role, which was
unsupported in Firefox until now. This change addresses a web platform test
failure. To accomplish this, the revision adds the WAI-defined role, adds a role
enum value, adds platform mappings, and adds a markup role mapping. The change
requires a new static atom for the word "emphasis," also added in this revision.
Finally, this change removes the expected wpt failure and updates other tests.
Differential Revision: https://phabricator.services.mozilla.com/D200130
This revision aims to add support for the 'term' and 'definition' ARIA roles.
These roles already exist in Gecko, but aren't fully mapped where they should
be. To address the problem, this revision adds a static atom for "definition,"
implements the ARIA map for definition, adds a markup map entry for the dfn
element (which has the DEFINITION role), and puts the term and definition atoms
in the role map. As a consequence of these changes, this revision also removes
the expected web platform test failures and updates other existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D200219
While bug 1861671 improved menupopup styling to closer match modern macOS, there were still several discrepancies between native and non-native menu metrics. The following adjustments were made in this patch to match native styles:
- Don't render the checkmark containers for menus with no checked or checkable items
- Adjusted various spacings to match native metrics
- Apply padding to the accelerator container only if an accelerator is present
- Fixed regression from bug 1861671 resulting in menuitems being misaligned with sub-menus
These changes result in non-native menupopups appearing nearly indistinguishable from native menus.
Differential Revision: https://phabricator.services.mozilla.com/D199787
`searchbar-search-button` includes two `<image>` elements, one of which is aimed to visually communicate that this `overlay` image could expand/collapse the search autosuggest list. This `<hbox>` that has an accessible name but lacks an appropriate interactive role and state, because it functions as a button (not focusable with keyboard because the alternative - `Escape` key - exists and works to collapse the autosuggest list and we do not want to create an additional tab stop for keyboard-only users). This would prevent users of speech-to-text/Voice Control from being able to send a click to it by calling its label and screen reader users and users of other assistive technology would not be able to get to this control via shortcuts like a list of controls, etc.
This issue is similar to the `Go` button on the URL bar resolved in the bug 1864962 and to the `Submit search` button tracked in bug 1871596
To activate the searchbar next to the URL Bar that includes this go button: `about:preferences` > `Search` > `Search Bar` > select `Add search bar in toolbar`.
Depends on D199504
Differential Revision: https://phabricator.services.mozilla.com/D197335
This would allow browser test like `accessible/tests/browser/tree/browser_searchbar.js` to test accessible roles in the Accessibility tree for buttons with `aria-haspopup` attributes.
Depends on D199394
Differential Revision: https://phabricator.services.mozilla.com/D199504
Extend a bit the test for dynamic changes to content-visibility, adding
the following checks:
* If there are text descendants in the content-visibility subtree,
make sure they are created when switching to auto ; and removed
when switching back to hidden.
* If there is a content-visibility: hidden or a visibility: hidden
descendant, make sure pruning still applies when switching to
auto.
* If there is a shadow host in the content-visibility subtree,
make sure that shadow subtree is properly updated when
content-visibility changes.
Differential Revision: https://phabricator.services.mozilla.com/D196964
setBoolPref has a persistent effect for the rest of the test run (potentially
affecting the behavior of other prefs), so we don't want to use
that. This test is currently failing when run in test-verify mode as a result
of this. With pushPrefEnv, the test will properly undo its pref-modification
when it completes.
Note: I'm moving the pref-toggle statement inside of a function so that I can
use the ergonomic `await` syntax. This is still essentially right at the start
of the test, since `doTests` is the main function here.
Differential Revision: https://phabricator.services.mozilla.com/D197830
We don't normally create an Accessible for <foreignObject>.
However, if there's an ARIA role or similar, we forceably create one.
Previously, if we ever did this for an SVG element, we would use an AccessibleWrap, which doesn't support HyperText.
This is normally correct because most SVG elements can't contain text.
However, a <foreignObject> can most definitely contain text, so we must use HyperTextAccessible.
This fixes assertions and text attributes.
Differential Revision: https://phabricator.services.mozilla.com/D195387
Previously, this incorrectly returned the row in the column field, the column in the row field, and the column span for both the row and column spans.
Differential Revision: https://phabricator.services.mozilla.com/D192912
This adds setup code and utility functions for ATK to the Python environment.
I also needed to prevent front-end accessibility checks (AccessibilityUtils) from force disabling accessibility for a11y engine tests.
Although the tests re-enabled it anyway, this seems to break AT-SPI's interaction with our ApplicationAccessible.
Disabling it really doesn't make sense in this case anyway.
This patch includes a simple role test to show all of this working.
Differential Revision: https://phabricator.services.mozilla.com/D192911
An image or image map can't contain text, so it doesn't make sense to walk the lines of any children.
Previously, for normal images (not image maps), we would find no children and thus return false because there were no children containing the point, thus breaking hit testing for images.
For image maps, hit testing would fail for any points that weren't covered by areas.
Now, we don't walk children in these cases, instead just using the element's rect.
We apply this same rule for other inline elements without children, since there are no children to walk in that case and we should use the rect there rather than always returning false.
I don't know if this last case is something that ever happens in practice, but I figured it was best to handle it just in case.
Differential Revision: https://phabricator.services.mozilla.com/D193509
1. Never treat a cell in a nested CachedTableAccessible as a cell in the outer table. This could previously result in trying to use cache data from one CachedTableAccessible when querying another, which could cause crashes.
2. Don't create an HTMLTableRowAccessible when the <tr> has a valid ARIA role other than "row". This could previously result in a situation where <tr role="grid"> was treated as a row by its parent table, but the <tr> was also treated as a separate table.
Differential Revision: https://phabricator.services.mozilla.com/D192175
Normally, XUL toolbarbutton elements are labelled using the label attribute or a child label element.
However, there are some instances such as in the Synced Tabs menu where a toolbarbutton contains only a text leaf.
Previously, these buttons exposed no label to accessibility APIs.
To fix this, we now allow a text leaf child in the accessibility tree.
We already supported this for XUL button elements.
Also, there was a bunch of existing common code in IsAcceptableChild for XULToolbarbuttonAccessible and XULButtonAccessible and the former subclasses the latter.
Therefore, XULToolbarbuttonAccessible::IsAcceptableChild has been refactored to call the base class method, adding an additional check specific to toolbarbuttons.
Differential Revision: https://phabricator.services.mozilla.com/D191713
A file input contains two native anonymous children: the Browse button and the file name label.
Previously, we exposed the file input as a group in the a11y tree and its anonymous children as children of that group.
While this is semantically correct, it causes several problems for screen readers.
First, if the author provides a label or description, that gets exposed on the group.
Some screen readers ignore either one or the other depending on the screen reader, what the author specified and how the user navigated there.
Second, the file name label isn't focusable and wasn't associated to the group in any way aside from being a child.
This meant that a screen reader user might not perceive it in some cases.
Since most users understand a file input as a single control anyway, we now just expose the input as a simple button containing two text leaves.
However, unlike most buttons, we need to append the text to the name even if the author specifies a name.
As a bonus, this simplifies some code, since we no longer need to redirect focus or events.
An additional problem was that the file input previously returned false for LocalAccessible::IsWidget, which meant that a wrapping HTML label wasn't associated correctly.
This has been fixed as well, although this fix could have applied just as easily to the previous group implementation.
Differential Revision: https://phabricator.services.mozilla.com/D191264
This is necessary to work around a bug in the Windows UI Automation -> IAccessible2 proxy.
See the code comments for details.
Differential Revision: https://phabricator.services.mozilla.com/D187529
James Teh
Greg Stoll
Nathan LaPre
Iulian Moraru
Sam Johnson
Anna Yeddi
Tom Marble
Sandor Molnar
Tom Schuster
Eitan Isaacson
Frédéric Wang
Daniel Holbert
Emilio Cobos Álvarez
Ziran Sun
Joel Maher
Butkovits Atila
Morgan Rae Reschenberg
Mike Hommey
Mark Banner
Marc Seibert