This was done with the following Python script:
```
import re
cacheConsts = open("accessible/base/CacheConstants.h", "rt").read()
aliases = {
alias: atom
for atom, alias in
re.findall(
r'static constexpr nsStaticAtom\*\s+(.*?)\s+=\s+(nsGkAtoms::.*?);',
cacheConsts
)
}
RE_ATOM = re.compile(r'(fields->SetAttribute|(?:mCachedFields|aFields)->(?:GetAttribute|GetAttributeRefPtr|GetMutableAttribute|HasAttribute|Remove|SetAttribute)(?:<.+>)?)(\(\s*)(nsGkAtoms::[a-zA-Z_]+)')
def repl(m):
# Group 3 is the atom.
alias = aliases.get(m.group(3))
if not alias:
# No alias for this atom. Return input unaltered.
return m.group(0)
alias = "CacheKey::" + alias
# Groups 1 and 2 should be returned unaltered. Group 3 (the atom) is replaced
# with the alias.
return m.group(1) + m.group(2) + alias
for fn in (
# Found with: git grep -l 'ields->'
"accessible/base/CachedTableAccessible.cpp",
"accessible/base/nsAccessibilityService.cpp",
"accessible/base/TextLeafRange.cpp",
"accessible/generic/LocalAccessible.cpp",
"accessible/ipc/DocAccessibleParent.cpp",
"accessible/ipc/RemoteAccessible.cpp",
"accessible/ipc/RemoteAccessible.h",
"accessible/windows/sdn/sdnAccessible.cpp",
):
input = open(fn, "rt").read()
output = RE_ATOM.sub(repl, input)
open(fn, "wt").write(output)
```
Differential Revision: https://phabricator.services.mozilla.com/D184791
This revision removes unnecessary include directives from cpp files in the
accessible/base directory. These suggestions came from the Include What You Use
tool.
Differential Revision: https://phabricator.services.mozilla.com/D182288
1. CachedTextMarker::LineRange: If the line starts with a line feed, it's a blank line and the end boundary is the same as the start boundary, so just return the start for both.
2. TextLeafRange::FindLineEnd: If the origin is the empty last line of a textarea, we actually do want the line starting at the next character, so don't skip forward a character. Also don't skip back to the line feed after the search, since that would be the end of the previous line.
Differential Revision: https://phabricator.services.mozilla.com/D177366
DocAccessibleChildBase::RecvSetTextSelection and RecvScrollTextLeafRangeIntoView constructs TextLeafPoints without null checking the retrieved Accessible.
This can be null if the Accessible was destroyed in the content process but the parent process didn't know about this yet when it sent the request.
TextLeafPoint currently crashes if constructed with a null Accessible.
These DocAccessibleChildBase methods do check the validity of the range, which will be invalid if the TextLeafPoints are invalid.
Therefore, just construct an invalid TextLeafPoint if a null Accessible is given.
Differential Revision: https://phabricator.services.mozilla.com/D176494
I was trying to anticipate all the conditions that would bring us
to a non-text leaf text point in a text selection. But it is hard to
account for other "correct" cases so this assertion should probably just
go away.
Differential Revision: https://phabricator.services.mozilla.com/D173760
This is consistent with other HyperTextAccessible methods such as TextAtOffset.
It allows us to test the new implementation with LocalAccessible.
This is especially useful because we have better test coverage in our HyperText tests than we do in our TextLeafPoint tests.
In fact, running the tests with this change uncovered some bugs which I had to fix here.
First, TextLeafPoint::ComputeBoundsFromFrame was preferring to stick to the end of the first frame when on a boundary, rather than using the next frame.
For example, if we had the text "a\nb" where "b" is split into a continuation, offset 2 "b" was previously using the primary frame instead of the continuation.
This isn't a problem in HyperTextAccessible::GetBoundsInFrame because it walks to the next continuation if needed, since it is dealing with a range of offsets.
This is fixed by preferring the beginning of the next frame instead.
Second, passing the text length as the offset (i.e. one past the last character) should return a 0 rect.
TextLeafPoint::CharBounds needed to be tweaked accordingly.
Third, if TextLeafPoint returns a 0 rect (e.g. because a RemoteAccessible doesn't have a cache yet), HyperTextAccessibleBase needs to respect that and return it untouched.
Differential Revision: https://phabricator.services.mozilla.com/D172533
Table rows and cells are now treated as paragraph boundaries.
Whether a cell should be a paragraph boundary is debatable, but currently, a cell is treated as a line boundary, so this is consistent; a line shouldn't expand beyond a paragraph.
Differential Revision: https://phabricator.services.mozilla.com/D172079
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