Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessibility regressions in the 21H1 inbox console #9239

Closed
codeofdusk opened this issue Feb 21, 2021 · 7 comments
Closed

Accessibility regressions in the 21H1 inbox console #9239

codeofdusk opened this issue Feb 21, 2021 · 7 comments
Labels
Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting

Comments

@codeofdusk
Copy link
Contributor

Environment

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd] 19043.844
Windows Terminal version (if applicable): inbox conhost

Any other software? NVDA

Steps to reproduce

  1. Open inbox conhost.
  2. Press NVDA+control+z to open the Python console.
  3. Enter nav.is21H1Plus

Expected behavior

True is returned, as in OpenConsole commit 12b12d5.

Actual behavior

False is returned, as in 20H2 inbox, indicating a regression from #4495.

Additional context

For testing, I've replaced conhost with OpenConsole on my system, but reverted to inbox before applying the 21H1 update. Perhaps Windows Update didn't install the new inbox conhost on my system?

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Feb 21, 2021
@codeofdusk
Copy link
Contributor Author

Cc @carlos-zamora.

@DHowett
Copy link
Member

DHowett commented Feb 22, 2021

Can you check the file version (right click, properties) for conhost.exe?

I am not sure how NVDA’s is21H1 function determines whether it is in fact 21H1... but I didn’t believe we had control over that.

Certainly we have made 0 changes to conhost in 21H1. I wasn’t even aware there was a 21H1 publicly available.

@codeofdusk
Copy link
Contributor Author

See the implementation of is21H1Plus here.

21H1 inbox on my system is acting as if #4495 was never merged (obviously false) or regressed between the above-linked commit and shipment in Windows.

@codeofdusk
Copy link
Contributor Author

Version number is 10.0.19641.746

@DHowett
Copy link
Member

DHowett commented Feb 22, 2021

That doesn’t seem right. I’ll need to check the build when I get back to the office tomorrow, but 19641 corresponds to a version of Windows from two development cycles ago, numerically, and would not contain any of our recent UIA fixes.

Just so you know: 21H1 is a patch release from the servicing team, and they did not contact us about releasing any conhost changes. I have no reason to believe that the code in conhost 21H1 is any different from 20H1, which was the last non-patch upgrade that brought in a whole new tree of Windows code indiscriminately.

@DHowett
Copy link
Member

DHowett commented Feb 22, 2021

The versions of Windows that take your computer down for 10-75 minutes and reboot three times tend to contain the entire development tree from the OS repository before they’re snapped. The builds that increment the UBR or patch version, or the ones that increment the main version by 1 (so, from 19041 to 19042 or 19043) are servicing updates that have hand-selected features backported into them. Since we were not hand-selected for those releases, no conhost changes are present in 20H2 or 21H1.

@DHowett
Copy link
Member

DHowett commented Feb 22, 2021

Discussed this with @codeofdusk off GitHub. The changes we were targeting for "21H1" did not get selected for the build that was released in the early half of 2021. We'll regroup here, but there's no regression per se. Just a lack of ... progression? I guess?

@DHowett DHowett closed this as completed Feb 22, 2021
feerrenrut pushed a commit to nvaccess/nvda that referenced this issue May 17, 2021
Fix for microsoft/terminal#9239

Summary of the issue:
Windows 10 21H1 has been released to insiders with significantly reduced scope (i.e. excluding the UIA changes it was originally set to include), making our internal names misleading. Additionally, there are plans to "undock" conhost from Windows, removing the guarantee that a given Windows version will run a particular version of the console (it's technically already possible to run newer console on older Windows, I do it for testing).

Description of how this pull request fixes the issue:
Renames:
- NVDAObjects.UIA.winConsoleUIA.is21H1Plus -> NVDAObjects.UIA.winConsoleUIA.isImprovedTextRangeAvailable
- NVDAObjects.UIA.winConsoleUIA.consoleUIATextInfo -> NVDAObjects.UIA.winConsoleUIA.ConsoleUIATextInfo (Start class name with upper case)
- NVDAObjects.UIA.winConsoleUIA.consoleUIATextInfoPre21H1 -> NVDAObjects.UIA.winConsoleUIA.ConsoleUIATextInfoWorkaroundEndInclusive
  - The implementation works around both end points being inclusive (in text ranges) before microsoft/terminal#4018
  - Workarounds for expand, collapse, compareEndPoints, setEndPoint, etc

Also moves the text override to the workaround textInfo as #10036 is no longer reproducible in new console.
Co-authored-by: Reef Turner <reef@nvaccess.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting
Projects
None yet
Development

No branches or pull requests

2 participants