We now use CachedTableAccessible for ARIA tables and grids, so most of the code in the ARIA table classes was unused.
1. Remove ARIAGridAccessible and ARIARowAccessible completely.
2. ARIAGridCellAccessible no longer derives from TableCellAccessible.
3. Remove most of ARIAGridCellAccessible.
4. We still use ARIAGridCellAccessible to differentiate between valid and invalid cells. Valid cells create an ARIAGridCellAccessible and ARIAGridCellAccessible::IsTableCell() returns true due to mGenericTypes. Invalid cells don't get an ARIAGridCellAccessible, so IsTableCell() returns false on those.
5. We also keep the code in ARIAGridCellAccessible to expose some states and attributes.
6. The code for creating ARIAGridCellAccessible in CreateAccessible has been refactored, both for simplification and to fix bugs. display: contents tables now properly get the table and table cell interfaces; i.e. IsTable() and IsTableCell() return true when appropriate. Walking non-generic ancestors should fix ARIA tables with intervening generics, though this will be dealt with fully in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D179801
We now use CachedTableAccessible for HTML tables, so much of the code in the HTMLTable*Accessible classes was unused.
However, we still depend on these classes for some data needed to build the cached table.
1. HTMLTableAccessible and HTMLTableCellAccessible no longer derive from TableAccessible and TableCellAccessible, respectively. Instead, callers which need specific access to HTML table data use the HTMLTable*Accessible class directly.
2. All table specific methods have been removed except those that provide data required to build a CachedTableAccessible. The remaining methods are those for querying the row/column span (which depends on layout) and getting the caption (which depends on DOM).
3. HTMLTable*Accessible are now used for all <table>, <td>, <th> and <tr> elements and MathML equivalents. ARIA*Accessible are never used for these elements. This improves consistency, simplifies the code and means that behavior specific to these HTML elements is handled in these classes, rather than in the ARIA classes as well.
4. The table and row roles are now specified in HTMLMarkupMap and MathMLMarkupMap, rather than overriding NativeRole. Cell roles are still handled in a NativeRole override; see the code comments for details.
5. IsProbablyLayoutTable has been moved from TableAccessible to HTMLTableAccessible, as it is only relevant for HTML tables, not for ARIA tables.
6. HTMLTableHeaderCellAccessible::NativeRole has been rewritten such that it no longer depends on querying table coordinates, as that would now require building a CachedTableAccessible, which would be very wasteful here. This replaces TableCellAccessible::HeaderCellRole, which has been removed.
Differential Revision: https://phabricator.services.mozilla.com/D179799
Updated HTMLMarkupMap to expose `<s>` element with an implicit `roles::CONTENT_DELETION`, updated `accessible/tests/mochitest/elm/test_HTMLSpec.html` Mochitest and expected results for `testing/web-platform/tests/html-aam/roles.html` wpt test
Differential Revision: https://phabricator.services.mozilla.com/D179842
This revision modifies NotifyOfAnchorJump in order to ensure that we fire a
scrolling start event for AT clients. Without this, clients might miss anchor
jump updates, since anchor jumps can arrive after getting focus. This revision
also adds a test to verify that the scrolling start event is now being sent.
Differential Revision: https://phabricator.services.mozilla.com/D177419
This revision modifies UncacheChildrenInSubtree such that removed but relocated
accessibles that are aria-owned are actually relocated to their proper parent
after the removal of the formerly-aria-owning parent. It also contains some
fixes for issues that allowing this relocation unleashes. In particular:
- Logic in PutChildrenBack is reworked in order to better handle different
reparenting situations, such as unacceptable parents or original containers
(or ancestors thereof) that are no longer in the document. These changes help
us avoid failure modes related to events on defunct accessibles, or bad
coalescence due to partially-shut-down trees.
- ShutdownOrPrepareForMove has been updated to handle moving children. We now
recurse through children and move them rather than just shutting them down.
This revision adds tests which verify that the functionality works as intended.
Differential Revision: https://phabricator.services.mozilla.com/D176204
Updated HTMLMarkupMap to expose `<s>` element with an implicit `roles::CONTENT_DELETION`, updated `accessible/tests/mochitest/elm/test_HTMLSpec.html` Mochitest and expected results for `testing/web-platform/tests/html-aam/roles.html` wpt test
Differential Revision: https://phabricator.services.mozilla.com/D179842
This ensures that these are HyperTextAccessibles if they contain text, which prevents assertions and exposes formatting information.
It also gives these the correct role.
Differential Revision: https://phabricator.services.mozilla.com/D179409
We had some different results in non-caching mode. We can now unify the results and not worry about that.
Depends on D178718
Differential Revision: https://phabricator.services.mozilla.com/D178719
We had some different results in non-caching mode. We can now unify the results and not worry about that.
Depends on D178718
Differential Revision: https://phabricator.services.mozilla.com/D178719
Now that we always have the core parent process cache, this is no longer necessary.
This also removes EVENT_TABLE_STYLING_CHANGED, which was only used to keep the Mac cache up to date.
Differential Revision: https://phabricator.services.mozilla.com/D178425
Previously, we passed true for aIsEnabled, indicating that the state was only ever enabled, never disabled.
We could get the actual enabled value here using dom::ElementState::HasState(), but that wouldn't take aria-invalid into account if present.
Instead, we let AccStateChangeEvent calculate it by calling Accessible::State().
Differential Revision: https://phabricator.services.mozilla.com/D178039
1. CachedTextMarker::LineRange: If the line starts with a line feed, it's a blank line and the end boundary is the same as the start boundary, so just return the start for both.
2. TextLeafRange::FindLineEnd: If the origin is the empty last line of a textarea, we actually do want the line starting at the next character, so don't skip forward a character. Also don't skip back to the line feed after the search, since that would be the end of the previous line.
Differential Revision: https://phabricator.services.mozilla.com/D177366
This revision modifies UncacheChildrenInSubtree such that removed but relocated
accessibles that are aria-owned are actually relocated to their proper parent
after the removal of the formerly-aria-owning parent. On the way to
accomplishing that goal, this revision adds PutChildBack, a method called by
PutChildrenBack and now also called by UncacheChildrenInSubtree. We don't always
want to put all the children back - this function lets us manage it one at a time.
Finally, this revision adds tests which verify that the functionality works
as intended.
Differential Revision: https://phabricator.services.mozilla.com/D176204
The message wasn't doing anything useful on Mac. Took the opportunity to
correcty expose the AXTitle/AXDescription of headings.
Differential Revision: https://phabricator.services.mozilla.com/D176824
This is used by the Web Access NVDA add-on to identify and remediate some inaccessible elements on websites with accessibility problems.
It is also useful for developers using screen readers when trying to identify specific elements in the absence of semantics.
Differential Revision: https://phabricator.services.mozilla.com/D176896
Line should return the current line when the start of the line is queried.
Otherwise, VoiceOver reports the previous line if you're on the first character of a line and you move by line with down or up arrow.
LegacyTextMarker behaves inconsistently when you use Line/LeftLine depending on whether you fetched the marker via index or from a selection range.
browser_text_basics.js treated the index behaviour as correct, but it isn't.
The tests have been updated accordingly with expected failures for non-cached.
Differential Revision: https://phabricator.services.mozilla.com/D176608
CachedTextMarker uses TextLeafPoint.
Because caret and selection events currently use HyperText offsets, we construct text markers using a HyperTextAccessible.
The constructor detects that it was provided with a HyperText and converts to a TextLeafPoint appropriately.
However, this was previously conditional on the provided offset being less than the character count.
When the caret is at the insertion point at the end of a text box, the caret offset will be the character count itself.
This meant that we didn't convert to TextLeafPoint in this case, resulting in an incorrect text marker.
This was causing VoiceOver to report the first character, word, etc. when cursoring through text boxes instead of the last.
Differential Revision: https://phabricator.services.mozilla.com/D176522
The code previously checked !childAtOffset->IsText(), but this isn't sufficient to be certain that childAtOffset->AsHyperTextBase() will work.
For example, childAtOffset could be an image which can't be descended into.
Differential Revision: https://phabricator.services.mozilla.com/D174213
This revision adds logic to BoundsWithOffset to ensure that bounds, when
calculated for hit testing, are constrained to the scroll areas that contain
them. This ensures that we don't return an Accessible that's covered by another
element when hit testing due to overflow: scroll situations.
This revision also contains a fix for transforms and scroll: we now apply
scroll before any transform, since transforms operate on scrolled content.
This revision contains tests for both of the above changes.
Differential Revision: https://phabricator.services.mozilla.com/D173392
Previously, PushNameOrDescriptionChange wouldn't consider the target itself as a candidate for a name change event.
If the text of a text leaf changes without replacing the leaf, the only event we will get is text inserted on its parent.
If that parent calculated its name from its subtree, this meant that we wouldn't fire a name change in this case.
We address this by allowing this function to fire on the target itself in this case.
Differential Revision: https://phabricator.services.mozilla.com/D172953
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
Previously, we always used the Accessible's rect.
However, if the text wraps across lines, its rect might cover a wider area than the actual text.
That meant we were matching a wrapped text leaf when we shouldn't in some cases.
Now, we restrict text leaf matches to the rects occupied by text.
Differential Revision: https://phabricator.services.mozilla.com/D173097
This patch remedies 4 things:
1. Fix conversion from NSRange to GeckoTextMarkerRange. We were adding the start offset twice. Oops.
2. Clamp given range to actual text size. Since we are messing with the offset fields directly we need to do our own checks here.
3. Don't allow an infinite loop in CachedTextMarkerRange::AttributedText
4. Fix legacy Crop method to be able to take a text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D172594
This patch remedies 4 things:
1. Fix conversion from NSRange to GeckoTextMarkerRange. We were adding the start offset twice. Oops.
2. Clamp given range to actual text size. Since we are messing with the offset fields directly we need to do our own checks here.
3. Don't allow an infinite loop in CachedTextMarkerRange::AttributedText
4. Fix legacy Crop method to be able to take a text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D172594
This patch remedies 3 things:
1. Fix conversion from NSRange to GeckoTextMarkerRange. We were adding the start offset twice. Oops.
2. Clamp given range to actual text size. Since we are messing with the offset fields directly we need to do our own checks here.
3. Don't allow an infinite loop in CachedTextMarkerRange::AttributedText
Differential Revision: https://phabricator.services.mozilla.com/D172594
This patch remedies 3 things:
1. Fix conversion from NSRange to GeckoTextMarkerRange. We were adding the start offset twice. Oops.
2. Clamp given range to actual text size. Since we are messing with the offset fields directly we need to do our own checks here.
3. Don't allow an infinite loop in CachedTextMarkerRange::AttributedText
Differential Revision: https://phabricator.services.mozilla.com/D172594
Otherwise, tests can take a very long time to run due to a bug without us realising that this is due to cache condition timeouts.
This patch also notifies observers of a cache update when state change events are received, as those do update the cache but aren't handled by RecvCache.
Some Mac tests depend on cache notifications for these instead of state change events, so these were hitting cache condition timeouts.
Differential Revision: https://phabricator.services.mozilla.com/D171417
Table rows and cells are now treated as paragraph boundaries.
Whether a cell should be a paragraph boundary is debatable, but currently, a cell is treated as a line boundary, so this is consistent; a line shouldn't expand beyond a paragraph.
Differential Revision: https://phabricator.services.mozilla.com/D172079
1. Open the link in a new tab instead of a new window. I originally did this to make debugging easier with a screenshot, but it seems to actually make the test more reliable. I don't know why.
2. Suffix the URL so we can be sure it will not have been visited before the test.
Differential Revision: https://phabricator.services.mozilla.com/D171948
Otherwise, tests can take a very long time to run due to a bug without us realising that this is due to cache condition timeouts.
This patch also notifies observers of a cache update when state change events are received, as those do update the cache but aren't handled by RecvCache.
Some Mac tests depend on cache notifications for these instead of state change events, so these were hitting cache condition timeouts.
Differential Revision: https://phabricator.services.mozilla.com/D171417
1. HyperTextAccessibleBase::CharBounds didn't have code to support magic offsets (like TEXT_OFFSET_CARET) at all, resulting in a crash.
2. HyperTextAccessibleBase::TextBounds handled the end offset being a magic offset, but not the start offset.
3. HyperTextAccessible::CharBounds assumed it could just add 1 to the start offset to pass to TextBounds, which resulted in returning the rect from the caret to the end of the container, since length (-1) is caret (-2) + 1.
This patch addresses all three of these issues.
Differential Revision: https://phabricator.services.mozilla.com/D171545
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
These text marker and marker range classes use our text cache and don't rely on any sync calls.
There are some edge cases where the range for boundary type code diverges from the non-caching one. The tests have amended exceptions for that in cases where the caching code is more correct, or at least not more wrong :)
Differential Revision: https://phabricator.services.mozilla.com/D168451
This change gives a bit more flexibility for isolating issues and seeing which specific marker offset is giving trouble when a test fails.
Depends on D168445
Differential Revision: https://phabricator.services.mozilla.com/D168446
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
Previously, the test was retrieving an Accessible with a non-existent id and calling testAccessibleTree on it.
That meant we were calling testAccessibleTree with null, which is a no-op.
Now, we get the intended Accessible so that the test actually tests what it was supposed to test.
This is important to test a potential bug in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D170306
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
Previously, the test was retrieving an Accessible with a non-existent id and calling testAccessibleTree on it.
That meant we were calling testAccessibleTree with null, which is a no-op.
Now, we get the intended Accessible so that the test actually tests what it was supposed to test.
This is important to test a potential bug in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D170306
This uses a bitfield for flags in FindBoundary, the idea is that it
will give some regression coverage if/when we move the native API
to do the same.
Differential Revision: https://phabricator.services.mozilla.com/D169246
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
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
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
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
Mostly changing XUL attributes to CSS properties, though there are a few
tricky ones:
* test_offsets.xhtml expects the scroller to be full-width, while
modern flexbox would honor width: 200px (so just remove it).
* window_intrinsic_size.xhtml was relying on the div imposing a XUL
min-size (the test is for SetSizeConstraints, bug 1447056). Use
min-height instead as that's what modern flexbox reads. Confirmed
that bug doesn't regress in any case.
* object-fit-contain-png-001.xhtml has a float: left which had no
effect on -moz-box, but which assert with modern layout[1]. In the
future I think we could remove that assert but anyways, for now just
keeping behavior.
* image-size.xhtml has a couple uninvestigated sizing differences. They
didn't seem problematic.
* 579323-1-ref.html changes because the other file has a canvas with
width=100 height=100 which imposes an aspect ratio (which XUL never
honored).
* window_largemenu.xhtml shows a regression, but this never worked on
some platforms (at least Linux+Wayland) and nobody has noticed it in
the browser area, so I suspect we're fine.
[1]: https://searchfox.org/mozilla-central/rev/08362489086b10de96e7a199b267ea5504c01583/layout/generic/ReflowInput.cpp#2137
Differential Revision: https://phabricator.services.mozilla.com/D169084
Calculating it relative to an ancestor causes problems when the frame ancestry and the a11y ancestry diverge.
For example, this can happen for a transform which is also position: absolute.
In that case, the parent Accessible's frame is not an ancestor of the child Accessible's frame.
Since the transform is no longer relative to the ancestor, we no longer need to remove our parent-relative bounds before applying it.
However, we do need to ensure that we apply the transform *before* adding parent-relative bounds.
Differential Revision: https://phabricator.services.mozilla.com/D169059
Most usage is a straight replacement but gtk needs extra changes as it transfers plain text in UTF8 natively and needs to be converted into UTF16, and Windows uses single-byte characters for RTF and CF_HTML formats so we preserve this.
Differential Revision: https://phabricator.services.mozilla.com/D158587
When an Accessible is moved, it's possible it is re-parented.
In that case, since our cached bounds are relative to the parent, the bounds are now incorrect.
To fix this, queue a bounds cache update whenever an Accessible is moved.
This will also trigger when an Accessible remains under the same parent.
However, because we cache bounds in LocalAccessible, we won't actually push a cache update unless the bounds really changed.
Differential Revision: https://phabricator.services.mozilla.com/D167866
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
If a container has a 0 width/height, we use the ink overflow rect.
A container can overflow beyond the top left of its main rect; e.g. with align-items: flex-end.
Previously, when calculating the parent relative bounds of children, we always calculated relative to the parent's main rect.
If we ended up using the ink overflow rect for the parent, this meant that the parent relative bounds of children were wrong.
To fix this, compensate for the ink overflow offset in this case.
Differential Revision: https://phabricator.services.mozilla.com/D167636
A frame doesn't have to be reflowed to change its position.
For example, if there is a container c followed by a node outside the container o, inserting a node into c reflows c, but moves o down the page without reflowing o.
In this case, we previously weren't being notified that there was a possible bounds change, which meant we weren't updating the cache.
Now, we get notified about frames moving regardless of reflow.
Since this notification includes changes to CSS left/right/top/bottom, we can also remove the code added in bug 1774705 to explicitly watch for changes to these properties.
Differential Revision: https://phabricator.services.mozilla.com/D167645
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
For deepest child, previously, if the requested point was inside a different subtree to the origin Accessible (e.g. out-of-flow), we would return null because the origin wasn't an ancestor of the target.
We still check the ancestry, but if the point is inside the origin, we return the origin.
This is consistent with LocalAccessible (and thus non-cached RemoteAccessible).
For direct child, previously, we would return a child of the origin even if another element in a different subtree was higher in the z-order.
This is because we kept walking the viewport cache until `this`.
Instead, we now stop at the deepest match and walk up to the direct child if the origin is an ancestor.
If it isn't an ancestor, we still fall back to the origin if the point is inside it, just as we do for deepest child.
This change is necessary here because our test for out-of-flow hit testing changes the CSS left property to move an out-of-flow element.
That test passed because the bounds cache for that element was never updated, so we always found the target we expected.
In the next patch, we fix the bounds cache update, which would break this test without this hit testing fix.
In addition, this patch also changes our test for overlapping elements to match this new expectation.
There were also some bugs in the test that had to be fixed; e.g. using y instead of height to get the centre.
Since this is now consistent, we can remove the cache restriction and test LocalAccessible as well.
Differential Revision: https://phabricator.services.mozilla.com/D166849
textareas contain an anonymous div which fires the scroll event.
We don't have an Accessible for this div, so previously, we were just ignoring the scroll event.
Now, we'll redirect it to the textarea and get its Accessible.
This ensures that we push a cache update so that the scroll position (and thus the bounds) are correct.
This also means that a11y scroll events are fired on textareas where they weren't previously.
Differential Revision: https://phabricator.services.mozilla.com/D166508
Transition the group position calculation - specifically the code in Update -
to Pivot such that we can handle finding siblings across intervening generic
container accessibles, such as SECTIONs. This fixes issues with finding the
values of "pos in set" and "set size" for descendant owned elements in compound
ARIA widgets. This revision also updates and adds tests for this functionality.
Differential Revision: https://phabricator.services.mozilla.com/D165756
These MathML table elements may not have a table display style, in which case
they shouldn't be HTML table accessibles. This revision changes the logic of
MathMLMarkupMap such that mtable, mtr elements create generic ARIA accessibles
if the display style for the element is something other than 'table'. This
revision also adds a test to verify that the roles are still reported correctly,
even with this change.
Differential Revision: https://phabricator.services.mozilla.com/D165980
When an element's slot changes and the element is unslotted, we remove its Accessible.
If the body is moved inside a shadow host at the same time, we will process the slot removal first because moves are processed async.
Previously, this caused us to try to remove the DocAccessible (since it was still associated with the body), causing nastiness and potentially crashes.
We should never try to remove the DocAccessible, so explicitly prevent this when handling slot changes.
An assertion was also added to make sure we never try to remove the DocAccessible in future.
Differential Revision: https://phabricator.services.mozilla.com/D166134
This test passes on automation, somehow, probably due to timing.
Locally the click rolls up the popup (so you'd need a second click to
show the other popup).
This happens both with and without the patch, and given I debugged and
it is trivial to fix, well, make sure to hide the previously open menu
before clicking on another...
Differential Revision: https://phabricator.services.mozilla.com/D165983
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
My patch in bug 1805414 makes this fail in a way that's perma, and it
seems it is because we're not waiting for the actual value change to
happen.
Differential Revision: https://phabricator.services.mozilla.com/D165238
If the slot attribute is changed to assign the element to a slot which doesn't exist in the shadow DOM, the element is now unslotted and thus shouldn't be rendered.
We have code in PruneOrInsertSubtree to handle changes like this, but that only works if the frame for the shadow host or something inside the shadow DOM gets reconstructed.
In the case of a shadow host with a single child, there might not necessarily be any frame reconstruction.
To handle this, we listen for changes to the slot attribute.
We check if the element is still part of the flat tree (i.e. it is slotted).
If it isn't, we remove its Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D165135
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
When applying an ancestor transform, ApplyTransform is supplied with the cumulative bounds calculated so far; i.e. from descendants.
When removing the parent relative offset, the code previously set the top left to (0, 0).
This not only removed the parent relative offset, but also the cumulative offset calculated for all descendants!
Instead, we now pass in the cumulative bounds as well as the parent relative bounds.
We only subtract the parent relative bounds.
Differential Revision: https://phabricator.services.mozilla.com/D164995
When applying an ancestor transform, ApplyTransform is supplied with the cumulative bounds calculated so far; i.e. from descendants.
When removing the parent relative offset, the code previously set the top left to (0, 0).
This not only removed the parent relative offset, but also the cumulative offset calculated for all descendants!
Instead, we now pass in the cumulative bounds as well as the parent relative bounds.
We only subtract the parent relative bounds.
Differential Revision: https://phabricator.services.mozilla.com/D164995
Previously, this test case caused an assertion, but that was fixed in bug 1792120.
We also ensure the x and y are the same before an dafter the re-creation.
This verifies that we aren't losing the iframe's border/padding.
Differential Revision: https://phabricator.services.mozilla.com/D164879
Aside from making the code consistent for OOP and in-process iframes, this also fixes incorrect bounds in in-process iframe documents when the iframe's padding is changed.
We always pushed a cache update for the iframe when the padding was changed.
However, we previously relied on parent-relative bounds for in-process iframes, which didn't get updated when the iframe's padding changed.
Differential Revision: https://phabricator.services.mozilla.com/D164878
See the code comments for an explanation.
This fixes assertions and crashes when pushing the cache when a page contains a map which is unslotted in a shadow host.
Differential Revision: https://phabricator.services.mozilla.com/D164783
Calling GetAccessibleOrContainer meant that if a particular content node didn't have an Accessible but did have a frame, we'd insert its container in its place.
There might have been other descendants of that container that did have Accessibles, though.
In that case, we would have put the container ahead of some of its descendants!
To fix this, use GetAccessible instead.
We'll still fall back to the container if the user hit tests a point in an inaccessible node, since it will appear later in the viewport cache.
Differential Revision: https://phabricator.services.mozilla.com/D164803
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
Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
This makes a couple of large changes:
(1) "Generic" buttons (the ones added by `UrlbarView.#addRowButton()`) are now
supported in all row types. The help button that's currently included in some
types of rows when `result.payload.helpUrl` is defined is now supported for all
row types, and two additional button types are now supported too: block buttons
and labeled buttons. A row will get a block button if its
`result.payload.isBlockable` is defined. It will get a labeled button if
`result.payload.buttons` is defined and non-empty. A button can include a `url`
property that is then added as an attribute on the button's element, and
`UrlbarInput.pickResult()` will use this attribute to load the URL when the
button is picked.
(2) The reason I added labeled buttons is because it lets us support tip buttons
without much more effort, which then lets us get rid of the special row type
used for tips. With this patch, tips are now standard rows that use generic
buttons.
This approach should be compatible with the result menu, when we switch over to
it, because we can include the help and block commands in the menu when
`helpUrl` and `isBlockable` are defined, instead of creating buttons for them.
Labeled buttons -- the ones used in tips -- would still be created. The result
menu button itself can continue to be a generic button.
It should also be compatible with including the result menu button inside the
row selection. We'll still add buttons to `.urlbarView-row`, separate from
`.urlbarView-row-inner`, so that the buttons can continue to be on the right
side of the row. We can color the background of the row instead of the
row-inner.
As with D163630, my motivation for this change is to support generic buttons in
dynamic result rows so that help and block buttons can be easily added to
weather suggestions. Here too the larger changes of supporting generic labeled
buttons and removing special rows for tips aren't strictly necessary, but I took
the opportunity to rework things.
Finally, this makes a few other changes:
* It includes some of the more minor improvements to selection that I made in
D163630.
* It removes the help URL code from quick actions since it was decided not to
show a help button. Currently, the button is hidden in CSS, but now that a
generic help button is added for dynamic result rows when
`result.payload.helpUrl` is defined, `helpUrl` needs to be removed from the
payload to prevent a button from being added.
* I removed the special tip wrapping behavior, where the tip button and help
button would wrap below the tip's text. Instead, now the text wraps inside
row-inner and the buttons always remain on the same horizontal as the text. I
don't think it's worth the extra complication.
Differential Revision: https://phabricator.services.mozilla.com/D163766
This makes a couple of large changes:
(1) "Generic" buttons (the ones added by `UrlbarView.#addRowButton()`) are now
supported in all row types. The help button that's currently included in some
types of rows when `result.payload.helpUrl` is defined is now supported for all
row types, and two additional button types are now supported too: block buttons
and labeled buttons. A row will get a block button if its
`result.payload.isBlockable` is defined. It will get a labeled button if
`result.payload.buttons` is defined and non-empty. A button can include a `url`
property that is then added as an attribute on the button's element, and
`UrlbarInput.pickResult()` will use this attribute to load the URL when the
button is picked.
(2) The reason I added labeled buttons is because it lets us support tip buttons
without much more effort, which then lets us get rid of the special row type
used for tips. With this patch, tips are now standard rows that use generic
buttons.
This approach should be compatible with the result menu, when we switch over to
it, because we can include the help and block commands in the menu when
`helpUrl` and `isBlockable` are defined, instead of creating buttons for them.
Labeled buttons -- the ones used in tips -- would still be created. The result
menu button itself can continue to be a generic button.
It should also be compatible with including the result menu button inside the
row selection. We'll still add buttons to `.urlbarView-row`, separate from
`.urlbarView-row-inner`, so that the buttons can continue to be on the right
side of the row. We can color the background of the row instead of the
row-inner.
As with D163630, my motivation for this change is to support generic buttons in
dynamic result rows so that help and block buttons can be easily added to
weather suggestions. Here too the larger changes of supporting generic labeled
buttons and removing special rows for tips aren't strictly necessary, but I took
the opportunity to rework things.
Finally, this makes a few other changes:
* It includes some of the more minor improvements to selection that I made in
D163630.
* It removes the help URL code from quick actions since it was decided not to
show a help button. Currently, the button is hidden in CSS, but now that a
generic help button is added for dynamic result rows when
`result.payload.helpUrl` is defined, `helpUrl` needs to be removed from the
payload to prevent a button from being added.
* I removed the special tip wrapping behavior, where the tip button and help
button would wrap below the tip's text. Instead, now the text wraps inside
row-inner and the buttons always remain on the same horizontal as the text. I
don't think it's worth the extra complication.
Differential Revision: https://phabricator.services.mozilla.com/D163766
This revision changes the logic in MathMLMarkupMap such that mtd elements create
generic ARIA grid accessibles if the display style for the element is something
other than 'table'. This revision also adds a test that verifies that the roles
remain as expected, even with this change.
Differential Revision: https://phabricator.services.mozilla.com/D163898
Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
Done:
- Functionality of the button was changed from cleaning the field value to toggling the datepicker dialog.
- Pre-existing issues resolved: Updated datetimebox.js to use `keydown` event instead of the deprecated `keypress` (which does not preventDefault for buttons), added default handling of digits for `keydown`, and added a check to avoid running duplicate cleanup when the picker is closed
- Removed ability to open a date picker from editable elements of the `<input type="date">` field and ensured keyboard and mouse/touch click are working for the Calendar button, while Escape functionality remained
- Updated `onBlur` logic for the button in accordance with its new functionaility
- New Calendar SVG icon was created by Katie Caldwell and optimized by Sam Foster
- Provided HCM support for the Calendar button
- Ensured the Calendar button is not shown on `<input type=time>` to preserve the existent UX
- Added Fluent l10n to the content process and provided `title` to the image button (SVG is marked as `role="none"` to avoid exposure to assistive technology)
- Added functional and markup tests for the Calendar button and its localization, updated Reset button tests to the Calendar one
ToDo (further patch):
1. Pt.4 - Ensure keyboard support when focus moves between processes
ToDo (other dependencies/bugs):
1. Investigations into if we should show a calendar button for read-only fields and if a Reset button would be benefitial to be shown for a `type=time` inputs
Depends on D139981
Differential Revision: https://phabricator.services.mozilla.com/D141175
This revision addresses an issue with th elements within tables that don't have
the table CSS display style. In these cases, where we create an
ARIAGridCellAccessible for a th, we fail to report rowheader and columnheader
properly, since ARIAGridCellAccessible doesn't know how to handle th elements.
This revision fixes the problem by moving the th NativeRole logic into the
TableCellAccessible class, then calling that logic from both the ARIA grid cell
accessible NativeRole and from HTMLTableHeaderCellAccessible, as before. This
revision also updates tests reliant on the old behavior, including beefing up
an existing test aimed at this bug specifically.
Differential Revision: https://phabricator.services.mozilla.com/D163371