We assume ARIA roles are case insensitive when setting up the role map entry.
In contrast, previously, when falling back to the next valid role due to the criteria for an earlier role not being met, we were using a case sensitive comparison.
This resulted in infinite recursion when an invalid role contained upper case characters because we kept trying to process the ARIA role we were already processing.
To fix this, use a case sensitive comparison here, making it consistent with other ARIA role checks.
Original Revision: https://phabricator.services.mozilla.com/D253617
Differential Revision: https://phabricator.services.mozilla.com/D253753
I decided not to use aria-disabled directly because we currently don't
cache it in the parent, and I don't think the benefit would be great
enough.
Differential Revision: https://phabricator.services.mozilla.com/D250357
We don't expose the view transition tree to the accessibility tree per
our current implementation, so only a test in this patch.
In the test, we shouldn't see any view transition pseudo-elements in the
accessibility tree.
Differential Revision: https://phabricator.services.mozilla.com/D250840
This reverts commit d4794289e7.
Revert "Bug 1899960 - P1: Don't cache implicit states. r=Jamie"
This reverts commit dd5d2cd561.
Revert "Bug 1967813 - Check menu's frame IsOpen to determine if menu is active. r=morgan"
This reverts commit 2d6a0f17e3.
I decided not to use aria-disabled directly because we currently don't
cache it in the parent, and I don't think the benefit would be great
enough.
Differential Revision: https://phabricator.services.mozilla.com/D250357
Previously, both literal line feed characters in pre-formatted text and HTMl <br> elements returned a rect with 0 width and/or height.
Because of the way CharBounds() was implemented, this also returned 0 for x and y.
This caused problems for clients such as Windows Text Cursor Indicator which need the rectangle for the character at the caret.
Now, we return the correct x and y coordinates.
We also return a minimum width and height of 1 to ensure clients treat it as an actual rectangle.
As part of this, CharBounds() has been refactored slightly for consistency and readability.
As a bonus, this also fixes character bounds for list item bullets (bug 360003), but a test for that will be added in a subsequent patch.
This patch also removes the special case line feed code added to TextLeafRange::WalkLineRects() in bug 1946552, since CharBounds() now handles this.
Differential Revision: https://phabricator.services.mozilla.com/D249709
This is the scenario for this bug:
1. A UIA client retrieved a range for the caret at the end of a text input at the end of a document, collapsed at (input, 2).
2. Backspace was pressed, removing the last character, so (input, 2) was no longer valid.
3. The UIA client attempted to call GetAttributeValue on the previously fetched range.
4. FindTextAttrsStart couldn't move further, so it returned the document end point, (input, 1).
5. Because the range contained (input, 2), the search point was never less than the end point, so we got stuck in an infinite loop in GetAttributeValue.
To fix this, UiaTextRange now restricts offsets to the length of the leaf Accessibles when reconstructing the TextLeafRange.
Differential Revision: https://phabricator.services.mozilla.com/D248734
I removed this behaviour in bug 1951573.
Unfortunately, it turns out that contrary to the spec (which says "1 or more selections"), NVDA depends on this behaviour.
Reinstate this by supporting kRemoveAllExistingSelectedRanges in HyperTextAccessibleBase::RemoveFromSelection and using that.
Differential Revision: https://phabricator.services.mozilla.com/D247875
A TextLeafPoint is always a leaf Accessible and an offset within that Accessible.
When a TextLeafPoint is created for the end of a container and the last Accessible in the container isn't text (e.g. it is an image), TextLeafPoint represents this as offset 1 within the image.
When calculating a DOM point for such a TextLeafPoint, we need to use the child index for the next DOM node.
This indicates to DOM that the point should be positioned after the node.
Differential Revision: https://phabricator.services.mozilla.com/D247874
For text nodes, DOM points use the character offset within the node itself, just like accessibility does.
For non-text nodes, DOM points use the child index within the parent to specify the position before or after the node.
Previously, TextLeafPoint::ToDOMPoint always used an offset within the node itself.
This meant that when the (exclusive) end point of a range was an image, we converted to a DOM point of offset 0 within the image.
As far as DOM is concerned, this includes the image.
This patch adjusts ToDOMPoint as appropriate.
As part of this, ToDOMPoint now returns a uint32_t instead of an int32_t.
This is because DOM offsets are actually uint32_t and calculating int32_t child indices is deprecated.
Differential Revision: https://phabricator.services.mozilla.com/D247873
When we descend to the end for an embedded object character, we get the position after the last character inside that embedded object.
This isn't what we want for selections because the end offset should be exclusive, not inclusive.
Descending to the end means we include the entire content of the embedded object instead of excluding it.
Instead, always descend to the start.
Differential Revision: https://phabricator.services.mozilla.com/D247872
We did have support for IA2 testing when this was added.
However, because this interface is a relatively recent addition to the IA2 spec, it isn't included in the COM proxy dll included in Windows.
This means we can't run these tests without building and installing our own proxy DLL.
This has to be integrated into the Windows CI images, so we can't run these tests on CI for now and thus they're disabled on CI.
Even so, it's better to have local-only tests for this than no tests at all.
Differential Revision: https://phabricator.services.mozilla.com/D247871
This is a bit risky, but I hope worthwhile.
I also changed the single labelling relation check in moxTitle and moxLabel to not allocate an NSArray.
Differential Revision: https://phabricator.services.mozilla.com/D247369
Tests go in accessible/tests/browser/performance.
They use the usual addAccessibleTask function to add a test.
Inside the task, they can time operations using the timeThis() function, which takes a name and a function to time.
As well as logging the time, this also logs all accessibility PerfStats captured during the function.
For now, output is simply logged using info().
In future, we may wish to output this data elsewhere; e.g. so it can be picked up by performance monitoring tools.
Having this single function should make extending this fairly easy without needing to rewrite tests.
Two initial tests have been included:
- browser_manyMutations.js: Test for bug 1948375.
- browser_spellingErrors.js: Test for bug 1961832.
Differential Revision: https://phabricator.services.mozilla.com/D246544
Tests go in accessible/tests/browser/performance.
They use the usual addAccessibleTask function to add a test.
Inside the task, they can time operations using the timeThis() function, which takes a name and a function to time.
As well as logging the time, this also logs all accessibility PerfStats captured during the function.
For now, output is simply logged using info().
In future, we may wish to output this data elsewhere; e.g. so it can be picked up by performance monitoring tools.
Having this single function should make extending this fairly easy without needing to rewrite tests.
Two initial tests have been included:
- browser_manyMutations.js: Test for bug 1948375.
- browser_spellingErrors.js: Test for bug 1961832.
Differential Revision: https://phabricator.services.mozilla.com/D246544
This diff was generated as follows:
List all toml files in the tree:
`find * -name '*.toml' > /tmp/toml`
Manually edited /tmp/toml to drop non-relevant entries (objdir).
Ran the toml linter for all files:
`cat /tmp/toml | xargs ./mach lint -l test-manifest-toml --fix`
Differential Revision: https://phabricator.services.mozilla.com/D240948
This code has been broken in content processes since e10s; i.e. we currently fire doc load complete events for iframes, even if the parent doc is still loading.
Rather than returning to the pre-e10s behaviour, this check has been removed instead for several reasons:
1. Mac wants AXLayoutComplete to be fired on iframes and we map that from doc load complete.
2. We've been doing this since e10s (3+ years) and it doesn't seem to have hurt any screen readers, so presumably, this has been fixed in screen readers.
3. This check can never work for OOP (Fission) iframes, since the parent document is in a different process and we thus can't query its loading state.
4. The behaviour is currently inconsistent between parent process documents and content process documents. Removing this check makes it consistent.
Differential Revision: https://phabricator.services.mozilla.com/D109582
When a local document is added, we fire a reorder event in DocAccessible::DoInitialUpdate.
This doesn't work for top level documents in remote content processes because the embedder (OuterDocAccessible) is in a different process.
We already handled this for out-of-process iframe documents in DocAccessibleChild::AddChildDoc.
However, there was no code to do this for a top level remote document.
This wasn't a problem for users for normal browser tabs, since clients only interact with the document when it gets focus.
It was problematic for <browser> elements embedded in a parent process content document, since some clients need the event in order to pick up the embedded content.
Therefore, we now fire this event in DocManager::RemoteDocAdded.
This patch re-enables browser_test_docload.js, which is intended to test this.
This test was ported in bug 1376857 before we shipped e10s.
It didn't work with e10s at the time, so it was disabled there, but this was never fixed.
That meant that once e10s shipped, this test was disabled completely.
I had to change the test's expectations slightly, since we do fire document load complete and state change events for remote iframe documents, but the test asserted that we don't.
Although we originally didn't fire these events many years ago, this has been broken for a long time now and it doesn't really make sense to reinstate that behaviour; see bug 1700362.
Differential Revision: https://phabricator.services.mozilla.com/D244687
This keeps id retrieval code in one place: the accessibility engine.
It thus fixes some edge cases that were previously broken; e.g. SVG documents.
It would have been nice to remove these functions altogether and have everything use the id property directly.
Unfortunately, some code depends on getAccessibleDOMNodeID returning null when an accessible has died, rather than throwing an exception.
Changing all the impacted callers to catch exceptions is a bit ugly, but having the XPCOM function just return null itself in this case seemed like hiding reality.
This way, callers have a choice: they can use the id property directly if they care about the failure case (or if the failure case isn't relevant for their use case), or they can call getAccessibleDOMNodeID if they explicitly want to ignore the failure.
It turns out that some tests were unwittingly relying on the nsIAccessibleDocument interface having been queried on the document accessible by getAccessibleDOMNodeID when waiting for the doc load complete event.
To fix this, the harness now explicitly queries for nsIAccessibleDocument before passing the document to test tasks.
Differential Revision: https://phabricator.services.mozilla.com/D244708
