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
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
The caret can be at the end of a wrapped line, but this does not have its own offset.
In this case, the way we handle the caret depends on what is being queried.
For character, we want to return no character at the position of the caret.
For word and line, we want to return the word/line before the caret.
To facilitate this conditional treatment, we use a special TextLeafPoint which represents the caret.
This is then actualized to a real point depending on the method called.
Differential Revision: https://phabricator.services.mozilla.com/D132095
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
With the rewrite, we reduce the dependency of lwbrk LineBreaker::Next(),
WordBreaker::Next(), and their `int32_t` sentinel values
NS_LINEBREAKER_NEED_MORE_TEXT and NS_WORDBREAKER_NEED_MORE_TEXT.
Differential Revision: https://phabricator.services.mozilla.com/D130392
