It is possible for a DOM selection to start or end within an empty container.
In this case, we have offset 0 in an empty HyperTextAccessible.
This caused two problems.
First, DocAccessibleParent::SelectionRanges previously treated a range as invalid (and thus skipped it) if the offset was >= the character count in the container.
While this usually makes sense, it is problematic for empty containers.
To fix this, always treat offset 0 as valid.
Second, GetChildAtOffset returns null when called on an empty container with offset 0, since there's no child for it to return.
Previously, TextRange::Crop wasn't handling this, resulting in a crash.
To fix this, just use the start/end container itself if GetChildAtOffset returns null.
Differential Revision: https://phabricator.services.mozilla.com/D254467
Previously, we called Crop on every range.
Among other things, that has to calculate common parents, which gets very slow with lots of ranges.
Since the selection ranges are sorted by position in the document, we can binary search to find the overlapping ranges instead.
This required a fix to TextPoint::operator<, which previously returned an incorrect result when comparing a descendant point with an ancestor point.
Differential Revision: https://phabricator.services.mozilla.com/D233622
There was already a code path to handle siblings, but this only applied if the boundary child at the range's start/end (often a text leaf) was a sibling of aContainer.
It didn't apply if aContainer was a direct sibling of the range's start/end container.
To fix this, don't restrict the code which handles the case where aContainer does not contain the start/end boundary.
This should always fail to crop, regardless of the ancestry.
Differential Revision: https://phabricator.services.mozilla.com/D139351
Even though we'd ideally be using TextLeafRange for new things, TextRange is still needed by our selection events (which still use HyperText offsets) and IA2/ATK clients which depend on HyperText offsets.
Thus, we need TextRange to support RemoteAccessible.
Although the start and end containers are HyperTextAccessibles, I chose to store Accessible rather than HyperTextAccessibleBase because HyperTextAccessibleBase doesn't inherit from Accessible and having an Accessible is easier.
XPCOM needs to hold a reference to any state objects.
Because we can't hold a reference to an Accessible (due to RemoteAccessible), xpcAccessibleTextRange holds references to xpcAccessibleHyperText instead.
Differential Revision: https://phabricator.services.mozilla.com/D139341
This class needs to be updated to support base Accessible and it doesn't make sense to port methods that can never be used.
Also, any new functionality (e.g. needed for the UIA text pattern) should now be implemented using TextLeafPoint/Range, not TextRange.
Differential Revision: https://phabricator.services.mozilla.com/D139340
It's an internal API corresponding to `Selection.getRangeAt` DOM API.
I think that it should use `uint32_t` rather than `size_t` because of the
consistency with the DOM API and `Selection::RangeCount()`.
This patch fixes all callers of `GetRangeAt()`, and rewrites it with ranged-
loops unless original ones do not refer `RangeCount()` every time and may run
script in the loop.
Differential Revision: https://phabricator.services.mozilla.com/D128848
This is a collaboration between clang-tidy and clang-format.
clang-tidy uses compiled code paths, so this patch is linux specific.
Differential Revision: https://phabricator.services.mozilla.com/D105669
This includes 3 changes:
1. Add a lazy ranges getter to AccTextSelChangeEvent.
2. Create an XPCOM interface for testing purposes.
3. Add IPDL bindings for passing ranges in e10s.
Differential Revision: https://phabricator.services.mozilla.com/D80556
Sylvestre Ledru