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
1. When constructing a TextLeafPoint and searching for a leaf, do not descend inside an OuterDoc (iframe/browser).
Otherwise, we end up inside another document.
Other TextLeafPoint code avoids crossing document boundaries, so the constructor must do this too.
2. When searching for a leaf, include an OuterDoc, but don't walk inside it.
Previously, we skipped OuterDocs altogether.
This meant that if you started on an OuterDoc, walking backward and then forward by character would never return you to your origin.
Also, clients walking the document text shouldn't just skip iframes altogether, so exposing them as a single character makes more sense.
This fixes infinite loops in OffsetAtPoint when querying a container with an iframe at the end.
Differential Revision: https://phabricator.services.mozilla.com/D158740
We already have an nsISelectionListener, but that only tells us that a change happened somewhere in the selection, not which range changed.
We don't want to push a cache update for all ranges when only one changed.
Therefore, this patch adds an accessibility notification in mozInlineSpellChecker::AddRange.
We don't need this for removed ranges because the text will change for any spelling error corrections and text updates trigger spelling error cache updates.
Differential Revision: https://phabricator.services.mozilla.com/D147244
Even though spelling errors can cross Accessibles and are represented in the DOM as ranges, we cache them for each text leaf.
This is necessary so that we correctly update the offsets when text is inserted or removed from a leaf.
We cache them as an array of offsets, including both the start and end offset for each range.
We use -1 as the start offset to indicate when a spelling error starts in a previous Accessible.
When a spelling error starts in an Accessible but ends in a subsequent one, we simply don't include an end offset in the array.
This structure means we can easily query spelling error points or ranges with a binary search.
Differential Revision: https://phabricator.services.mozilla.com/D147243
The implementation searches for spelling errors in each leaf, as this is how we will need to do it for RemoteAccessibles.
Differential Revision: https://phabricator.services.mozilla.com/D147242
This was done for LocalAccessibles to avoid the need to fetch attributes twice when we're simultaneously fetching boundaries and returning the attributes to a client.
However, GetTextAttributes will soon handle spelling errors, so it will no longer return the same data as GetTextAttributesLocalAcc (which doesn't handle spelling errors).
This breaks the equality checks in FindTextAttrsStart.
Aside from this, this argument was somewhat confusing.
For now, just remove aOriginAttrs, which means there will be some redundant calls to GetTextAttributesLocalAcc.
Parent process documents shouldn't be that large anyway.
If this ends up being a real problem, we can either revert to the local HyperTextAccessible implementation of text attributes or implement a smarter temporary cache.
Differential Revision: https://phabricator.services.mozilla.com/D147241
For block frames, nsLineIterator doesn't use the line cursor, so switch to nsBlockInFlowLineIterator.
We don't actually care about the line number here anyway.
Differential Revision: https://phabricator.services.mozilla.com/D147237
The code checks whether the origin is inside the block, since if not, the block ends before the origin.
However, it previously didn't handle the case where there was a leaf outside the block between the block and the origin.
An additional check has now been added to handle this case.
This required the code to be restructured somewhat, which hopefully also makes it easier to read/debug.
Differential Revision: https://phabricator.services.mozilla.com/D145867
For pre-formatted text, the content text and rendered text are the same.
Therefore, there's no point calling nsIFrame::RenderedText, which is quite slow for nodes containing a large chunk of text.
This improves performance significantly when caching line start offsets for large plain text files such as logs.
Differential Revision: https://phabricator.services.mozilla.com/D145080
For pre-formatted text, the content text and rendered text are the same.
Therefore, there's no point calling nsIFrame::RenderedText, which is quite slow for nodes containing a large chunk of text.
This improves performance significantly when caching line start offsets for large plain text files such as logs.
Differential Revision: https://phabricator.services.mozilla.com/D145080
The code previously returned failure for array index 0, but it did this for both movement directions.
It should only do this for eDirPrevious, since we decrement index in that case.
Differential Revision: https://phabricator.services.mozilla.com/D144785
The code previously returned failure for array index 0, but it did this for both movement directions.
It should only do this for eDirPrevious, since we decrement index in that case.
Differential Revision: https://phabricator.services.mozilla.com/D144785
Previously, we were always comparing with the primary frame of the previous leaf.
If the previous leaf crossed lines, this meant we incorrectly reported that the following leaf started a new line even if it didn't, since the primary frame of the previous leaf was always on a different line.
Now, we use the last continuation (line) of the previous leaf.
This way, if the next leaf continues the final line of the previous leaf, they will have the same line number and so we won't incorrectly report that the next leaf starts a new line.
Differential Revision: https://phabricator.services.mozilla.com/D144781
There is no base class for local (DocAccessible) and remote (DocAccessibleParent) documents, so this adds nsAccUtils::GetAccessibleByID.
Differential Revision: https://phabricator.services.mozilla.com/D141207
There is no base class for local (DocAccessible) and remote (DocAccessibleParent) documents, so this adds nsAccUtils::GetAccessibleByID.
Differential Revision: https://phabricator.services.mozilla.com/D141207
BOUNDARY_WORD_END is implemented using BOUNDARY_WORD_START and adjusting for spaces, which are word end boundaries.
This is arguably less efficient than it could be, since we will walk over space and then reverse course to compensate.
However, the alternative would mean keeping two slightly different versions of the word boundary check code in sync, plus compensating for the fact that a word often ends before a line start while still supporting words split by line wrapping.
I felt the lower complexity here outweighed the potential slight loss in efficiency.
We can always revisit this if this turns out to be a real problem.
Differential Revision: https://phabricator.services.mozilla.com/D138105
BOUNDARY_LINE_END is implemented using BOUNDARY_LINE_START and adjusting for line feed characters, which are line end boundaries where present.
Differential Revision: https://phabricator.services.mozilla.com/D138103
These bugs cause problems for the upcoming implementation of BOUNDARY_LINE_END.
1. Don't always return no character at the caret. Only do that if the caret is at the end of the line. This was always the intent; this was just a silly mistake.
2. When moving to the next character in an Accessible, don't move past the last character. This was a simple off-by-one error.
Differential Revision: https://phabricator.services.mozilla.com/D138102
Jan-Niklas Jaeschke
James Teh
Morgan Rae Reschenberg
Eitan Isaacson
criss
Jonathan Kew
Butkovits Atila
smolnar