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

Issue 731067 link

Starred by 2 users
Status: Fixed
Owner:
█ nek...@chromium.org
Last visit > 30 days ago
Closed: Aug 2017
Cc:
█ hdodda@chromium.org
dmazz...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug
Team-Accessibility



Sign in to add a comment

Accessible line offsets incorrect for insertion point after backspacing line feed on last line

Project Member Reported by ja...@nvaccess.org, Jun 8 2017 
Chrome Version: 61.0.3122.0 (Official Build) canary(64-bit)
OS: Windows 10 Version 1703 (OS Build 16199.1000) 64-bit

What steps will reproduce the problem?

(1) Start Chrome and the NVDA screen reader.
(2) Open this URL: data:text/html,<textarea></textarea>
(3) Type "1".
(4) Press enter, then press backspace. The insertion point will be after the "1".
(5) Press NVDA+upArrow (laptop layout: NVDA+l) to read the current line.

What is the expected result?
NVDA should say "1"

What happens instead?
NVDA says "blank"

After step (3), the accessible text line offsets for offset 1 are (0, 1), which is correct. After step (4), the text is back to what it was in step (3) as far as the user is concerned. However, the line offsets for offset 1 are now (1, 1). The point after the end of the text should be considered to be part of the last line, just as it was before the line feed was inserted and deleted.

Impact: While editing, this causes the last line to be reported as blank in many cases when it isn't, which is misleading at best for Chrome + NVDA users.

Comment 1 by nek...@chromium.org, Jul 12 2017

Cc: dmazz...@chromium.org
Components: -UI>Accessibility UI>Accessibility>Compatibility
Status: Started (was: Untriaged)
Bug identified and patch uploaded for review.

Comment 2 by dmazz...@chromium.org, Jul 21 2017 

After typing 1:

id=4 textField value="1"
  id=5 genericContainer
    id=6 staticText name="1"
      id=7 inlineTextBox name="1"
    
After typing enter:


id=4 textField value="1\n"
  id=5 genericContainer
    id=6 staticText name="1"
      id=7 inlineTextBox name="1"
    id=8 staticText name="\n"
      id=10 inlineTextBox name="\n"
    id=9 lineBreak

After pressing backspace:

id=4 textField value="1"
  id=5 genericContainer
    id=6 staticText name="1"
      id=7 inlineTextBox name="1"
    id=9 lineBreak
Project Member

Comment 3 by bugdroid1@chromium.org, Jul 21 2017 

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

commit ca0c10d91f6dfe41938c371f761cc5780ce15eec
Author: Nektarios Paisios <nektar@chromium.org>
Date: Fri Jul 21 17:35:03 2017

Blink doesn't always remove deleted whitespace at the end of textareas from the shadow DOM.

This results reading "blank" in some cases, when in fact the line contains text.
R=dmazzoni@chromium.org
TESTED=Manually using Jaws, existing unit tests

Bug:  731067 
Change-Id: I3c74e7c42a5178b5900df12e361e61cce318f0dc
Reviewed-on: https://chromium-review.googlesource.com/575684
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#488692}
[modify] https://crrev.com/ca0c10d91f6dfe41938c371f761cc5780ce15eec/ui/accessibility/ax_position.h
Project Member

Comment 4 by bugdroid1@chromium.org, Jul 27 2017 

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

commit 023b42abe8ca3803a6a993e96f3044e47995181f
Author: Nektarios Paisios <nektar@chromium.org>
Date: Thu Jul 27 23:43:12 2017

Fixed the way we were calculating the previous anchor position in AXPosition.

Jaws and NVDA were announcing the first line of the previous paragraph if the cursor was on the line break between two paragraphs.
BUG= 731067 
TESTED=manually with Jaws and NVDA

Change-Id: I8e13ee866ff56895457f3423b00a3dced8be885d
Reviewed-on: https://chromium-review.googlesource.com/568465
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Nektarios Paisios <nektar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490122}
[modify] https://crrev.com/023b42abe8ca3803a6a993e96f3044e47995181f/ui/accessibility/ax_position.h

Comment 5 by hdodda@chromium.org, Jul 28 2017

Cc: hdodda@chromium.org
Labels: TE-Verified-62.0.3169.0 TE-Verified-M62
Verified the issue on windows 10 using chrome M62 #62.0.3169.0 and issue seems fixed.with the below steps :

1. Launched NVDA(2017.1)/ Jaws(18.0.2530.400) and chrome.
2. Redirected the chrome to url "data:text/html,<textarea></textarea>"
3. Typed 1 and then enter -> backspace -> uparrow and observed that NVDA/Jaws read as 1.

Hence adding the TE-Verified labels.

Thanks!

Comment 6 by dmazz...@chromium.org, Aug 4 2017

Labels: triage-nektar

Comment 7 by dmazz...@chromium.org, Aug 4 2017

Labels: triage-aaron

Comment 8 by nek...@chromium.org, Aug 4 2017

Status: Fixed (was: Started)

Comment 9 by nek...@chromium.org, Aug 4 2017

Labels: -triage-aaron -triage-nektar
►

Sign in to add a comment