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 shouldn't happen, but the COM runtime seems to do this sometimes.
I can't reproduce it and I haven't been able to fathom what causes it.
I suspect a Windows bug or a bug in some third party software.
This leads to trying to check the UIA pref from the wrong thread, which is not allowd and causes a crash.
Differential Revision: https://phabricator.services.mozilla.com/D248558
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
In modern C++, static constexpr member variables are automatically
inline (aka weak) so the template trick is not needed. This also avoid
duplication and reduces the amount of parsed code. No impact on
generated binary (actually: smaller debuginfo, close to identical
binary).
Differential Revision: https://phabricator.services.mozilla.com/D247825
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
When a UIA client first queries us, the accessibility engine hasn't yet been initialised.
Previously, this also meant that we hadn't yet called InitConsumers() to figure out which Windows clients were present.
This in turn meant that we would initially believe UIA should be enabled, even if we later realised NVDA/a Vispero product was present and then believed it should be disabled.
To fix this, call InitConsumers() appropriately if it hasn't been called yet.
Even with the above fix, the following scenario might still be possible:
1. UIA is enabled.
2. A client QueryInterfaces to IRawElementProviderSimple.
3. UIA gets disabled.
4. Only then does the client try to call a method on IRawElementProviderSimple.
In this scenario, LazyInstantiator::MaybeResolveRoot won't set mWeakUia, but the IRawElementProviderSimple method will try to use mWeakUia, causing a crash.
To fix this, add a new RESOLVE_ROOT_UIA macro used by IRawElementProviderSimple methods.
In addition to calling RESOLVE_ROOT, this also checks mWeakUia and fails gracefully if that is null.
Differential Revision: https://phabricator.services.mozilla.com/D247504
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
Some tests (e.g. Marionette and WPT) can start the accessibility service in a content process without starting it in the parent process.
When this happens, the content process will still send the accessibility tree, events, etc. to the parent process via IPDL, and the parent process will create the RemoteAccessible tree.
However, the accessibility service still isn't running in the parent process unless a client instantiates it.
Previously, nsAccUtils::GetLiveRegionSetting assumed the accessibility service was running without checking.
UIA calls this method when firing certain events, so this was causing a crash.
To fix this, just null check it.
In future, we may wish to consider not firing events if the service isn't running or some other broader solution for this situation, but I don't think it's worth investing in that now, especially as this is only relevant to tests.
I also added an assertion for the presence of the service in nsAccUtils::SetLiveContainerAttributes.
Because this is only used for setting attributes, callers already check that the service exists before calling this, but an assertion should help enforce this.
Differential Revision: https://phabricator.services.mozilla.com/D244275
This issue is a possible crash case.
Actually `SessionAccessibility.NativeProvider.setAttached` is called in
C++ constructor of `SessionAccessibility`. But native handle is set
after calling the constructor. So when `NativeProvider.setAttached` is
called, C++ side might not set native handle yet.
So we should not call `setAttached` in the constructor.
Differential Revision: https://phabricator.services.mozilla.com/D246070
