This revision implements the HTML-AAM spec's rules for role mapping of the aside
element. The aside element might be either 'complementary' or 'generic'
depending on the ancestor and presence of accessible name. This revision
implements these rules via a new class, HTMLAsideAccessible, which has a
NativeRole override. This revision also updates the HTMLMarkupMap to map HTML
aside elements to HTMLAsideAccessible. Finally, this revision removes related
expected failures from web platform tests.
Differential Revision: https://phabricator.services.mozilla.com/D203192
This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
This revision adds a Gecko GRID role, matching the ARIA 'grid' role, and
implements its platform mappings. It then remaps the ARIA 'grid' role to the
Gecko GRID role. Finally, this revision removes the expected-fail for the
relevant formerly-failing web platform test and updates existing tests.
Differential Revision: https://phabricator.services.mozilla.com/D202040
Accessibility needs to keep track of changes to explicitly set attr-elements.
Since the popovertarget content attribute is "" for any explicitly set attr-element, we won't always get attribute change notifications for the content attribute when .popoverTargetElement is set.
For example, if e1's popovertarget content attribute is absent and you set e1.popoverTargetElement to e2, the popovertarget content attribute will be "".
If you later set e1.popoverTargetElement to e3, there won't be a notification for the content attribute change, since it remains "".
Even if there were, it might occur before the element has changed, which means we can't detect any relevant state changes there; e.g. mPrevStateBits.
To deal with this, we now have DOM notify accessibility before and after the explicitly set attr-element is changed.
Within DocAccessible, this is treated like any other attribute change, but the notification methods get called consistently and at the appropriate time.
Differential Revision: https://phabricator.services.mozilla.com/D201662
As well as getting an invoker's popover target, we need to be able to do the reverse: get a popover's invokers.
We can already do this when the popovertarget content attribute is set to a string id using the dependent ids map.
However, the popover target can also be explicitly set to a DOM element using the .popoverTargetElement WebIDL attribute.
For this, we need a new map which maps from target elements instead of target ids.
RelatedAccIterator has also been updated to use this map.
DocAccessible::QueueCacheUpdateForDependentRelations had to be updated as well.
Rather than duplicating logic, RelatedAccIterator has been taught how to optionally return all relations and QueueCacheUpdateForDependentRelations now uses RelatedAccIterator.
Differential Revision: https://phabricator.services.mozilla.com/D201661
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 'implements' the 'generic' ARIA role mapping by mapping ARIA
'generic' to Gecko 'section.' This isn't a full implementation of 'generic' - it
sidesteps it to avoid dealing with larger 'generic' issues (namely: that there
are multiple roles that are 'generic' in Gecko currently). We'll sort that out
in a later commit. This revision adds a new web platform test to verify that the
generic role actually overrides an element's implicit role.
Differential Revision: https://phabricator.services.mozilla.com/D200133
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 'implements' the 'generic' ARIA role mapping by mapping ARIA
'generic' to Gecko 'section.' This isn't a full implementation of 'generic' - it
sidesteps it to avoid dealing with larger 'generic' issues (namely: that there
are multiple roles that are 'generic' in Gecko currently). We'll sort that out
in a later commit.
Differential Revision: https://phabricator.services.mozilla.com/D200133
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
It's only used from some crashtests, and it hasn't worked in a long,
long time, due to it not having the right styles in xul.css
Differential Revision: https://phabricator.services.mozilla.com/D200361
Per HTML AAM, HTML hgroup elements should have an implicit role=group instead
of being generics. This revision implements that by mapping hgroup elements to
roles::GROUPING in HTMLMarkupMap. It also removes the expected fail from the
relevant web platform test, which we now pass.
Differential Revision: https://phabricator.services.mozilla.com/D200204
ContentRemoved recursively walks both AllChildrenIterator and direct DOM children.
In addition, we might get duplicate notifications from DOM and layout, plus PruneOrInsertSubtree might do a recursive walk and it too calls ContentRemoved.
To avoid this duplicate processing, keep a set of removed DOM nodes on the DocAccessible which we clear after mutation events are processed.
Differential Revision: https://phabricator.services.mozilla.com/D196707
std::sort used by nsTArray::Sort expects the comparator to be tolerant
for being called to compare the very same element with itself.
Differential Revision: https://phabricator.services.mozilla.com/D195482
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
This is just a "belt-and-suspenders" invariant tightening. Shouldn't impact
behavior at all, assuming that we don't call methods on NotificationController
objects that have been nerfed with Shutdown().
Differential Revision: https://phabricator.services.mozilla.com/D195321
If these assertions somehow fail, then we are probably doomed to crash anyway.
The new release assertions just make it so we'll crash in a controlled way,
with a more actionable backtrace, closer to the problem-spot.
This patch also removes one mDocument null-check that's becoming redundant
since it follows a release-assert that would make us abort if the pointer is
null.
Differential Revision: https://phabricator.services.mozilla.com/D195042
We can sometimes reach the code that this patch is touching, just we've been
shutdown (as can be seen by the fact that we have a null mDocument pointer); in
that case, it's problematic for us to be assigning 'mObservingState' here. The
mObservingState assignment is meant to be *undoing* the temporary assignments
earlier in the function, but in this post-Shutdown situation, it's actually
causing us to forget that we already unregistered as a refresh observer, in a
nested stack level's call to Shutdown().
I think this one place is the only mObservingState assignment that's got this
problem. The other mObservingState assignments should all be OK (they don't
need a "have we shut down" check), because they're all either:
a) modifying mObservingState to record an actual change that we just made to
our RefreshDriver registration,
...or:
b) immediately adjacent to code that dereferences mDocument, implying that
mDocument is known-to-be-non-null at that point, which means we know we haven't
been Shutdown.
This patch unblocks us from adding a release assert in the
NotificationController destructor in the next patch in this series. (Without
this patch, that assertion can be made to fail, via this inadvertent
mObservingState assignment.)
Depends on D195041
Differential Revision: https://phabricator.services.mozilla.com/D195200
This patch is non-functional; it's just adding a debug-only assert, for
documentation and lightweight validation purposes.
As far as I can tell, the asserted condition must hold, since it looks like
this constructor is only invoked via this instantiation of the subclass, which
passes `this` as the aDocument arg (and `this` must trivially be non-null):
https://searchfox.org/mozilla-central/rev/12ea2c521cdd071a6d25b0894f31f8f23b18b76a/accessible/generic/DocAccessible.cpp#422
This assertion makes it easier to reason about the usages of this member-var.
There are lots of checks for whether mDocument is nullptr, and it's useful to
know that it'll always be non-null to begin with (though it becomes null
eventually, as part of teardown, when NotificationController::Shutdown is
called).
Differential Revision: https://phabricator.services.mozilla.com/D195041
If these assertions somehow fail, then we are probably doomed to crash anyway.
The new release assertions just make it so we'll crash in a controlled way,
with a more actionable backtrace, closer to the problem-spot.
This patch also removes one mDocument null-check that's becoming redundant
since it follows a release-assert that would make us abort if the pointer is
null.
Depends on D195041
Differential Revision: https://phabricator.services.mozilla.com/D195042
This patch is non-functional; it's just adding a debug-only assert, for
documentation and lightweight validation purposes.
As far as I can tell, the asserted condition must hold, since it looks like
this constructor is only invoked via this instantiation of the subclass, which
passes `this` as the aDocument arg (and `this` must trivially be non-null):
https://searchfox.org/mozilla-central/rev/12ea2c521cdd071a6d25b0894f31f8f23b18b76a/accessible/generic/DocAccessible.cpp#422
This assertion makes it easier to reason about the usages of this member-var.
There are lots of checks for whether mDocument is nullptr, and it's useful to
know that it'll always be non-null to begin with (though it becomes null
eventually, as part of teardown, when NotificationController::Shutdown is
called).
Depends on D195040
Differential Revision: https://phabricator.services.mozilla.com/D195041
This is needed in order to support find in page on Android using remote caret events instead of virtual cursor change events.
Depends on D192641
Differential Revision: https://phabricator.services.mozilla.com/D192642
This is needed in order to support find in page on Android using remote caret events instead of virtual cursor change events.
Depends on D192641
Differential Revision: https://phabricator.services.mozilla.com/D192642
RelationType.h will soon be generated, but it will be generated within the obj dir, so local includes won't work.
Our C++ style guide says we should prefer exported includes wherever possible anyway.
This was done with this shell command inside the accessible/ directory:
```
sed -i 's,#include "RelationType.h",#include "mozilla/a11y/RelationType.h",' `git grep -l '#include "RelationType.h"'`
```
Differential Revision: https://phabricator.services.mozilla.com/D193001
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
This is a speculative crash fix; I don't know how to reproduce this problem.
A non-XUL (HTML, SVG, etc.) table cell should always have a CachedTableAccessible ancestor.
Apparently, this sometimes isn't the case.
It seems there can be a table ancestor which is not a CachedTableAccessible, which could only be a XULListboxAccessible or XULTreeGridAccessible.
In this case, CachedTableCellAccessible::GetFrom would previously try to cast this TableAccessible to a CachedTableAccessible and breakage would ensue.
I don't know how this can happen, but we protect against this now by returning early if a XUL table is found, since a XUL table can never be a CachedTableAccessible.
In contrast, all non-XUL tables are always CachedTableAccessibles.
Differential Revision: https://phabricator.services.mozilla.com/D191374
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
