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
Previously we checked if the announcement was a child of the root acc directly, but it's not clear this worked reliably since we've done `GetObjectOrRepresentedView` for a while, which (should) return the view instead of the root acc. This patch also:
- Dispatches the announcement from NSApp instead of NSWindow, since per chrome and safari notifs fired on non-main windows get dropped
- Modifies the announcement priority from medium to high, so VO interrupts itself to speak this message (this makes the UX more consistent, since the text-inserted/text-deleted notifs from the URL bar seem to occasionally bookend the announcement)
- Updates the browser_app.js test to NOT run in headless mode, since in headless mode NSApp isn't rendered to dispatch the notification. This test contains a task for AXAnnouncementRequested via a11yUtils.announce
Differential Revision: https://phabricator.services.mozilla.com/D206083
`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
In bug 1779578, I changed the way a11y trees are serialised such that the parent id is included for each Accessible.
When de-serialising in DocAccessibleParent::RecvShowEvent, in order to avoid a theoretical performance regression caused by repeatedly looking up the same parent, I added an optimisation to use the last parent if it is the same as the current parent.
Unfortunately, it seems I never actually set the lastParent and lastParentID variables, so this optimisation was a no-op!
This is a micro-optimisation: it doesn't seem to make any observable difference.
However, it seems silly to have effectively dead code and it's a very straightforward fix.
Differential Revision: https://phabricator.services.mozilla.com/D213177
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
Previously we checked if the announcement was a child of the root acc directly, but it's not clear this worked reliably since we've done `GetObjectOrRepresentedView` for a while, which (should) return the view instead of the root acc. This patch also:
- Dispatches the announcement from NSApp instead of NSWindow, since per chrome and safari notifs fired on non-main windows get dropped
- Modifies the announcement priority from medium to high, so VO interrupts itself to speak this message (this makes the UX more consistent, since the text-inserted/text-deleted notifs from the URL bar seem to occasionally bookend the announcement)
- Updates the browser_app.js test to NOT run in headless mode, since in headless mode NSApp isn't rendered to dispatch the notification. This test contains a task for AXAnnouncementRequested via a11yUtils.announce
Differential Revision: https://phabricator.services.mozilla.com/D206083
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
In order to keep all of the tragic implementation detail for this function in a single class, I originally put the structs and the thread proc inside the function.
The thread proc was implemented as a lambda which implicitly converts to a function pointer.
Unfortunately, it seems MinGW can't implicitly convert this lambda to a function with the stdcall calling convention.
This is why we can't have nice things.
To deal with this, refactor it into a class so that we can define the thread proc as a static function instead of a lambda.
All of the methods are static; the class is just used to contain the implementation details.
Differential Revision: https://phabricator.services.mozilla.com/D212391
Querying some pipe handles can cause a hang and there is no way to prevent this other than terminating the thread.
See the discussion on the bug for more details and research.
Therefore, query the pipes in another thread.
If the thread takes too long, terminate it and resume querying other handles in another thread.
Differential Revision: https://phabricator.services.mozilla.com/D212088
Previously we checked if the announcement was a child of the root acc directly, but it's not clear this worked reliably since we've done `GetObjectOrRepresentedView` for a while, which (should) return the view instead of the root acc. This patch also:
- Dispatches the announcement from NSApp instead of NSWindow, since per chrome and safari notifs fired on non-main windows get dropped
- Modifies the announcement priority from medium to high, so VO interrupts itself to speak this message (this makes the UX more consistent, since the text-inserted/text-deleted notifs from the URL bar seem to occasionally bookend the announcement)
- Updates the browser_app.js test to NOT run in headless mode, since in headless mode NSApp isn't rendered to dispatch the notification. This test contains a task for AXAnnouncementRequested via a11yUtils.announce
Differential Revision: https://phabricator.services.mozilla.com/D206083
`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
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
Previously, we listened for changes to the disabled attribute itself.
However, this doesn't handle the case that the disabled state is inherited from a fieldset ancestor.
In contrast, DOM notifies us about changes to ElementState::DISABLED on form control descendants when a fieldset gains or loses the disabled attribute.
Differential Revision: https://phabricator.services.mozilla.com/D211688
`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
Also, simplify some callers of `GetScrollTargetFrame()` to drop
`nsIScrollableFrame*` and unnecessary `do_QueryFrame`. We'll continue removing
more `nsIScrollableFrame*` in later parts.
Differential Revision: https://phabricator.services.mozilla.com/D211490
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
