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

Issue 831179 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 1
Type: Bug
Team-Accessibility



Sign in to add a comment

AXPosition should set an upstream affinity when computing a parent equivalent position that happens to be at the end of the line

Project Member Reported by nek...@chromium.org, Apr 10 2018

Issue description

This issue is accessibility related and is affecting email composition in Gmail, hence Pri1.
Steps:
Open Gmail and compose a new email. Type the word "Hello", press enter and type the word "there".
Move up and press End to put the caret at the end of the first line.
Observe that if you use the Read Line command, e.g. Insert+Up for Jaws or NVDA, the second line is read instead of the first.

Technical details:
<div contenteditable>hello<div>there</div></div>
The above snippet produces text that spans two lines.
If we set a text position on the static text object containing the word "hello" at offset 5, i.e. after the last letter, the affinity is correctly set to downstream, since there is no confusion as to the fact that the text position is at the end of the first line. Upstream affinity is only used when the position is ambiguous, not every time the position is at the end of a line.
If we compute a parent equivalent position , we might need to set the affinity to upstream because ambiguity would be introduced. For example, a text position on the outer div at position 5 might indicate the beginning of the inner div, hence the start of the second line, or the end of the word "hello" and hence the end of the first line.
Resolution:
Either always set an upstream affinity when at the end of a line or always recompute affinity when computing parent equivalent positions.
I am leaning towards the latter approach.

 
Project Member

Comment 1 by bugdroid1@chromium.org, Apr 25 2018

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

commit a1a7bcba7ea8b9d6009f1577dc923121121593d6
Author: Nektarios Paisios <nektar@chromium.org>
Date: Wed Apr 25 22:27:50 2018

Recompute affinity if parent equivalent position is ambiguous.

If a line break is introduced implicitly, i.e. because there is one block layout node next to the other, there would be two leaf positions:
One is at the end of the first layout node at the end of the line and the other at the beginning of the second block node at the start of the next line.
Both positions will have a downstream affinity, because there is no ambiguity as to which position is at the end vs. the start of the line.
However, when computing the parent equivalent position, and since there is no line break in the text of the parent, affinity will need to be computed on the browser side.
Also, I made some fixes which maintain predictability as to which affinity will be assigned to computed positions, regardless of the input position.

R=dmazzoni@chromium.org

Bug:  831179 
Change-Id: I425223bee1f53654ddaaa045a375c6da0367b7a8
Tested: Unit tests
Reviewed-on: https://chromium-review.googlesource.com/1028181
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553794}
[modify] https://crrev.com/a1a7bcba7ea8b9d6009f1577dc923121121593d6/ui/accessibility/ax_node_position_unittest.cc
[modify] https://crrev.com/a1a7bcba7ea8b9d6009f1577dc923121121593d6/ui/accessibility/ax_position.h

Project Member

Comment 2 by bugdroid1@chromium.org, May 23 2018

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

commit f3ae656ad80fbec934c4d1e6648c0cd4ff030127
Author: Nektarios Paisios <nektar@chromium.org>
Date: Wed May 23 23:29:25 2018

Expose anonymous editable blocks to a11y

Anonymous blocks were not correctly marked as editable and richly editable in Blink and thus unnecessarily ignored affecting selection on Windows.

R=dmazzoni@chromium.org

Bug:  831179 
Change-Id: Ic53ad29e63d7e9bbfd775ce5f933f20e7ea656f5
Tested: Layout test
Reviewed-on: https://chromium-review.googlesource.com/1004925
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561308}
[add] https://crrev.com/f3ae656ad80fbec934c4d1e6648c0cd4ff030127/third_party/WebKit/LayoutTests/accessibility/editable-anonymous-block.html
[modify] https://crrev.com/f3ae656ad80fbec934c4d1e6648c0cd4ff030127/third_party/WebKit/LayoutTests/accessibility/inline-continuations-expected.txt
[modify] https://crrev.com/f3ae656ad80fbec934c4d1e6648c0cd4ff030127/third_party/WebKit/LayoutTests/accessibility/inline-continuations.html
[modify] https://crrev.com/f3ae656ad80fbec934c4d1e6648c0cd4ff030127/third_party/blink/renderer/modules/accessibility/ax_layout_object.cc
[modify] https://crrev.com/f3ae656ad80fbec934c4d1e6648c0cd4ff030127/third_party/blink/renderer/modules/accessibility/ax_layout_object.h

Comment 3 by nek...@chromium.org, May 24 2018

Status: Fixed (was: Started)

Sign in to add a comment