For example, one of the frames could be in the block's main in-flow line list and the other could be in an overflow list.
When this happens, it's not valid to compare LineIterators, so we must compare the line lists first.
Differential Revision: https://phabricator.services.mozilla.com/D218613
This is now simply a matter of leveraging the work in the previous patches to support the new selection type and map it to the correct attribute.
There isn't an IAccessible2 or ATK attribute for this yet.
We use mark:true, based on <mark> and role="mark" which is used for a semantic highlight.
I've discussed this with Google, NV Access and Vispero and they all seem to be happy with this.
Differential Revision: https://phabricator.services.mozilla.com/D217071
Previously, this code was specifically tied to the spell check selection.
Actually adding more selection types will come in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D217066
An array of ints is fine for spelling errors, but we need to support multiple attributes like this.
We could use an array of ints for each attribute and search each one, though that would require more work in the parent process.
Also, custom highlights can have multiple selections for a single highlight type.
This would be rather messy with int arrays, especially where multiple selections span beyond the Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D217065
This doesn't matter for spelling errors.
However, we will soon generalise this code for use with other attributes like this.
In particular, custom highlights require us to use AbstractRange.
While we aren't supporting custom highlights in this bug, it is more effective to do this as part of this major refactor rather than doing another refactor later.
Differential Revision: https://phabricator.services.mozilla.com/D217063
Previously, we assumed that CaretAssociationHint::Before always meant the caret was at the insertion point at the end of a line.
However, it can also mean that the caret is before the start of a node in the middle of a line.
To fix this, we need to check for line and paragraph boundaries.
See the code comments for details.
I moved this functionality completely out of HyperTextAccessible and into TextLeafPoint.
First, it was easiest to do these checks with private functions already available to TextLeafPoint.
Second, this ideally belongs in TextLeafPoint anyway; its existence in HyperTextAccessible was vestigial.
Differential Revision: https://phabricator.services.mozilla.com/D215089
Previously, we assumed that CaretAssociationHint::Before always meant the caret was at the insertion point at the end of a line.
However, it can also mean that the caret is before the start of a node in the middle of a line.
To fix this, we need to check for line and paragraph boundaries.
See the code comments for details.
I moved this functionality completely out of HyperTextAccessible and into TextLeafPoint.
First, it was easiest to do these checks with private functions already available to TextLeafPoint.
Second, this ideally belongs in TextLeafPoint anyway; its existence in HyperTextAccessible was vestigial.
Differential Revision: https://phabricator.services.mozilla.com/D215089
Previously, TextLeafPoint::GetCaret() returned a placeholder representation of the caret.
ActualizeCaret() was then used to get the real caret position, optionally adjusting for the line end depending on the caller's needs.
This causes problems when we need to store the TextLeafPoint information in a UIA text range object because the only way to indicate the line end insertion point is to use the GetCaret() placeholder, but that also means the stored position changes if the caret moves.
For example, if you disabled NVDA's "caret moves review cursor" setting and then moved the caret, the review cursor should stay at the old position, but it didn't previously.
To fix this:
1. TextLeafPoint now has a new mIsEndOfLineInsertionPoint flag which is set to true by GetCaret() if appropriate.
2. GetCaret() sets mAcc and mOffset immediately, rather than needing to call ActualizeCaret() later.
3. TextLeafPoint methods still need to adjust the point to correctly handle the line end insertion point in some cases, but that is now handled by the private TextLeafPoint::AdjustEndOfLine method.
4. FindBoundary now correctly returns the previous character/cluster when requested for this end of line insertion point. Strictly speaking, this bug always existed, but no existing callers ever triggered it.
Differential Revision: https://phabricator.services.mozilla.com/D214342
We already did this for BOUNDARY_CHAR, but i neglected to update this for cluster in bug 855184.
Without this, FindBoundary with BOUNDARY_CLUSTER on a caret TextLeafPoint when the caret is at the end of a line would return the last cluster instead of no character.
Differential Revision: https://phabricator.services.mozilla.com/D214341
Most OS APIs want a cluster when they ask for a "character", except ATK.
Rather than altering BOUNDARY_CHAR, I added a new BOUNDARY_CLUSTER.
Aside from being less risky and causing less churn, there are cases internally where we want to move a TextLeafPoint by character; e.g. to explicitly move to the next/previous Accessible or to move to the next/previous character in an abstract way without worrying about Accessible boundaries.
Calculating clusters is more expensive, so it doesn't make sense to move by cluster in those cases.
Differential Revision: https://phabricator.services.mozilla.com/D212517
Continuations occur when text wraps onto a new line (fluid continuations), but they also occur when the text direction changes (non-fluid continuations).
Previously, TextLeafRange assumed that all continuations were line breaks.
Now, we explicitly treat fluid continuations as line breaks.
It's also possible for a non-fluid continuation to be on a different line if the text direction changes between the end of the previous line and the start of another.
In that case, we must use a line iterator to check whether they are on different lines.
Differential Revision: https://phabricator.services.mozilla.com/D210893
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
James Teh