nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
Other
2.08k stars 625 forks source link

Chromium Edge address bar cursor does not announce "blank" at the end of the address bar #11393

Open KurtCattiSchmidt opened 4 years ago

KurtCattiSchmidt commented 4 years ago

Hi, I'm an engineer on the Microsoft Edge team who works on our UIA implementation. I came across this bug and was looking to see what if there's anything we can do our side to fix this. However, from my initial investigation, the bug may actually be in NVDA.

Steps to reproduce:

  1. Launch Chromium-based Edge and NVDA
  2. Type "test" in the address bar
  3. Move the cursor to the right via the arrow keys until the cursor is at the end of "test"
  4. Continue to press the right arrow key

Actual behavior:

"t" is announced repeatedly

Expected behavior:

"Blank" is announced repeatedly

This is unexpected, because for HTML inputs, "blank" is usually announced by NVDA upon reaching the end of a text input. This is the behavior in other applications (like Notepad), so this may indeed be a bug with Edge's UIA implementation. This seems to be an important indicator for users that they've reached the end of the address bar, so we'd love to get this addressed.

I was able to add logging to Edge and (possibly) correlate it with the NVDA code where it's going wrong:

Here's NVDA's log upon one of the repeated 't' announcements: Speaking [CharacterModeCommand(True), LangChangeCommand ('en_US'), 't', EndUtteranceCommand()]

Here's what my logs are saying for Edge around this time:

BEGIN ExpandToEnclosingUnit start: text_offset=4 affinity=downstream annotated_text=test<>
BEGIN ExpandToEnclosingUnit end: text_offset=4 affinity=downstream annotated_text=test<>
END ExpandToEnclosingUnit start: text_offset=3 affinity=downstream annotated_text=tes<t>
END ExpandToEnclosingUnit end: text_offset=4 affinity=downstream annotated_text=test<>

So you can see that the text range is correctly at the end of the word "test" (see the first two BEGIN lines, indicating a degenerate range at the end of the word 'test' - text_offset 4 for both start and end), but when ExpandToEnclosingUnit(character) is called, we correctly move the text range from being a degenerate range at the end of the address bar, to a range that captures the last character (see how the 'text_offset' for 'start' is moved from 4 to 3). This is the character that's being announced, instead of "blank".

I'm not clear why this call to ExpandToEnclosingUnit is being called from NVDA here, but this appears to be the source of this bug. Any help would be greatly appreciated!

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2020.1

Windows version:

Windows 10 version 1909

Name and version of other software in use when reproducing the issue:

Microsoft Edge | 86.0.578.0 (Official build) canary (64-bit)

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

No

If addons are disabled, is your problem still occuring?

Yes

Did you try to run the COM registry fixing tool in NVDA menu / tools?

Yes

Adriani90 commented 4 years ago

Hmm, I think this must be fixed in the browser is I am not wrong. The browser should expose when the line has ended and when there is a line feed or so. Then NVDA would report "blank" as expected. @ObjectInSpace I think this problem has been solved in Chrome as well. Maybe you can advice here? cc: @aleventhal

ObjectInSpace commented 4 years ago

My understanding is that Chrome currently uses IAccessible2. If you turn on the --enable-experimental-UI-automation commandline flag, NVDA doesn't speak the address bar at all. So I wouldn't say this is fixed in Chrome, but it does not reproduce there.

KurtCattiSchmidt commented 4 years ago

@ObjectInSpace, agreed - this issue doesn't reproduce in Chrome, even with the --enable-experimental-UI-automation flag. Chrome's address bar implementation is different than Edge.

In general, that flag is intended to test web-platform UIA behavior (which should be equivalent between Edge and Chrome). But for browser UI, they are not equivalent, even with the --enable-experimental-UI-automation flag.

It's definitely possible that this is a bug in Edge's UIA implementation, and if so I'd love to narrow it down fix it there. The closest I've gotten is that call to ExpandToEnclosingUnit from NVDA that I mentioned in the bug report, which seemed to be behaving as expected from Edge's side. But perhaps something is going wrong before that call.

Adriani90 commented 4 years ago

@KurtCattiSchmidt I think NV Access can assist you in this. cc: @michaelDCurran or @feerrenrut