Change:
Type: <bBug</bWindows 10, screen reader is NVDA, most recent insider build, as of December 13, 2022. The first time I start vscode for the day, after a short time (about 3 minutes), my screen reader stops speaking. If I press nvdaKey+tab (read current focus), it says "setup", but nothing else and I can't do anything. If I cancel out, I get back to vscode, but now every minute or so, my keyboard locks up, again with no speech. The only way now to get things going again is to switch away from vscode via alt+tab, then back again. I cannot see the screen, so cannot give any more info, but I'll bet whatever that setup window that came up first was, it's coming up again... Sorry I can't be more specific... VS Code version: Code - Insiders 1.75.0-insider (, 2022-12-13T05:22:12.417Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I cannot reproduce this. I am wondering if you are not in mode. Can you check the value of in your settings and make sure it's set to ?
I can verify this issue, also with NVDA on Windows 10. It occurs both with the latest insiders and with the production 1.74.0. And yes accessibility support is enabled. The symptom is usually that the screen reader simply stops reading anything after a period of time, and it can be temporarily fixed by minimizing the window or switching to another then going back to vscode. I've also had the symptom where it will keep reading the same line after consecutive down or up arrow presses even though the cursor is clearly moving to the next or previous line. cc:
Symptoms point to running with experiment as the cause. Can you try starting with and see if the issue persists ?
Disabling that feature seems to have no effect. The problem persists. I'm also noticing that I can get NVDA to start reading again if I switch context (e.g. stops reading in file editor, switch to terminal then back, reading usually resumes).
I also have this problem in stable version 1.74. In many occasions I can't read the current line. In addition to losing focus, when returning from another window, the file browser and line navigation, when it works, becomes much slower. I have to restart NVDA every time that happens and it fixes it, but it is annoying and interrupts a lot of work. I would appreciate a quick solution please
Running new build with potential fix for testing, will update here once the builds are available.
Can you test if the issue persists with the following insiders build, please make sure turn off updates temporarily in your settings with
These are terrible bugs i've encountered on production 1.74. The most annoying one for me was NVDA were trying to read whole document from top to bottom when ever I press up or down arrow. With the given insider 1.75 link above, it looks fine for now. It also feels a bit faster than the usual vscode, out of topic.
Thanks for filling this issue. I tried to reproduce with latest Insiders, NVDA on my Win10 VM and I could not repro, here are my steps. on NVDA, VS Code insiders the repo in VS Code Insiders this file in VS Code Insiders up / down arrow for 7-8 minutes inside the file. Notice how NVDA reads everything even after all that time can you tell me what am I missing in this steps? Also can you try with the build provided . That would really help us to understand this better since we cannot yet reproduce the problem on our side.
I have not tested with insider, but in stable, if you press ctrl + shift + e to go to the file explorer, leave it still for a while, you can no longer do anything and it is necessary to change window. When I go back to the VS Code window, sometimes I can't read the lines, it reads the whole file from the beginning, and besides that, NVDA takes a long time to move through some controls. For example, when expanding a folder in the file explorer. All this is solved if I restart NVDA. But it is something I have to be doing very frequently to be able to work well. As I was saying, this happens to me in the latest stable version. I will try the above solution. Thanks
The above solution solves the performance problems I have been having for a long time when starting VS Code. It seems that the line reading problem has been solved as well. However, when I leave the focus on the file browser for a minute or so, the problem persists and nothing else can be done. If I press ctrl + shift + e and switch contexts, the focus returns, but now I have lower performance with NVDA, which causes me to have to restart the screen reader anyway. Thanks
After some time, I have been able to verify that it is still not resolved, but it does not happen in all cases. The performance issues in VS Code at startup seems to be the only thing that was fixed, apparently. I hope you can keep and merge the changes from the above proposed solution because now I don't have to restart the screen reader after starting VS Code, which is much nicer. However, the other two problems still persist. Standing still for about a minute in the file explorer results in not being able to focus on anything. The line problem I can now only reproduce with an extension, but it uses the same Monaco editor as VS Code. Install eamodio.gitlens extension. Now, focus the file explorer and look for a file with the arrows. Press shift f10 and scroll down to open file history. Then, choose any commit and press enter, then f6 to go to the editor that opened. There the lines do not read well. For example, given this file from a Ruby on Rails application: Pressing up arrow or down arrow always reads this, except in the last line that reads blank: Thanks
I just installed the build posted above: VSCodeUserSetup-x64-1.75.0- and now, everything works as expected. The screen reader no longer locks up on me every minute or so! This is great... Hopefully, this will give the team enough information to track down this bug! I will leave updateMode set to "none" until I hear that this bug has been squashed. Thanx for the fix! -- Rich
I investigated further and the problem was indeed solved. While changing "" to none VS Code downloaded the update. I uninstalled and reinstalled and everything is fine. Thank you very much! I hope you can release this solution quickly, as I can't use this specific code-insiders version with WSL. Try to install but I get 404 error.
I agree that your test build seems to have solved the issue and navigation feels crisper and more responsive. Please update insiders and also a patch release to 1.74 since this does not work with WSL or devContainers.
thanks for confirming the fix, it will be available in Insiders today. Can you also respond to comment in about any missing steps which will help us on our end to verify the fix. Thanks! We just had a patch release yesterday , you should be able to use the normal insiders with the fix on both WSL and devcontainers until we make a release. Also, we will need the steps to verify if we want to make a patch release to stable. I will update here again once the fix is available with Insiders.
Insiders has been released with the fix, you can get insiders from
the steps are in this , for the line reading and freezing problem Thanks for the solution!
FOr me, the problem would occur when I was simply navigating the interface. It was most apparent, and seemed to be triggered more quickly, when navigating a menu like view (alt+v, then up/down arrows). Question: I'm seeing behavior that I've never seen in other menus -- if I open view with alt+v, navigate via downArrow, escape out of the menu, then come back in with alt+v, it almost never focuses on the first menu item, but somewhere in the middle. Is this intentional? Thanx for all the work on this! -- Rich
I cannot say I noticed a repeatable pattern, but it was much more likely to occur when navigating around the UI in areas like the explorer, settings, extensions, menus, etc. than just staying within a single file. So it doesn't surprise me that steps did not reproduce the issue.
Closing since we have pushed a fix for this. Adding a verified label based on users confirming the issue is indeed fixed (since we can not reproduce ourselves). If some users can it would also be helpful to verify with the stable build that is about to come out in the next 24 hours. Here's the links to the build depending on your platform darwin: darwin-arm64: darwin-universal: linux-arm64: linux-armhf: linux-deb-arm64: linux-deb-armhf: linux-deb-x64: linux-rpm-arm64: linux-rpm-armhf: linux-rpm-x64: linux-snap-x64: linux-x64: win32: win32-archive: win32-arm64: win32-arm64-archive: win32-arm64-user: win32-user: win32-x64: win32-x64-archive: win32-x64-user:
Yes, it's also fixed in 1.74.2.

Discussion:
*/ app.commandLine.appendSwitch('disable-features', 'CalculateNativeWinOcclusion'); <del> /* Following features are enabled from the runtime. * `AutoDisableAccessibility` - https://github.com/microsoft/vscode/issues/162331#issue-1390744354 */ app.commandLine.appendSwitch('enable-features', 'AutoDisableAccessibility'); </del> // Support JS Flags const jsFlags = getJSFlags(cliArgs); if (jsFlags) {