This is an extension of the fix in bug 1775684.
In that fix, I tweaked NativeInteractiveState to ignore visibility when calling nsIFrame::IsFocusable, since otherwise, an invisible document would report that nothing was focused.
That works well if an Accessible would be created for other reasons; e.g. because it has a meaningful role.
However, if an element has no semantic value except for its focusability (e.g. <span tabindex="-1">), we were failing to create an Accessible for it altogether.
Now, we also ignore visibility when checking focusability in nsAccessibilityService::MustBeAccessible.
This means that we do create an Accessible in this case.
We don't need a caching check here because we should always create an Accessible in this case, even if the document is initially invisible.
Differential Revision: https://phabricator.services.mozilla.com/D173245
This revision modifies the logic in CreateAccessible such that we create
Accessibles for elements that have ARIA roles (other than presentation, none) or
other ARIA attributes, even if those elements have the display: contents style.
This revision also adds tests to verify the above.
Differential Revision: https://phabricator.services.mozilla.com/D170718
Otherwise, semantics are exposed (e.g. for a table), which completely defeats the author's intent that this be treated as presentational.
Differential Revision: https://phabricator.services.mozilla.com/D170165
Otherwise, semantics are exposed (e.g. for a table), which completely defeats the author's intent that this be treated as presentational.
Differential Revision: https://phabricator.services.mozilla.com/D170165
We only use these notifications from layout to push cache updates or insert Accessibles that were skipped during the initial build.
If the DocAccessible doesn't exist yet, creating it is pointless since we can't do this update until the tree is built.
The correct data will be included in the initial tree and cache push anyway.
Aside from pointless refresh ticks, this really shouldn't make any difference, since we don't build the initial tree until layout is ready anyway.
However, the only remotely relevant thing I can think of that's changed in the a11y code lately that might have caused a spike in these test failures is that bounds notifications might get fired earlier/more often from layout, potentially causing earlier creation of DocAccessibles.
Any change to timing might cause a shift in intermittent failures, and since this is wasteful anyway, we may as well fix it.
Differential Revision: https://phabricator.services.mozilla.com/D168911
We need to know about position: fixed in the parent process a11y cache, so we always need an Accessible for such elements.
We don't cache the fact that something is position: sticky, but we need the Accessible so that it can be notified about bounds updates when it moves within its container.
Previously, we calculated bounds incorrectly if a position: fixed/sticky element wasn't included in the a11y tree.
Differential Revision: https://phabricator.services.mozilla.com/D168916
This revision changes the logic of MustCreateAccessible such that we always create
an accessible if the content's frame has been transformed and it has children.
This ensures that we have accessibles to which we apply transforms when
calculating accessible bounds. This revision also adds tests to verify that the
accessible is created, even when the element has role="none", both initially and
as a result of an on-the-fly style change.
Differential Revision: https://phabricator.services.mozilla.com/D167760
This revision changes the logic of MustCreateAccessible such that we always create
an accessible if the content's frame has been transformed. This ensures that we
have accessibles to which we apply transforms when calculating accessible bounds.
This revision also adds a test to verify that the accessible is created, even
when the element has role="presentation".
Differential Revision: https://phabricator.services.mozilla.com/D167760
There is an issue that when the element is hidden because its ancestor has 'content-visibility:hidden', it still appears in the accessibility tree.
Depending on CSS Containment Spec (https://www.w3.org/TR/css-contain-2/#cv-a11y),
it should be omitted from the accessibility tree.
This change fixes the issue above.
The approach is not to create the node in accessibility tree if the element has any ancestor specified with 'content-visibility:hidden'.
This patch can be tested such as:
(1) Check if the accessibility tree is created correctly
./mach test accessible/tests/browser/tree/browser_css_content_visibility.js
(2) Check if the accessibility tree is updated correctly
./mach test accessible/tests/browser/e10s/browser_treeupdate_csscontentvisibility.js
Differential Revision: https://phabricator.services.mozilla.com/D159879
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
Move most the event handling stuff to the DOM. I've left nsMenuBarFrame
for now, but I will be removing that in the future.
The basic set up is:
* nsMenuParent becomes XULMenuParentElement (menubar or popup, manages
the current active menu item)
* nsMenuFrame -> XULButtonElements that return true for IsMenu().
Can't use XULMenuElement because of <button type=menu>, which
behaves like a, well, menu.
This makes the a11y events for menus (DOMMenuItem{Active,Inactive}) make
sense (before that we were firing duplicate Inactive events etc, and the
event order was rather suspicious).
Differential Revision: https://phabricator.services.mozilla.com/D164210
Certain MathML elements such as annotation and annotation-xml don't normally get an Accessible.
However, we force create Accessibles in some cases; e.g. if the element is focusable.
When this happens for these MathML elements (e.g. annotation-xml with a tabindex), we previously created AccessibleWraps which don't support text.
This meant that text formatting information was unavailable and caused assertions when pushing the cache.
To fix this, use HyperTextAccessibleWrap instead.
As a drive-by fix, also use HyperTextAccessibleWrap instead of HyperTextAccessible for content MathML elements.
This was almost certainly a typo when this was implemented.
This wouldn't have been noticeable in tests and some native platforms, but some platforms (e.g. Mac and Windows) do have some overrides in HyperTextAccessibleWrap, so we should use those.
Differential Revision: https://phabricator.services.mozilla.com/D165252
These can contain <foreignobject>, which contains HTML but does not normally create its own Accessible.
This means that these Accessibles could have TextLeafAccessible children.
TextLeafAccessible children must always have a HyperTextAccessible as a parent.
Therefore, we must use HyperTextAccessible for <svg> and <g>.
As well as fixing assertions, this allows text formatting to be queried for <foreignobject> content, which was previously broken.
Differential Revision: https://phabricator.services.mozilla.com/D164636
After bug 1779156, show events were fired from RecvCache, rather than from RecvShowEvent.
This was done to ensure that cache data was available when the event was fired.
However, because RecvCache fired a show event for every initial cache push, this meant that it also fired one for the document itself, plus all the document's initial direct children.
Firing an event for the document caused problems for ATK, since the parent was null for all top level documents.
This also meant we were firing a lot of unnecessary show events, which could be a performance problem for documents with a lot of initial direct children.
To fix this, provide an explicit argument to PDocAccessible::Cache specifying whether to dispatch a show event or not.
This replaces the existing aFinal argument, which was never used.
Differential Revision: https://phabricator.services.mozilla.com/D163192
The button tweak is needed because now if you have:
<button>
<label value="foo">
</button>
There is a text node for the value (generated content), and the <button>
shouldn't steal it.
I was getting crashes without it because XULButtonAccessible isn't
hypertext (so I wonder if the IsText() code-path can even be reached?).
Same issue with XULComboboxAccessible, fixed the same way by preventing
text there (preserving behavior).
Setting crop="center" now reframes, so test_label needs to change.
Differential Revision: https://phabricator.services.mozilla.com/D162011
This revision changes the logic for creation and updating of accessibles
corresponding to elements that produce image accessibles, such that alt=""
(without click listeners or any other aria attributes that force an accessible)
will effectively remove that element's accessible from the accessibility tree.
Next, this revision removes the concept of eNoNameOnPurpose from accessible name
handling, since it's now unnecessary now that alt="" means "don't create an
accessible" in most cases. This revision also adds tests to verify the
functionality and updates existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D160706
This revision changes the logic for creation and updating of accessibles
corresponding to img elements such that alt="" (without click listeners or any
other aria attribute that forces an accessible) will effectively remove that
img's accessible from the accessibility tree. Next, this revision removes the
concept of eNoNameOnPurpose from accessible name handling, since it's now
unnecessary now that alt="" means "don't create an accessible" in most cases.
This revision also adds tests to verify the functionality and updates existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D160706
DocAccessible::GetAccessible() won't return the document if a root element
like body is passed. We need to check for that in NotifyOfPossibleBoundsChange
and use the document accessible in that case.
We can't modify GetAccessible() because that is not that method is used
extensively and that is not the expected behavior.
Differential Revision: https://phabricator.services.mozilla.com/D160677
Previously, we were inconsistent in what we treated as a table row in various places.
This caused breakage after bug 1726124, since nsAccUtils::TableFor() started returning a table when an ARIA row had an invalid parent, but Filters::GetRow wouldn't find such a row
This was causing broken expectations (and consequently, an extremely long loop) in TableCellAccessible::PrevColHeader.
To fix this, avoid creating an ARIARowAccessible (and thus ARIAGridCellAccessibles) if the row's parent isn't valid.
This way, there aren't conflicting expectations because the TableCellAccessible code can never run.
Furthermore, clients don't get a broken table cell interface on invalid cells, which was a problem even before bug 1726124.
Differential Revision: https://phabricator.services.mozilla.com/D159679
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
Gijs for front-end bits, layout for the new CSS properties and the
removal of nsDeckFrame / nsStackLayout, Jamie and Morgan for the a11y
changes.
As discussed in the bug, the main tricky part here is handling a11y
correctly. For <deck>, that's trivial (just use `visibility: hidden` to
hide the panels visually, while removing the unselected panels from the
a11y tree).
For <tabpanels> however we need to do something special. We do want to
hide stuff visually, but we want to preserve the contents in the a11y
tree.
For that, the easiest fix is introducing a new privileged CSS property
(-moz-subtree-hidden-only-visually), which takes care of not painting
the frame, but marks stuff offscreen in the accessibility tree. This is
not intended to be a property used widely.
Other than that, the changes are relatively straight-forward, though
some of the accessible/mac changes I could get a sanity-check on.
Differential Revision: https://phabricator.services.mozilla.com/D157875
I don't understand why we don't allow any box through, but for now this
is a safer change to restore the previous behavior when emulated flex
box is used.
Differential Revision: https://phabricator.services.mozilla.com/D158002
Some markup elements expose Accessible attributes which must be retrieved from DOM; e.g. the datetime attribute of the datetime element.
We don't cache these yet for RemoteAccessible.
Previously, these were unintentionally exposed from MarkupAttributes with null values.
For now, these should be skipped instead until we have caching code for them.
This fixes crashes whenever a client tries to fetch attributes from such an element.
Differential Revision: https://phabricator.services.mozilla.com/D151659
RemoteAccessibleBase::Attributes will soon use the service to query markup attributes.
Thus, the service must not shut down while a client call is being handled on the UI thread.
Differential Revision: https://phabricator.services.mozilla.com/D150722
