This is purely refactoring in preparation for allowing print documents to have a set of cache domains which is different to the global set.
The free functions DomainsAreActive and RequestDomainsIfInactive are turned into methods on DocAccessibleParent, and a new EffectiveCacheDomains accessor is added on both DocAccessible and DocAccessibleParent.
The original DomainsAreActive free function remains because it's still required by PlatformShouldTrackFocusedAccLocation on Mac, and passing a DocAccessibleParent to that is awkward.
Differential Revision: https://phabricator.services.mozilla.com/D299959
The current mozilla::ScrollAxis struct in PresShellForwards.h isn't a simple
axis enum. It carries information about where to scroll to along a specific
axis, and under what conditions that should happen. So 'ScrollAxis' isn't the
best name.
Now we're introducing WebIDL 'ScrollAxis' in bug 1350457:
https://drafts.csswg.org/scroll-animations-1/#scrolltimeline-interface
The extensive use of PresShellForwards.h's ScrollAxis in DOM code makes it
conflict with this new DOM enum. Rather than try to fix this through lots of
explitic namespacing, this patch renames PresShellForwards.h's ScrollAxis.
Differential Revision: https://phabricator.services.mozilla.com/D293485
Firing a caret event for an Accessible which doesn't have focus confuses clients, who expect that the caret should be related to the focus.
Prior to bug 2006816, this wasn't as bad because even though we fired the caret event on the wrong Accessible, TextLeafPoint::GetCaret still returned the caret from the focused document.
After bug 2006816, we use the cached caret, so the event and the retrieved caret are both (consistently) incorrect.
To fix this:
1. Make it possible to update the RemoteAccessible cache for the caret via IPDL without firing a caret event.
2. When the caret moves, don't fire a caret event unless it's within the focused document.
3. However, the caret event won't be fired again when the document eventually gets focused, so we still send an IPDL message to update the cached caret in the RemoteAccessible tree.
4. In TextLeafPoint::GetCaret, only use the cached caret if the cached caret Accessible is within the same document as the origin Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D282330
This was breaking Text Cursor Indicator when typing into an impacted text box.
This was caused by a cascade of problems:
1. Previously, we explicitly never set mIsEndOfLineInsertionPoint to true at the start of a paragraph. This is exactly the case we're dealing with here and that behaviour is incorrect. Instead, we now have a much narrower check for the specific exception we're trying to detect: the start of the editor.
2. GetCaretRect vertically aligns the rect to the top of the line. To do this, it relies on mIsEndOfLineInsertionPoint being set correctly, which it wasn't previously. Thus, GetCaretRect was using the first character on the next line, resulting in a rect with negative height.
3. UIA calls TextLeafRange::LineRects, which clips the bounds to the content area. Since the caret rect previously had negative height, it was clipped completely and removed. Thus, UIA previously returned no bounds at all.
All of this is fixed by correctly setting mIsEndOfLineInsertionPoint in this case.
Differential Revision: https://phabricator.services.mozilla.com/D281126
nsTextEquivUtils is for name and description calculation, where we want to consider things like aria-label, compress whitespace, etc.
However, a text box value should reflect the actual text content as closely as possible, just like text APIs; i.e. it shouldn't compress whitespace if it isn't compressed in the visual rendering, nor should it consider things like aria-label.
This required a slight tweak to the editable text tests, since a cleared contentEditable gets a line feed padding character which is exposed as text content but was previously stripped by nsTextEquivUtils.
Differential Revision: https://phabricator.services.mozilla.com/D279971
This reverts commit 763c1c8083.
Revert "Bug 2010498 part 3: For LocalAccessible, use textbox value calculation for HTML text input/textarea, AKA HTMLTextFieldAccessible. r=morgan"
This reverts commit 1dc286a790.
Revert "Bug 2010498 part 2: Use the text content from the subtree when calculating the value of role=textbox/contentEditable, not nsTextEquivUtils. r=morgan"
This reverts commit 70ca939007.
Revert "Bug 2010498 part 1: Add a11y browser tests for value of <input>, <textarea> and <input type="password"> elements. r=morgan"
This reverts commit ecc02c2433.
nsTextEquivUtils is for name and description calculation, where we want to consider things like aria-label, compress whitespace, etc.
However, a text box value should reflect the actual text content as closely as possible, just like text APIs; i.e. it shouldn't compress whitespace if it isn't compressed in the visual rendering, nor should it consider things like aria-label.
This required a slight tweak to the editable text tests, since a cleared contentEditable gets a line feed padding character which is exposed as text content but was previously stripped by nsTextEquivUtils.
Differential Revision: https://phabricator.services.mozilla.com/D279971
Previously, it used HyperTextAccessible::CaretOffset on the origin container, then ToTextLeafPoint on that offset.
However, offsets can only refer to a direct child.
This meant that ToTextLeafPoint was descending into the direct child using offset 0; i.e. returning the start of the child's content.
This was completely incorrect when the caret wasn't at the start of the child's content.
To fix this, first try using the caret cached by SelectionManager, as that avoids redundant transformation of the caret for each descendant.
If that fails, traverse using CaretOffset on each descendant until we can't go any further.
Differential Revision: https://phabricator.services.mozilla.com/D276963
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
Previously, UIA had its own code to use the caret rect for the end of line insertion point or a line feed at the end of a textarea.
However, this didn't account for an empty text box.
To fix this, now that we have unified code in TextLeafRange to use the insertion point in all cases where it is necessary, use that instead of UIA specific code.
This involved moving the call to TextLeafPoint::InsertionPointBounds from TextLeafRange::Bounds to TextLeafRange::WalkLineRects, since UIA uses TextLeafRange::LineRects, not TextLeafRange::Bounds.
Differential Revision: https://phabricator.services.mozilla.com/D263045
As mentioned in the bug this method does not return bounds for special insertion points.
The bounds are probably correct 90% of the time, the exceptions are transition points in embedded bidi segments,
among other unforseen situations. These edge cases are things we can probably live with for the time being.
This addition also has a few changes:
1. HyperTextAccessible::TextBounds now returns bounds for identical start and end offsets.
2. TextLeafRange::Bounds now returns the insertion point for a collapsed range.
3. The browser caret rect test now uses the insertion point rect to compare against the caret rect.
Differential Revision: https://phabricator.services.mozilla.com/D259134
As mentioned in the bug this method does not return bounds for special insertion points.
The bounds are probably correct 90% of the time, the exceptions are transition points in embedded bidi segments,
among other unforseen situations. These edge cases are things we can probably live with for the time being.
This addition also has a few changes:
1. HyperTextAccessible::TextBounds now returns bounds for identical start and end offsets.
2. TextLeafRange::Bounds now returns the insertion point for a collapsed range.
3. The browser caret rect test now uses the insertion point rect to compare against the caret rect.
Differential Revision: https://phabricator.services.mozilla.com/D259134
As mentioned in the bug this method does not return bounds for special insertion points.
The bounds are probably correct 90% of the time, the exceptions are transition points in embedded bidi segments,
among other unforseen situations. These edge cases are things we can probably live with for the time being.
This addition also has a few changes:
1. HyperTextAccessible::TextBounds now returns bounds for identical start and end offsets.
2. TextLeafRange::Bounds now returns the insertion point for a collapsed range.
3. The browser caret rect test now uses the insertion point rect to compare against the caret rect.
Differential Revision: https://phabricator.services.mozilla.com/D259134
For example: `content: "" / "alt"`
In this case, a pseudo-element is created, but there is no text child.
Previously, we only exposed CSS alt content for a pseudo-element on its child.
To fix this:
1. Teach CssAltContent to work when a pseudo-element itself is provided, not just a pseudo-element's child.
If a pseudo-element *does* have a child, we ignore the pseudo-element itself because we still want to use the child where possible.
A pseudo-element itself is not a replaced element, so we also need to skip the frame IsReplaced check for this case.
2. Create a TextLeafAccessible for a pseudo-element itself if appropriate; i.e. it has no children and has CSS alt text.
3. Don't assume that a TextLeafAccessible is backed by a DOM text node in TextLeafRange code, since a TextLeafAccessible might now have a pseudo-element as its DOM node.
4. Teach TextLeafAccessible to return role STATICTEXT if its node is a pseudo-element.
Differential Revision: https://phabricator.services.mozilla.com/D256946
As of bug 1901457, the TextLeafPoint constructor can no longer receive TEXT_OFFSET_CARET.
However, a related check was never removed from the constructor.
Remove this check and assert that this offset is never provided.
This is just a correctness fix that makes the code easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D256398
As of bug 1901457, the TextLeafPoint constructor can no longer receive TEXT_OFFSET_CARET.
However, a related check was never removed from the constructor.
Remove this check and assert that this offset is never provided.
This is just a correctness fix that makes the code easier to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D256398
In bug 1951573, I unified the code for setting the caret.
This includes focusing the node at the caret.
Unfortunately, Windows Narrator behaves badly if the focus is changed as a result of setting the caret.
Chromium doesn't move the focus if the caret is moved via UIA, even though it does for caret navigation like Firefox.
ATK in particular still wants the focus to be changed.
Therefore, add an aSetFocus argument to TextLeafRange::SetSelection so this can be configured by the caller.
Change UIA to specify aSetFocus = false.
Differential Revision: https://phabricator.services.mozilla.com/D252030
Previously, both literal line feed characters in pre-formatted text and HTMl <br> elements returned a rect with 0 width and/or height.
Because of the way CharBounds() was implemented, this also returned 0 for x and y.
This caused problems for clients such as Windows Text Cursor Indicator which need the rectangle for the character at the caret.
Now, we return the correct x and y coordinates.
We also return a minimum width and height of 1 to ensure clients treat it as an actual rectangle.
As part of this, CharBounds() has been refactored slightly for consistency and readability.
As a bonus, this also fixes character bounds for list item bullets (bug 360003), but a test for that will be added in a subsequent patch.
This patch also removes the special case line feed code added to TextLeafRange::WalkLineRects() in bug 1946552, since CharBounds() now handles this.
Differential Revision: https://phabricator.services.mozilla.com/D249709
A TextLeafPoint is always a leaf Accessible and an offset within that Accessible.
When a TextLeafPoint is created for the end of a container and the last Accessible in the container isn't text (e.g. it is an image), TextLeafPoint represents this as offset 1 within the image.
When calculating a DOM point for such a TextLeafPoint, we need to use the child index for the next DOM node.
This indicates to DOM that the point should be positioned after the node.
Differential Revision: https://phabricator.services.mozilla.com/D247874
For text nodes, DOM points use the character offset within the node itself, just like accessibility does.
For non-text nodes, DOM points use the child index within the parent to specify the position before or after the node.
Previously, TextLeafPoint::ToDOMPoint always used an offset within the node itself.
This meant that when the (exclusive) end point of a range was an image, we converted to a DOM point of offset 0 within the image.
As far as DOM is concerned, this includes the image.
This patch adjusts ToDOMPoint as appropriate.
As part of this, ToDOMPoint now returns a uint32_t instead of an int32_t.
This is because DOM offsets are actually uint32_t and calculating int32_t child indices is deprecated.
Differential Revision: https://phabricator.services.mozilla.com/D247873
I previously thought that CaretAssociationHint::Before was only used either at the start of a node or at the end of a line.
However, it can also be used if the user clicks any character other than the first in a text node.
To fix this, check if we're at the start of a line for all offsets, not just offset 0.
I didn't do this originally in an attempt to reduce the cases where we must search for lines, but it seems this is unavoidable.
If we run into performance problems here, we might be able to restrict this check to cases where we're at the start of a layout frame.
However, that significantly complicates the code, I'm not entirely certain it will work and it is likely premature optimisation, so I opted not to do that in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D241770
There are multiple problems and inconsistencies in the way we previously calculated text bounds in various places:
1. TextLeafRange::WalkLineRects and TextLeafRange::Bounds calculated bounds inclusive of the range end. However, everywhere else, range ends are exclusive.
2. To compensate for this, HyperTextAccessibleBase::TextBounds walked back 1 character from the end before calling TextLeafRange::Bounds. However, other callers (UIA and Mac) didn't do this. Including the range end meant we included the bounds for an additional character or even an entire line in some cases.
3. When lines end with a line feed character, we tried to include this in the bounds calculation. Since line feeds have a 0 rect, this messed up the calculation.
4. Even though WalkLineRects constrained line bounds to the end of the range, the provided sub-ranges were not constrained.
To fix these problems, TextLeafRange::WalkLineRects and TextLeafRange::Bounds now explicitly return bounds and sub-ranges constrained to, but exclusive of, the end of the range.
HyperTextAccessibleBase::TextBounds has been updated accordingly.
The line feed character is ignored when calculating line bounds.
Co-authored-by: Nathan LaPre <[email protected]>
Differential Revision: https://phabricator.services.mozilla.com/D237142
HyperTextAccessible::SetSelectionRange (used by SetCaretOffset) performed these tasks, but TextLeafRange::SetSelection didn't.
This meant that the behaviour when setting the caret or selection was different for different OS APIs: IA2 and ATK use HyperTextAccessible::SetCaretOffset, while Mac and UIA use TextLeafRange::SetSelection.
While we aren't aware of any specific bugs impacting users, this is confusing at best and might result in obscure bugs in future.
See the code comments for details.
Differential Revision: https://phabricator.services.mozilla.com/D240275
Previously, a caller had to first retrieve all selection ranges and then remove them individually.
This makes it awkward to perform a fairly common operation.
Differential Revision: https://phabricator.services.mozilla.com/D240274
James Teh