Open KurtCattiSchmidt opened 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
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.
@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.
@KurtCattiSchmidt I think NV Access can assist you in this. cc: @michaelDCurran or @feerrenrut
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:
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:
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