New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 786220 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug
Team-Accessibility



Sign in to add a comment

Affinity should be maintained when calling an IAccessibleText API and the start offset is equal to the caret offset

Project Member Reported by nek...@chromium.org, Nov 17 2017

Issue description

1. Start NVDA or Jaws (any version).
2. Load this URL:
data:text/html,
<textarea cols="3">
abcdef
</textarea>

3. There should be three lines in the textarea:
"abc"
"def"
<blank line>

4. Position the caret on the first line and press End.
5. Read the current line using Insert+Up or corresponding laptop layout key.

Expected:
"abc" is read.

Actual:
"def" is read instead.

Cause:
Affinity is not maintained when IAccessibleText::get_textAtOffset(...) is called with a start offset that is equal to the caret offset. Since the start offset is the same as the location of the caret and since the location of the caret is incomplete without affinity, it should be retrieved and passed to AXPosition.

 
Project Member

Comment 1 by bugdroid1@chromium.org, Nov 22 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dfd053adb7bb52aa31cc536c883f27767daaabc1

commit dfd053adb7bb52aa31cc536c883f27767daaabc1
Author: Nektarios Paisios <nektar@chromium.org>
Date: Wed Nov 22 17:59:24 2017

Ensures that affinity is maintained in AXPosition while traversing down the tree to find a leaf equivalent position

It turns out I didn't test the case when the leaf node that is equivalent to the existing position is not an immediate child, but a deeper descendant. See added unit test on "root" instead of only the "text_field".
Also, I don't see the need to reset affinity on the leaf node since keeping it as upstream doesn't hurt. It was my aggressive resetting to defaults that caused the bug in the first place.
See the bug for a sample HTML that demonstrates the bug.
R=dmazzoni@chromium.org, aleventhal@chromium.org

Bug:  786220 
Change-Id: Ica2f360c286301841146072b2272cb6ebe17cb05
Tested: manually with a narrow textarea and text that wraps, unit test
Reviewed-on: https://chromium-review.googlesource.com/777474
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518677}
[modify] https://crrev.com/dfd053adb7bb52aa31cc536c883f27767daaabc1/ui/accessibility/ax_node_position_unittest.cc
[modify] https://crrev.com/dfd053adb7bb52aa31cc536c883f27767daaabc1/ui/accessibility/ax_position.h

Comment 2 by nek...@chromium.org, Nov 22 2017

Status: Fixed (was: Started)

Sign in to add a comment