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
nsISelectionListener isn't sufficient because it only notifies that the selection has changed.
A11y needs to know specifically which ranges were added or removed.
Previously, we handled this specifically for spelling errors in mozInlineSpellChecker.
That code has been removed and replaced with a more general approach.
Since we now have these notifications, rather than using nsISelectionListener just to fire events, we now use these notifications for that as well.
This avoids the need to add additional nsISelectionListeners, which would get messy particularly for custom highlights where there can be an arbitrary number of selections at any given time.
Differential Revision: https://phabricator.services.mozilla.com/D217068
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
`eContextMenu` event may be fired from `widget`. Therefore, different from
`ePointerClick` and `ePointerAuxClick`, they may cross the process boundary,
may be handled by APZ and may be dispatched into the DOM after a delay.
Therefore, this patch is complicated than the previous patch. This adds
* New IPC message handlers for sending/receiving a `WidgetPointerEvent`
* New `DelayedPointerEvent` class and templated `MouseInput::ToWidgetEvent`
* `PresShell::EventHandler` handles `eContextMenu` as same as `WidgetMouseEvent`
Differential Revision: https://phabricator.services.mozilla.com/D213003
1. HyperTextAccessibles already cache language and RemoteAccessible::Language uses this.
2. Previously, we didn't cache language for a non-text, non-HyperText Accessible at all. This includes images and HTML radio buttons. Now we cache it as a top level attribute in this case and return it in RemoteAccessible::Language.
3. We previously cached language for a text (leaf) Accessible where the language differed from its parent, but we never used this in RemoteAccessible::Language, only when calculating text attributes. Now we use it in RemoteAccessible::Language as well.
4. Where a text (leaf) Accessible's language is the same as its parent, RemoteAccessible::Language now gets this from the parent.
Differential Revision: https://phabricator.services.mozilla.com/D212503
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
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
`PresShell::GetRootScrollFrameAsScrollable()` is equivalent to
`PresShell::GetRootScrollContainerFrame()`.
In ScrollContainerFrame.h, `DecideScrollableLayer()` has two versions, one has
four parameters, and the other has five parameters with the fifth parameter
`aDirtyRectHasBeenOverriden` having a default value `nullptr`. When we switch
the caller from `nsIScrollableFrame` to `ScrollContainerFrame`, we need to
remove the default value for the fifth parameter to avoid ambiguity.
Differential Revision: https://phabricator.services.mozilla.com/D211494
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
As per the comments it isn't supported with cache-the-world on, it's
barely documented if at all, and a test for it seems to be failing
without me being able to reproduce it at least (tried on both windows
and Linux).
I don't think it's worth digging too much more into it. My guess is a
reentrant / differently timed a11y event caused by my scheduling
changes, or so, which would override sEventTargetNode or the other
static bool.
The test has ~always failed on macOS too...
Differential Revision: https://phabricator.services.mozilla.com/D210872
When we create a TextLeafAccessible for a CSS pseudo-element, we already use the alt text if present.
However, it seems layout sometimes re-renders the text of pseudo-elements.
Previously, a11y would update the text in this case like it would for any other TextLeafAccessible, thus overwriting the alt text with the text rendered by layout.
To fix this, we now skip updating text if CSS alt text is present.
Differential Revision: https://phabricator.services.mozilla.com/D211139
This revision updates outdated comments in nsTextEquivUtils that refer to
previous names for steps of the Accessible Name and Description Computation
specification. It updates the comments to the new, named computation steps.
Additionally, this revision cleans up and adds other comments to make reading
the code a bit easier.
Differential Revision: https://phabricator.services.mozilla.com/D211110
The Acc Name spec requires that UAs should only follow aria-labelledby and
aria-describedby IDREFs "if [...] the current node is not already part of an
ongoing aria-labelledby or aria-describedby traversal." It also requires
that "[e]ach node in the subtree is consulted only once." This revision
implements these rules and updates relevant tests, including removal of WPT
expected-fail designations. The concept of sInitiatorAcc has been expanded - we
now track all referenced accessibles. We also track whether we're in an
aria-labelledby or aria-describedby traversal.
Differential Revision: https://phabricator.services.mozilla.com/D209617
As well as plain strings, alt text items can get their text from an attribute on the Element.
We need to include the values of those attributes when we compute alt text.
In addition, we must watch for changes to these attributes and update the accessibility tree or fire events as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D210018
CSS alt text makes most sense for an image.
However, even when the content property specifies text, you can still specify alt text!
To support this, this patch does two things:
1. Uses the alt text for the TextLeafAccessible instead of the primary text.
2. Tweaks nsTextEquivUtils to use the alt text when gathering text from a subtree.
As with the last patch, changing the CSS content replaces the pseudo-element, which in turn replaces the Accessible with a new one, so we don't need any additional code to handle updates.
Differential Revision: https://phabricator.services.mozilla.com/D210017
Previously, a11y did get notified about CSS images, but we chose not to create Accessibles for them.
This patch allows us to create an ImageAccessible for a CSS image if it has alt text.
Since there is now an Accessible, the previous patch will then mean that Accessible::Name will return the CSS alt text.
Changing the CSS content replaces the pseudo-element, which in turn replaces the Accessible with a new one, so we don't need any additional code to handle updates.
Differential Revision: https://phabricator.services.mozilla.com/D210016
This allows us to check for alt text and also to output all of it to a string.
For now, this only supports plain strings, but this will be extended in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D210014
Without this, a new source file introduced in a subsequent patch causes the compiler to become confused about which TreeWalker we mean: a11y::TreeWalker or dom::TreeWalker.
I don't really understand why this starts happening, but I'm guessing it is related to our unified builds.
Differential Revision: https://phabricator.services.mozilla.com/D210013
There's no call to AddRefreshObserver(FlushType::Layout), so we don't
need to track layout flushes. The only reason we need
mLayoutFlushObservers is so that reflows triggered from the style flush
get processed. But at that point, we can just flush layout directly.
There's no really good distinction between style flushes and layout
flushes with container queries anyways, so this makes the code simpler
to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D209924
This doesn't change behavior on its own, but it's likely we want to make
the tab focusability more complicated in bug 1895184, and this will make
changes to this area less painful.
Differential Revision: https://phabricator.services.mozilla.com/D209525
We return the implicit role in ARIATransformRole, but that doesn't change the role map entry.
However, ApplyARIAState uses the role map entry to figure out what states are relevant.
To fix this, ApplyARIAState now checks for this case and gets the correct role map entry before applying states.
Differential Revision: https://phabricator.services.mozilla.com/D208855
This revision reverts the changes that trimmed non-breaking spaces from the
start and end of accessible names. The web platform group has decided that
those tests weren't valid as-is; the correct behavior is not to trim those
characters. This revision also removes expected-fail designations from
affected tests.
Differential Revision: https://phabricator.services.mozilla.com/D208687
Since SVG elements aren't in a markup map, Gecko doesn't check for them when
searching markup maps while determining whether to create an accessible in
display:contents contexts. This revision addresses the problem by factoring out
the SVG creation code and using it in two places - newly in the dislay:contents
code. This revision also removes expected failures from relevant web platform
tests.
Differential Revision: https://phabricator.services.mozilla.com/D207943
This revision implements the ARIA rowgroup role in Gecko. Previously, Gecko was
using roles::GROUPING for multiple types of groups and disambiguating them
in various places. This revision unwinds that while maintaining present
functionality.
Differential Revision: https://phabricator.services.mozilla.com/D205671
James Teh
Otto Länd
Sylvestre Ledru
acseh
Nathan LaPre
Masayuki Nakano
Morgan Rae Reschenberg
Ting-Yu Lin
Sebastian Hengst
Emilio Cobos Álvarez
Thomas Wisniewski