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
This change is necessary to support the [CSS Highlight API](https://drafts.csswg.org/css-highlight-api-1/),
which uses `Selection` internally.
To replace `nsRange` with `AbstractRange`, some sections needed to be
adapted since `nsRange`-specific features were used.
Therefore, some methods (such as `GetRangeAt()`) may only be called if
the `Selection` is *not* of type `SelectionType::eHighlight`,
as it (per spec) returns an `nsRange`.
These methods will now `MOZ_ASSERT` if called for a highlight selection.
Additional methods are implemented which return `AbstractRange`
instead and are safe to be called for every selection type.
This commit also improves support of highlight features:
- Invalidation of highlight ranges: adding/removing Ranges in-place instead of
removing and re-adding the Selection object associated with the highlight.
- Ranges are only associated with the Selection that shares the same Document
- Fixed minor IDL issue
Differential Revision: https://phabricator.services.mozilla.com/D170582
When hit testing, we retrieve the bounds for every character in a text leaf in a separate call.
Because we need to convert from an array of flat ints to rects, this previously meant we built the entire array for every character.
For a large text leaf, building this rect array is relatively expensive.
We only need a single rect at a time.
Therefore, RemoteAccessibleBase now returns the rect for a single requested character instead of building an array of rects.
Differential Revision: https://phabricator.services.mozilla.com/D171419
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
Move it to the mozilla::widget namespace.
Use enum classes for transparency, popup type, popup level, etc.
Mostly automated with sed, but there were a few manual changes required
as well in windows code because they relied on Atomic<TransparencyMode>
working (which now doesn't because TransparencyMode is 1 byte instead of
4 bytes).
Differential Revision: https://phabricator.services.mozilla.com/D167537
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
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
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
HTMLSelectEventListener changes are needed, since currently that code works somewhat by accident given that
mTime often contains totally bogus values, like PR_IntervalNow(). Those changes then reveal issues also in
browser_editAddressDialog.js.
Differential Revision: https://phabricator.services.mozilla.com/D165618
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
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
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
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
In bug 1766794, I replaced partial invalidation of cached offsets with full cache invalidation.
I did this to simplify the code, since the offsets cache was being extended to RemoteAccessible.
This is fine for RemoteAccessible because offsets are only needed there when clients query them.
However, for local HyperTextAccessible, offsets are always required to fire text events.
Full cache invalidation there meant that many insertions into a large container was very expensive.
To fix this, reinstate the ability to partially invalidate the offsets cache.
This is largely the code I previously removed from HyperTextAccessible, with some tweaks for readability.
Differential Revision: https://phabricator.services.mozilla.com/D163418
We will soon have an offsets array in the parent process cache which is not built in one shot.
Instead, we will gradually cache more offsets as they are requested.
To do this, we need a way to get an array from the cache which can be modified in-place.
Differential Revision: https://phabricator.services.mozilla.com/D163417
The pivot should never cross from remote into parent process local
containers. We need to explicitly set the root for the pivot, and
assert for this in the pivot traversal methods.
Differential Revision: https://phabricator.services.mozilla.com/D163285
