Verifying Version: 1.55.0-insider Commit: Date: 2021-03-25T16:24:13.227Z clone and open in vscode add a to F5 to run the extension Open an untitled file In the editor's tab, choose from the context menu, pick ! a different notebook is opened, no console log statement printed !
Are you able to open markdown notebooks without issue on non untitled files?
Yes, that works. I also tried to open a GitHub issue notebook on an untitled file and while a notebook seems to open which has a 'Github Issues' cell, the function in the GitHub issue notebook source seems not be called. So I'm a bit confused
I did some investigation with this and I can't reproduce it out of sources. When I select it through the reopen with dialog the notebook service receives the correct viewtype, although it always fails to open with the error . I'm not sure why it is failing as the inputs get created correctly and everything seems to be passing through the right way. Let me know if you want to investigate together.


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --In the source control, after changes are staged and a commit message is provided, it's no more possible to see easily the current branch name to commit to: ! The validation button displays a pop-up message, but this does not really add value: ! I propose to display the current branch name in this pop-up: ! This would dispel any doubts about the branch on which one commits. By the way, the same is possible for the "Publish Branch" button. Is it the right idea?
I'll submit a PR for this.
Whoaww, great, thanks. I had a look on it, mostly for curiosity, but I am very far from vsc dev currently... I will review with pleasure.
It's ready for review.
It looks so easy! Thanks. Do you think the 'Publish Branch' popup should be relooked too? The branch name appears in the commit textfield, but depending of the sidebar size it's not always visible. !
~That makes sense. I'll update the PR.~ I first thought this was stated in the issue description too, but it wasn't. So, we should hear from on this.
It is, at the end:
I guess I have to compile the whole vscode if I want to live test?...
Yes. If it's your first time, I suggest using GitHub Codespaces or dev containers, instead of compiling/running it on your plain OS environment.
I've updated the PR to include the branch name on the "Publish Branch" button, too.
Ok perfect! I first thought the screenshots were from my issue, just as an illustration... But it's yours in live, so I guess it's ok. I will investigate for a dev container, it may be useful for next PR... Thx for that.


Verification steps: Commit action button Open a folder/workspace that contains a git repository using VS Code Insiders Make a change to a file, and save the file Switch to the "Source Control" view and hover over the "Commit" action button Confirm that the tooltip of the action read Publish Branch action button Open a folder/workspace that contains a git repository using VS Code Insiders Create a new branch Switch to the "Source Control" view and hover over the "Publish Branch" action button Confirm that the tooltip of the action read
Hi, Both verification steps are working. Thanks. Version: 1.75.0-insider Commit: Date: 2023-01-20T05:23:42.626Z Electron: 19.1.9 Chromium: 102.0.5005.194 16.14.2 V8: 10.2.154.23-electron.0 OS: Linux x64 6.0.0-0..6-amd64 Sandboxed: Yes
Do we need to submit a PR to include this in the release notes?
Thanks for the nudge. Added


Testing I'm not sure why I have two entries for edit sessions and wonder if it came from another machine/sessions. It would be great to see some metadata about where the source is coming from, similar to the "Synced Data" view for Settings Sync. <img width="394" alt="CleanShot 2022-07-26 at 10 58 31 src="https://user-"<img width="373" alt="CleanShot 2022-07-26 at 11 00 07 src="https://user-"


Following test throws: I found this while investigating At that point the editor component is quite broken because of a lot of errors being thrown. Notice how not even a tab shows for the editor: <img width="1058" alt="image" src="https://user-"
that should already throw because at least a scheme is needed. It doesn't because was designed to be the runtime counter part of which never produces such output so some IPC deserialisation cost can be saved.
, that works for me and will also throw when we get bad objects into such as the from
Yeah, my plan is to add an argument like we have in other URI-places. It will default to true and only IPC should be relaxed
Not doing that because it actually already exists as . I believe the adoption/migration task is to use instead of whenever getting uri components from storage or esp from command arguments. Tho, there is one special case for which is that it automatically uses when the scheme is missing. We could make that configurable but a check for might make this obsolete
Closing this after and the ask to use when creating uri from "untrusted" sources
I will see to adopt , I forgot we had it


The colors we define in code should match our default theme, otherwise there is potential for ugly flickering as seen below: ! Notice how the title bar color changes, the active tab indicator appears late. It feels sluggish and like a UI bug. At one point I think we made "Modern Dark" our default, we I think we did not make a pass over our colors to align them with the colors defined in the theme. We need to ensure that the colors in code match the colors in our default themes, I would argue even for light and HC theme.
I think this should be fixed in May, it looks really bad for first startups.
Is there a reason to do it this way? I think I would have assumed the default dark theme JSON file to be empty (because it does not overwrite any colors) and our colors in code to be matching the default dark theme colors?
We can not change the defaults as all custom themes inherit these. I agree that it's not so nice to duplicate the colors but I couldn't yet come up with a simple solution.
I understand the argument that we cannot easily change the default colors without breaking other themes. But the issue still reproduces even after your change: open a fresh Code-OSS and see how title bar color and tab active indicator only kick in late. Also adding since this covers UI components of his.


VS Code Version: code-oss-dev(1.64.0) OS Version: win10 Steps to Reproduce: vscode web file "w", and click readmore icon at warn suggest label, but show webkitURL details in right panel !


VSCode Version: 1.19.1 In Markdown files, the editor is incorrectly styling every other inner word surrounded by underscores as italicized. The preview correctly shows them as not italicized. !
I think this is what Text Mate grammars' behavior. Tried in TextMate 2.0 (latest), same there. !
I think is right on this. The editor has an error as it interprets the other word as if it was a separate word starting and finishing with `` (that would be italized). It is correctly displayed on Github editor :
I created a PR to fix this


! Two problems: has no contrast and is being displayed over text mouse cursor over it should be Is this you?
We've always had this problem, the bottom part of the icon has no fill hence why the text shows through. The only alternative is to show this in the gutter when the first column of the row has text, but I'm not sure if that is technically possible.
Could we add a white trace outline to the icon, making it popup in messy locations?
Unfortunately strokes don't work on icons: ! We could try to add the same editor bg color with a slight opacity to account for this: !
Oh man, that looks good.


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Setting to stop at the bottom (or top) when navigating in the diff view through the changes with "next change" and reaching the last change. Like did in
Can I provide a PR for this feature
Go ahead.
Thanks a lot for implementing this. But what is the setting to enable this?
Looks like this behavior got to the "" setting
No, does not affect this unfortunately.


Testing Repro: /explain in inline chat to get a long response. using to focus the last response (does not work) to focus the last response using to scroll up in list view of chat messages. (does not work)
Same for panel chat. I believe the keybinding simply isn't bound
You may have to press it twice, once to move the cursor to the top of the editor, and then another time to trigger the chat keybinding, does that work? It's working fine for me.
Oh, not in inline chat though
I can't remember what terminal chat looked like in March, do you still want this disabled? I think we probably want it enabled in all chat widgets now:
I fixed this so that cmd+up/down will work in the terminal and inline chat widgets. But in the terminal, once the list is focused, then the arrow keys still navigate history. It looks like the terminal widget is registering a bunch of its own commands for history and for moving focus around. You shouldn't need to do that anymore, since you can use the commands that the ChatWidget has.


I think we used to indent inline chat to the indentation level of the line: ! Steps: have an indented line press enter to be on an empty line (still indented) press to bring up inline chat


Currently sticky scroll is grouped with the breadcrumbs in the context menu which appears on right click on sticky scroll. Henceforth it should be grouped with it too in the menu. cc


<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.21.1 OS Version: MacOS High Sierra 10.13.3 (17D102) Steps to Reproduce: markdown preview in combination with local plantuml server code to use local server for rendering a markdown with embedded plantUML content error about unsafe content ! The current only allow to enable/disable unsafe (HTTP without the S) entirely. Would it make sense to add an option that allows unsafe content from localhost but not from remote sources?
This may be ok (at least for images): If someone wants to take a look at this, you would just need to update the content security policy to allow :
Looking into it, thanks for the pointer.


Issue Type: <bFeature Request</bTo see the changes i made to a source controlled checked-in file, a user clicks on the "Open Changes" icon on the top right. I would like to see a better looking icon that represents git and changes. The current one looks like a search button. VS Code version: Code 1.29.1 (, 2018-11-15T19:13:36.375Z) OS version: Windows_NT x64 10.0.


This may be useful as a hint: Please, take a two minutes to look into source, it may work only for :
I think adding a desktop file with that launches VS Code with is what's needed to implement this.
nice relevant gist:
VS Code has native support for opening it's own URL scheme via the hidden argument, I don't think there is a need for wrapper script shenanigans. I'm going to submit a PR.
I've not checked too far into it (Just subscribed to this to keep up to date) but the wrapper script is probably there because in the standard would include the "vscode://" prefix.
That's what should happen, that's what handles. :smiley: You can test if you like. Alternatively you can test this (Which is what the PR adds): For OSS: For release version: Drop it into or and run on that directory.


There are some parts in notebook land that depend on . This service and its provider are deprecated and should be removed. As of today the following dependencies must be cleaned up first: , , The should be used instead, it will allow you to know if a agent per location exists or not


run you'll notice that in the main process before creating the renderer the update service takes its time (~5-10ms). while that's not much it seems unnecessary and "block" the renderer for no good reason <img width="1101" alt="Screenshot 2020-01-31 at 14 45 07" src="https://user-"
This is only problematic in macOS where calls into the native which blocks.
Thanks


a traditional . , listen for debugging the extension, open a file picker, then close it. session token's never gets triggered when the session is done (aka when the file picker is closed) :bug: This contradicts
regression from


Testing The type cannot be used with because that requires objects (no primitives). We should accommodate for that and change the API accordingly.


Right now we can do pull but not push with Git's API . We are looking into allowing users to create pull request from the extension but without this API, we can only execute git command ourselves. Not sure about the cost of adding this API, the shape of in my mind can be like .
Fixed by


open normal quick pick () type notice you want symbol search and select the cursor is random, within the word, and doesn't select the previous input anymore


To repro, cause the Ports view to rerender several times. This can be done by trying to set a label and escaping out about 8 times.
is this a bad leak? Like does it leak just 1 listener per interaction or does it grow faster than that?
It grows faster than that, but it's probably only a medium bad leak. After 8 table rerenders there are 175 listeners. After ~5 more table rerenders there are 263 listeners. After ~5 more table rerenders there are 351 listeners. After ~5 more table rerenders there are 439 listeners. A table rerender can be triggered through port auto-forwarding. Once when the process is started and the port is forwarded, and once when the process exists and the port is removed. The number of listeners is depended on the number of ports that have been forwarded. My numbers above are with 3 ports.
No more leak, works as expected -verified


Testing In the screenshot below, "Chat: Insert at Cursor" should be "Chat: Insert into New File" !


Testing There's a double close parenthesis here: <img width="305" alt="image" src=""
Also a missing on the line


<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --I'm working on a Visual Studio Code extension that's supposed to make it easier to clone a git repository in a user configured directory. The basic idea is that the user configures the directory once (e.g.: in ) and then all the cloned repositories will be placed in this directory. The seems the ideal candidate for implementing something like this (especially now with the new ). However, the only problem is that the command is always asking the user for the destination directory. This feature request is about adding an option to the command which would allow other extensions to clone a repository in a specific directory without showing the dialog. One possible implementation could be as simple as adding another optional argument (for the destination directory) to the command ().
Found a quirk:
Fixing the quirk is fine in the future. Thus pushing it out to the On Deck milestone since Joao is on vacation. please speak up if you disagree.
+1 for this issue. I'm also working on a VS Code extension (specifically the C++ extension here in Redmond). We're working on an experience that involves operating on the files in a repository that the user has cloned via the command, but currently there is no way to know which parent directory was selected. Allowing the repository parent directory to be passed in would solve the problem entirely for us -- I'll be watching this issue closely. :slightlysmilingface:
This has been implemented () and you can already use it in Visual Studio Code version .
Thanks
Since this is already implemented I am closign this issue. Thanks As for the quirk can handle as an independet issue
should this issue be labelled with again? I also wonder if the quirk has been filed as a separate issue.


Issue Type: <bBug</bCreating an untitled document (from a file URI amended with the scheme) results in different states depending on whether the document is created with the command or the function. I tried to reduce the problem to a failing test case and failed, but maybe can still be useful for debugging. Create an untitled URI for a new file () Open an editor for that URI with / Type some text Save the file Notice that the save dialog starts with the we had providedCreate a new untitled URI for a new file Open an editor for that URI with Type some text Save the file The save dialog starts with the we had provided, just like with the other method. The save dialog starts with the text we typed instead of the we had provided. VS Code version: Code 1.63.0 (, 2021-12-07T05:16:45.441Z) OS version: Linux x64 5.15.6-200.fc35.x8664 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (38)</summaryExtensionVersion ------ vscode-unfancy-file-icons3.15.0 icons-carbon0.2.4 chalice-icon-theme1.2.16 awk-ide-vscode0.6.2 vscode-fish1.0.24 init-script0.1.3 make-task-provider2.1.1 npm-intellisense1.4.0 path-intellisense2.6.0 vscode-eslint2.2.2 EditorConfig0.16.4 gtk-dark-titlebar1.2.3 vscode-pull-request-github0.34.0 go0.29.0 terraform2.17.0 nix-ide0.1.18 language-julia1.5.6 rust-analyzer0.2.842 git-graph1.30.0 fluent-icons0.0.15 direnv0.3.0 vscode-docker1.18.0 python2021.12. vscode-pylance2021.12.1 jupyter2021.11.


jupyter-keymap1.0.0 jupyter-renderers1.0.4 remote-containers0.209.5 remote-ssh0.68.0 remote-ssh-edit0.68.0 vsliveshare1.0.5196 vscode-commons0.0.6 vscode-yaml1.2.2 edit-with-shell1.3.0 lua2.5.3 even-better-toml0.14.2 shellcheck0.18.2 redo0.1.0 (6 theme extensions excluded) </details<!-- generated by issue reporter --
Looks like when you call we treat the URI as the associated resource: But we do not do the same from
I tried this with the following code: and both files saved to the correct paths... but I wasn't prompted at all by a file dialog. Is that expected?
Yes. Untitled with associated path don't ask for a file name, that is the whole idea of "untitled with associated resource" vs. "untitled without associated resource".


VSCode Version: 1.33.1 OS Version: 10.14.4 When editing and closing a git commit message file very quickly, the contents are not provided to git. Currently I manually save before closing any git commit file but it seems clear this should work properly - autosave should happen, then Code should inform Git that the commit file is ready. Currently it appears the two events are happening in reverse order, causing a bug. Steps to Reproduce: VS Code as editor () a git commit the commit message in Code close the commit message in Code, before autosave occurs Result: git complains about an empty commit message Expected: Autosave should happen before Code releases control back to git, resulting in a properly saved commit message Does this issue occur when all extensions are disabled?: Yes
Good catch. Extra points for using auto save in VSCode :+1:
via


Type: <bBug</bvscode with wsl: or similar tool to monitor CPU usage when vscode is idle or minimized to the taskbar. Expected: CPU usage for vscode's remote server should stay around 0% at idle conditions. Actual: CPU usage stays between 2-10 % VS Code version: Code 1.91.1 (, 2024-07-09T22:06:49.809Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 6.6.36.3-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ remote-wsl0.88.2 material-icon-theme5.6.0 vim1.27.3 markdown-checkbox0.4.0 gitlens15.2.0 prettier-vscode10.4.0 hexeditor1.10.0 advanced-new-file1.2.2 vscode-fileutils3.10.3 even-better-toml0.19.2 </details<!-- generated by issue reporter --
I had earlier opened the issue at where I provided more in-depth issue description. I'm just going to put the same description here. I recently noticed high CPU usage and faster battery drain (intel cpu) when working with any project under WSL. To find out what's taking so much cpu time (even when I'm doing nothing, apart from staring at the screen), I used to list processes in the order of cpu usage: ! Looked like vscode's remote server running inside wsl is taking CPU. So, I went a little further to profile the running instance of the remote server and I found: ! ! from is being called at a regular interval with a small delay (~1000ms). : ! I was able to trace back to : ! And I finally found where it is being called repeatedly: ! Now, why is it a bug? Because I've disabled all related settings in my config, yet the tunnel monitoring service is running in the background. I expect the service to not be running when or related configs are disabled. The service is currently always running.
Wow, great job, thanks for tracking down the problem!
I'm having trouble understanding this: Is WSL going to end up being a ?


I don't think we actually want to show the ports view in WSL even if the Tunnels extension isn't installed.
I agree. For non-managed remote authorities created just via the in the workbench, how did we determine whether or not to show the ports view? We should apply the same logic here...
The ports view is controlled by a context key getting set. It gets set in two ways: an extension that wants the ports view. This is what dev containers does. a tunnel factory getting . Since the tunnel factory is always now, we're always enabling it. I should be able to add a check if the tunnel factory is coming from an extension and only do 2 if that's the case.
Looks like we also show the ports view when there's an extension with an actiation event: Is this perhaps no longer needed with the work you did for tunnels I don't remember exactly why I it.
I've moved the check to happen when there's been a port forwarded.
Looks like this was actually a feature: You can set to disable this. I'm also going to try to improve the description of and .
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
To verify: the descriptions of and . Verify that you can understand what the settings do and how they're related. (These settings may be a bit confusing. We should consider deprecating and only have ) . to or if it isn't already. the WSL extension, connect to a WSL remote. the log level to Trace for the Remote Extension Host. the output for the Remote Extension Host. Verify that you see a steady stream of log lines that say "candidate" coming in. This means that port discovery is on. to and to . Reload. sure that the log level of the Remote Extension Host is still set to Trace the output for the Remote Extension Host. Verify that you DO NOT see a steady stream of log lines that say "candidate" coming in.


In the WSL workspace, I don't see any log lines that say "candidate" even after starting a Python HTTP server.
I can't repro this. Do you have an old version of WSL installed?
I verified that on my machine the work.
I haven't checked with Insider, but in stable I can confirm 'candidate' logs are not visible after Step 6 of the verification steps. Thanks. I also want to point out that it's not clear from the description that there's a process monitoring service running in the background, and that it can be disabled using . Should the default option be instead of ?
Thanks for trying it out If we set it to , then we might end up not showing any ports in the Ports view. In insiders, I updated the text of the setting: Sets the source from which ports are automatically forwarded when is true. When is false, will be used to find information about ports that have already been forwarded. On Windows and macOS remotes, the process and hybrid options have no effect and output will be used. It still doesn't explicitly say there will be process monitoring, but it should be clearer.


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.


<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.29-insider OS Version: Windows 10 Version 1809 (OS Build .1000) Steps to Reproduce: Find in files and search for something that will return results over different result lines Badge and Action button (Dismiss) are on the left (aligned to the end of result text) I'm expecting that Dismiss action will have fixed horizontal position (on the right side) that will allow me to easily dismiss several results entries. With current position at the end of result text I have to constantly move mouse to hit Dismiss button. In stable version both count badge (for file) and Dismiss action were aligned at the right side of the viewlet which was convenient. At this moment it is hard to filter out result entries because texts have different length and button shifts for each line. I've found which says that button should always stay on the right side, however this isn't case in v1.28.2 independently from viewlet width (both badge and actions are on the right side). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <details<summaryScreenshot</summary<div! </div</details
I guess this only applies to the search panel?
Yes, I observe issue in Search panel. UPD. Checked - same behavior when Search: Location is set to sidebar.
You should see the actions on the right when search is narrow, and on the left when it's somewhat wide. The reason is that when the actions are on the right and the text is aligned to the left, it can be hard to associate the two, so it seems more user-friendly to put the actions closer to the actual result. Maybe the threshold could be tweaked, but it doesn't feel good to click an action on the opposite side of the monitor from the actual text. Does this match what you see?
Yes, that match what I see, but makes it harder to use Dismiss action with mouse. For badge with results count - it is good position, since it is visible without hover. On the other hands actions are only visible on hover, when background can clearly indicate what line will be dismissed.


Previously (September and numerous builds before) I was able to put mouse over X and just click (even without looking) several times to remove unnecessary lines. Now it takes more time/attention to do it with mouse, and if next line after dismissed has longer text - it is easy to open file instead of dismissing it. Open editors view (Close editor button), Source control (action buttons for files), Extensions (Manage button) - have static position of actions that are not changed with sidebar width. My cases are 23" monitor with 1920x1080 and Surface Pro 3. Never had problems when action were on the right side. Users with 4k 30+" will have to snipe for X too.
Yes it was broken for a few months, but this was the behavior from before it was broken I see your point but I will leave this open to think about it
thanks!
Putting the dismiss button to the right would also make it less likley that someone presses it by accident which I just did. The middle of a search result might be just above/below the end of another so that clicking just a bit above/below where you intended could lead you to remove the other search result.
Issue 1) The dismiss buttons are too close to the actual text of the search result making it very easy to accidentally dismiss something. Issue 2) The dismiss buttons are invisible until hover/focus. So if you had your focus on another panel or another window and then click on a search result to focus it, it's too easy to click on an invisible button and accidentally dismiss a search result because of issue 1.
Trying to decide whether we should just always right align... but it seems weird to me to have the X really far away from the row content in some cases. Anyway, if someone wants to add a setting to configure this, I would take that PR.


Related: ! A better user experience for blocking/deferring subsequent modal dialogs needs to be implemented.


Open notebook with a header, code cell, and symbols in the code cell: # 1: symbols appear as a child of the header md cell, and the code cell is not present in the outline. # 2: changing the filter settings to remove code cells or symbols does not recompute the outline. Fixes: For # 1: an outline provider was being created with the incorrect target (sticky scroll was created with a QuickPick target), and this was being retrieved for the outline pane incorrectly. For # 2: one of the locations an outline change event is fired was shifted and subsequently removed, meaning that the outline did not recompute to reflect the filtered-out cells.


Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !


I wanted to customize my keybindings depending on the OutputPanel state, but it looks there's no clause to set in the stanza for it.
There is a context , please try that
Ok that works when if focused (but needs to be documented), what about when it's visible?
We accept PRs that update our docs. Checkout the vscode-docs repo. No this is not currently supported, we accept PRs that add this. Code pointers Similar to the viewlet service here The panelPart would add a context key
works but how does a user learn the panel ID?
good point. However we already had that issue with the viewlets, since we already have a "activeViewlet" conext key. We should document this properly


Including all who have commented : New SelectBox implementation: Standard native select allows navigation to an item using the first character. This can be done both on a unexpanded or expanded select. Should this behavior be implemented in the new custom SelectBox ?
yeah good catch I think it should. If the control has focus at least. Please do not assign the "candidate" label to issues. It is reserved for issues we plan to fix in a stable recovery release.
though assigning milestones is usualy a good idea, if you plan to fix this until the end of january just assign to December / January milestone.
Noted on the labeling issues (verified, candidate, milestones), sorry don't know all the workflows :-( Sorry to pepper you with a few more questions: I saw you wrote a draft test plan, would you like me to add some more specificity on keyboard support so people know exactly what to look for? If I have small tweaks/cleanup should I create an issue(s) or is using notes in a pull request sufficient? Essentially when is it appropriate Not to do an issue for work in progress? I will fix all issues posted for the December/January milestone assuming they are known in time.
yeah feel free to make tweaks to the test plan item: I also published some release notes on it here: The advantage of having an issue is that it will get verified in the endgame if it is a bug. If the thing you are changing cannot be verified or is not a bug, doing just a PR is fine.
You chose selectBoxCustom for the filename, do you prefer that I re- factor the delegate class and symbols to use custom instead of list?
no I think its fine
Fixed with:


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --With the above settings in effect and a terminal open in the bottom panel: If the terminal has focus, the cursor blinks If the terminal doesn't have focus, then the cursor remains visible without blinking Unlike the block-shaped cursor, which becomes hollow when the terminal loses focus, the line-shaped cursor doesn't change appearance when the terminal loses focus; it merely stops blinking. This makes it hard to tell at a glance whether the terminal has focus. So that it's easier to tell whether the terminal has focus, I would like an option to customize how the line-shaped cursor appears in the terminal when it doesn't have focus. Possible options (not exhaustive): Hide the cursor altogether Keep it visible, but make it (say) 50% opacity Show the same hollow block that's used with the block-shaped cursor
I actually thought it showed the hollow block in this case, I think that makes the most sense
try try
We're going back on the decision made in and making unfocused show the rectangle regardless of cursor style. Discussion:


Testing Using the simple file dialog this is a bit inconvenient: <img width="567" alt="image" src="https://user-"
(Also on Linux which I'm supposed to test.)


Type: <bBug</bWhen editing a Markdown file, VS Code will apply LaTeX syntax highlighting to math in double-dollar signs (math blocks), e.g., will color and and the numbers. GitHub Markdown also supports a code block syntax (the triple-tick syntax; see ), so the above could be written in GitHub-flavored Markdown as <img width="200" alt="image" src="https://user-"It'd be nice if it could apply the same highlighting as double-dollar signs. VS Code version: Code 1.75.1 (Universal) (, 2023-02-08T21:34:59.000Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (19)</summaryExtensionVersion ------ prettier-vscode9.10.4 linter-gfortran3.2.0 unicode-math-vscode0.3.5 isort2022.8.0 python2023.2.0 vscode-pylance2023.2.30 jupyter2023.1. jupyter-keymap1.0.0 jupyter-renderers1.0.14 vscode-jupyter-cell-tags0.1.6 vscode-jupyter-slideshow0.1.5 cmake-tools1.13.45 cpptools1.14.3 cpptools-extension-pack1.3.0 vsliveshare1.0.5831 rewrap1.16.3 cmake0.0.17 clang-format1.9.0 markdown-all-in-one3.5.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
Yay, 23 upvotes!!
<!-- -c9e0-7adb-d31b- --:slightlysmilingface: This feature request received a sufficient number of community upvotes and we moved it to our backlog.


To learn more about how we handle feature requests, please see our . Happy Coding!
Having math block and code-block specific code linting would be also great!


Testing Meaning that it would automatically highlight and reveal in the background when you type a valid number of a match.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.78.0 (user setup) Commit: Date: 2023-05-03T20:09:00.748Z Electron: 22.4.8 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No I've reported a bug related jupyter notebook before . After new release of vs code this below bug happens. Steps to Reproduce: https://user- a Jupyter notebook file that contains some images. to view images and see what happens.
I'm not seeing this repro - can you try disabling all extensions and opening that same notebook to see if it still repros? Also check which renderer is being used for the image by selecting 'change presentation' in the output menu !
I've provided info about you asked in the video. extensions are disabled was using 1. as seen in the image and video. tried other renderer as well to show difference. another issue is; VS Code is scrolling down own its own when notebook is opened first time and loading of output started. It can be observed below in end of video as well. I cannot hold the page and have to scroll back by myself. !
How many images are you displaying there? (I still don't see it with 500, though perf takes a big hit) Does it repro with a smaller number of images? Like just displaying the same image 10 times.


Do you know if all the images are being displayed? I see some suspicious collapsed borders in between a few. Can you try and reloading to check if there's a setting causing this? ( to default to switch back)
Alright, I have tried the way you told me and created new profile and didnt install anything at all. But it seems that doesnt change. I dont have a notebook that have few images. The notebook have 618 images as it could be seen in the video before images output says that 1/618, 2/618 .... 618/618. Those are the images is saved in storage after that they are being displayed. As far as i noticed those movements only occurs when notebook is being loaded. Because if load finishes that movement seem to stop as well. Another thing is there is something wrong about loading process as it could be seen in the video. I especially didnt use mouse's wheel not to confuse you, i only used scroll bar on the right. VS Code stops loading/showing images after some point untill i scroll down bottom and if i come back it suddenly appears. And i wanted to show how google colab loads in the browser.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
are there verification steps for this?
verification steps a notebook and put a small image in your local workspace a cell with the code: the cell and wait for completion, (finished for me in a few seconds) , close, and re-open the notebook the images might take a bit to all render, but they shouldn't bump up and down once they are visible
Same bug (bumping up and down) still persists for me. Another thing is loading of images are stuck some point and it's fixed if i scroll down to bottom and come back. I showed and explained the bug which was in vscode.mp4 video and duration between 00:42-1:20.


Version: 1.79.2 (user setup) Commit: Date: 2023-06-14T08:57:04.379Z Electron: 22.5.7 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0.
This fix is only on VS Code Insiders right now. It looks like you're still using the stable version.


Type: <bBug</bPressing Alt+] and Alt+[ in Accessible View includes redundant aria alert before new content. On Windows, NVDA and JAWS users hear the following info first whenever they press Alt+] and Alt+[ in Accessible View: I have tested with Accessible View against inline suggestion. Please exclude this message from the aria alert. VS Code version: Code - Insiders 1.82.0-insider (, 2023-08-17T05:33:29.141Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.20.0 gitlens14.2.1 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-google-translate1.4.13 codespaces1.14.15 copilot1.104.343 copilot-chat0.7. remotehub0.60.0 vscode-github-actions0.26.1 vscode-pull-request-github0.70.0 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.4 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.14.0 vscode-pylance2023.8.30 jupyter2023.7.


jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.105.1 remote-ssh-edit0.86.0 remote-wsl0.81.0 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.15.31 cpptools1.17.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.8.1117 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.16 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.94.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.13.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.53.0 vscode-java-dependency0.23.1 vscode-java-pack0.25.13 vscode-java-test0.39.1 vscode-maven0.42.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
can you pls try in insider's? I made some changes yesterday that should've fixed this.
This issue still exists in the latest insider that I have updated today.
That info, 'Inline Completions Accessible View' was formerly provided via the aria label.


With this change, , it just says 'Accessible View', but when I use the keybindings to go to next/previous, I only hear the new suggestion via as expected.
That’s odd. I still hear that redundant label info in Accessible View for inline suggestion when pressing Alt+[ and Alt+]. I have tested with NVDA and JAWS on Windows 11.
What happens for me is: inline completion accessible view "Accessible View, edit text...." 's some delay before the screen reader moves on from reading the initial text then I'm alerted with the new suggestion
If we wanted to prevent this delay, we'd need to hide the context view, wait 50 ms, reshow it. The issue with that is then it would do exactly what you describe and read the aria label + edit text before reading the new suggestion. That's what was happening in insider's yesterday and I realized was not ideal, so changed it.
can you reproduce this in today's Insiders?
it is working for me as described. I also debug with NVDA, and confirmed that it is processing the focus events before the liveRegionChange event. However, if I use Alt + left or right brackets, it behaves as we expect. If you hide the accessible view for 50 ms it might work, simply because NVDA will not receive any focus event before the alert.
I get slightly nervous about being so prescriptive when it goes to screen reader behavior. You just need a small change in the way the screen reader handle things for all these hacks to turn against us. There are a few that I feel comfortable recommending.
Thanks for confirming I've only tried macOS/ VoiceOver, so maybe the repro happens only when using NVDA. Here was the change where I had that delay
I can bring that change back if it seems reasonable to you. It's just like the other one that you tested and said works well
we still need to setup self hosting for you .
Oh yes. self-hosting is fun.


Needs to be fixed to reproduce the issue Repro: log level of "Pty Host" specifically to trace a terminal to verify trace logs show up in pty host channel the restart pty host command a terminal to verify trace logs show up in pty host channel, they don't show up
some help would be appreciated here. When the process is restarted the logging just stops working completely. Here's where the utility process environment is created: Here's the logger initialization on the pty host proc: If you try repro you'll need this change
I can reproduce it.
It seems pty process is creating the log file in a new folder instead in the logs home folder. <img width="386" alt="image" src=""It is because a new folder is getting passed to the pty process from main process. Fixing that would fix this.
Weird. Thanks, I'll look into that
This is causing following regression - only last 5 log sessions are being retained instead of 10. Hence moved it to current milestone and prepared a fix for it.
so the logs do show up, but the terminal doesn't seem to get created correctly - I cannot type in it. EDIT: after restarting the pty host, I cannot type in any of the terminals.
the terminal created before the pty host restarted receives input but does not display it. the one created after it restarted does not receive it.
I don't see this log
I ran it again and now can type in the terminals, but there are no logs happening when I type or create a new terminal !
As long as the regression fixed in is good, this is low priority. Will check it out again in July.
Flaky repro, but sometimes a window might not ack the restart. See the bg window correctly shows the restart and relaunches, but the fg doesn't: <img width="1008" alt="Screenshot 2023-06-30 at 8 02 18 am" src=""Restarting again fixes it, I can't repro any problem with the log not working though.
Weird, when this happens data events aren't getting fired for just one window: !


On input in the broken terminal: <img width="747" alt="Screenshot 2023-06-30 at 8 31 15 am" src=""
The 2 windows are connected to 2 different pty hosts: <img width="989" alt="Screenshot 2023-06-30 at 8 38 10 am" src=""
I'm closing this issue off again as the logging problem was fixed in the linked commit. I investigated the problem hit and created some more targeted issues to fix:


Issue Type: <bBug</bWhen : one mouse wheel scroll in extension view: moves 100px one mouse wheel scroll in settings editor: moves 100px When : one mouse wheel scroll in extension view: moves 100px, with slight animation one mouse wheel scroll in settings editor: moves 15~25px, without animation I'm using a Logitech G502 Lightspeed mouse, without any scrolling tweaking softwares. ! VS Code version: Code - Insiders 1.48.0-insider (, 2020-08-05T05:30:25.429Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
I don't see this, any idea
I believe this setting is ignored for macOS. Duplicate of
Actually not a duplicate. Interesting. I need to get my hands on a mouse to see if I can repro.
Created a PR that fixes this:


Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.


Light themes have relatively low contrast for foreground and hover colors. ideally we do not need to create a new color. Either we can tweak the default list colors which are used for quick pick , SelectBox, Explorer et cetera. Light Default: ! Bad Hover contrast: ! I suggest we increase the contrast for the default listHoverBackground applicable to all users. For the foreground color we could make this slightly darker again for the default. I don't see why we would create new colors either, I think whatever is good for selectBox should be the same and good for the quick pick Tagging this "under discussion" hopefully that is correct.
I finally figured out the listFocusForeground has no default, it's inherited from Monaco-shell. If we define it and listFocusHover in light-defaults we won't create any other colors. Screenshot does not do justice to foreground, you probably want to try it on your own machines. Let me know what you guys think. Below light+ with foreground, hover darkened: foreground === originally hover === # !
can you make a PR for me to try out your suggested color change?


When I use the command line code --install-extension {id} Cannot find the installed extension Vscode - userdata: $HOME /. Vscode/extensions/extensions. The json. This error only appears in version 1.90.0, but does not exist if you go back to version 1.89.0.
This only happened the first time, and it worked the second time I executed the command line to install the plugin. So did everyone else around
Are you still seeing this issue? If so can you please provide steps to reproduce?
My plug-in is a private plug-in that updates through the code command. When I released the updated version of the plug-in, I used the code command to update it, and there would be an error the first time, and it would be successful the second time, which was stable. !
TLDR: The issue happens when a version that was installed before is installed again I have pretty much the same scenario. A private extension that uses to update itself when a new version is available. This is the error that's logged: I do have an entry for my extension in the file though: I did some testing on a bare project to understand the failure mechanism. What I found out is that if a particular version of the extension is installed before (for example during my testing before I release the extension) then upgrading/downgrading to that version will fail. Using following steps I can reproduce this issue reliably: 1- Create a bare project: 2- Package the extension: 3- Increment the version number, and package again: 4- Install the first package: 5- Update to second package: So far everything is in order. The problem begins when we try to install any of those packages again: 6- Downgrade to first package: At this point the neither 0.0.1 nor 0.0.2 is shown as installed. So installing any of them will be successful. this explains why you're always getting the error on the first, but the second round is successful. 7- Install the first package again: 8- Update to second package again: Tested this with Windows and WSL Ubuntu. Happens only on WSL Ubuntu in my case.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected.


If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Looks like this is working now in the latest VS Code Insiders. Tried with WSL: And using the latest stable (which doesn't have the fix yet) I can repro the errors that describes.


Testing microsoft/vscode-jupyter The setting description says that the 'interactive window session' is restored. But after a reload, it seems that the state has been forgotten e.g. Open the interactive window run run prints 9 reload the window the output is restored but running again will show Note that I had to retype print(x) as there was no way to rerun the previously shown cells What's restored seems to be the last output. Maybe the settings description can clarify that?


Testing microsoft/vscode-jupyter IMO is about restoring a editor with unsaved changes, but the interactiveWindow doesn't seem to have a dirty state. Maybe just call it 'interactiveWindow.restore`? It's actually not really a window ;-)
Good point Martin, I think calling it makes better sense. is a bit ambiguous, we can revisit the name for it in the core when we stabilize the API.


Notice how for the task terminal it jumps all the way to the top on the first ctrl+up, instead of going to the most recently run task: !
When I run the build task and do cmd + up, the window crashes !
That's even worse
the call to get markers here returns undefined !
I bet the markers are getting disposed of, so deleted from the map in but it looks like that wouldn't even happen since we don't set like we should. Could be why I see the renderer process crash?


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --So far, I haven't been able to find any issues around this, but I also haven't found a ton of documentation on this feature either. Basically, I'd like to have finer grained control over how the terminal "word link" auto detection works. This is one of the only comments I was able to find about: Example: In the terminal, I have some output from a compiler that includes relative paths that can be clicked conveniently as an autodetected "word link": Specifically, clicking takes me to the line in question, which is great! However, at some point I tried configuring to include a forward slash (colon has related effects too), e.g. By doing so, the auto-detected file path is no longer clickable, since each path segment is considered as a separate word instead. Notably, the absolute path above is still clickable, but relative paths appear not to be (unless I remove from again). I guess there is probably more than one way to solve this, but a simple solution that comes to mind would be to have a separate config, maybe something like . If null it could fall back to the value, but at least this way it would be possible to configure different separators for double-click selection and link detection. Thanks in advance!
This case is meant to work with the regular non-word link detection as you can see here: <img width="490" alt="Screenshot 2023-05-08 at 6 31 15 am" src="https://user-"This may not work is if the relative path is not relative to the current working directory or you have shell integration disabled (which is provides better cwd detection). In your example is relative to the directory the terminal was currently on? The word links are meant to catch the majority of cases where the verified file links fall through.
Edit: never mind, I think I was testing with the wrong value of as I described in the original issue body :( I did however notice an interesting data point while integration was still disabled: the clickability of the file path seemed inconsistent. Here are a few screenshots showing what I mean (ctrl held in each case): Can't click in a compiler diagnostic, maybe due to the prefix on that line? !


A command I wrote without line/column numbers works fine: ! A command I wrote with line/column numbers works fine: !
It's a little hard to tell if this is by design or not without knowing the exact cwd and full path of these folders. What we're going for is verify if the file is real if it's relative to the current working directory (which is citro3d-rs in your last 2, not sure for the first), otherwise fall back to word links. Since you changed wordSeparators, the fall back isn't as useful, but it looks like it's working properly.
Ah sorry I forgot to include those extra details. The cwd and path was the same in all 3 cases (i.e., the relative file path should work in each case, I think?): I guess the part that doesn't make sense to me is why the latter two cases work but the first one doesn't - since in each case the path is the same and I haven't changed directories at all. I suppose the workaround of removing and from is still an option but it would be nice if the linking was more consistent.
Yeah this is strange if it's all the same cwd. I Can't repro here I'm improving trace logging in , when that is released to insiders (the day after it's merged) you will be able to set the log level via the command palette (F1) and view the trace logs when hovering the terminal line by looking in the Output panel Window dropdown entry. That will give us some more info on why this is happening.
The logging changes should be in tomorrow's insiders
thanks for that, here is the trace log output that I think is relevant for debugging. Please let me know if you need more info or another reproduction: Edit: the cwd again was and the relative path should resolve: <details<summarytrace output</summary</detailsOne odd thing I noticed - without changing any settings, I actually had one instance where it worked as expected and linked the relative path to . However I'm not sure how or why it worked. When I opened a new terminal the old behavior (not linking) came back. If I can reproduce that again I'll try to capture those trace logs and maybe it will highlight a difference in behavior that's helpful. Thanks again for looking at this!


So there's this in the logs: So it's parsed as a possible link, but not made a link candidate (which checked the file system before making the link). Somehow this part isn't adding the candidate: The only way I think that could happen is if doesn't return anything. I another log to verify the cwd and also improved fallback in case it is undefined. Can you do the same again on the next Insiders which should come out on Monday?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
sorry for the delay, was a bit busy last week but I was able to check with a recent build (): The link is clickable now, even with and both in ! I'm guessing the fallback changes you did the trick. It seems the triage bot closed this as "not planned" but maybe you are able to update its status to "fixed" or similar? Thanks for your help looking into this issue!
great news! I still don't totally understand how it was failing before but at least the issue is fixed


Type: <bBug</bterminal in editor area. and hit enter. and hit enter alt+F2 to open accessible view ctrl+shift+O to open symbol list and select and hit enter Note: the focus doesn't move to VS Code version: Code - Insiders 1.83.0-insider (, 2023-09-25T10:41:26.295Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (91)</summaryExtensionVersion ------ android-dev-ext1.3.2 aiprm-lang0.0.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.118 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.52.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.23.1 gitlens14.3.0 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-google-translate1.4.13 codespaces1.15.3 copilot1.115.437 copilot-chat0.8. remotehub0.60.0 vscode-github-actions0.26.2 vscode-pull-request-github0.72.0 overleaf-workshop0.2.4 cslpreview0.2.2 easy-snippet0.6.3 path-autocomplete1.25.0 latex-workshop9.14.0 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.1 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.16.0 vscode-pylance2023.9.20 jupyter2023.8.


jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.312.0 remote-ssh0.106.4 remote-ssh-edit0.86.0 remote-wsl0.81.4 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.15.31 cpptools1.17.5 cpptools-extension-pack1.3.0 js-debug-nightly2023.9.2117 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.18 vscode-serial-monitor0.10.0 vsliveshare1.0.5883 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.4 shinyuieditor0.4.3 quarto1.100.0 r-debugger0.5.4 java1.22.1 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.7.0 latex-utilities0.4.10 cmake0.0.17 errorlens3.13.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.54.0 vscode-java-dependency0.23.1 vscode-java-pack0.25.14 vscode-java-test0.40.0 vscode-maven0.42.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for the report! Reproduces in panel terminals also
For step 5, after I select and hit enter, the cursor moves to the beginning of the line that contains , rather than after the prompt. Is that intended behaviour?


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When using the Git API extension Repository interface and the corresponding are not exposed. Having access to these functions would be very helpful, since using with returns early and doesn't provide useful errors.
Verified by code review


use generate cell in notebooks make a request while the request is active press stop a bunch of errors are printed
It seems not wise at all to maintain my own *chatcontroller. I'd love to look into how do I ensure I reuse the most of Inline Chat Controller later.
Is the generate cell feature just with using ctrl+i from within a cell body? Not sure how I can trigger it.


It would be nice to have a entry in the configuration section of markdown-math extension. A place where users could put their custom math macros.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Verification steps: Open a folder/workspace that contains a git repository Use the "Git: Checkout to..." command to "Checkout detached...", and select a branch/tag Switch to the "Source Control" view and confirm that the "Commit" action button is shown instead of "Publish Branch"


Testing When turning off , the decorations disappear. When turning back on, they do not reappear automatically. !


Testing After enabling remote tunnel access, a link like this is printed: The browser ends up redirecting to It would be nicer to genrate the vanity format


Start legacy protocol debug session Open something via "Open loaded scripts" scroll down ctrl+tab to switch to another doc ctrl+tab back to the newly opened script It's scrolled up to the top. Is it being closed/opened each time we switch away?
This problem is independent from the "Open Loaded Scripts" feature. To reproduce: debug a simple node hello world program and stop on entry in the CALL STACK select an internal module press Control-Tab twice (to switch between two editors) Observe: you loose the scroll position in the internal module
March to investigate
Workbench is not preserving scroll location of in memory resources. Same is true for diff view. Forwarding to since he probably already has an issue for this
I do but I cannot find it right now, PR welcome.
give me some code pointers for the PR and I can do it in debt week
we do it for and via the and methods that are actually defined in and we could probably push this down from and and just use it from textEditor for any input that has a resource
Ok, makes sense. Assigning to me and April to look into it
Related:
With landed, we keep the UI state when you switch editors, though we clear it when you close a tab. The rationale is that the lifecycle of these editors that have virtual resources is not known, as such we assume the view state can be ditched once the editor closes.
That sounds perfect!


Open Select the top cell and page down a few times Focus hits a cell that is longer than the viewport, which is maybe important, then the next page down moves to a higher cell
When a list item is larger than the viewport, and it's also the only element in the viewport, pressing page down will reveal to the previous element, this is because we did a here (the catch is, the last page element is also the first page element)


only seen in OSS so far outline view shows 'No symbols found in document '*.ipynb' or a very limited amount of the outline logs show an exception:


Testing I'm wondering if there's a way to add a schema so that users can get descriptions on the various fields they can use while creating a new profile. I also realize that the keys represent profile names, so that might make it harder to validate/provide descriptions for them. I guess the description for the keys would go under in that case, though there already is a long description for that field.
this would be nice, looked into it a bit but we're not sure how to set it up for such an object. We essentially want to enforce something like
would you be the right person to ask about schemas for settings?
You can use the property to specify the shape of all properties regardless of the key. An example is the setting: If there are constraints on the key, you can use :


Testing Type in the settings editor. It would be nice if there was autocomplete for a list of languages. This is a finite list which we should be able to suggest fyi !
It's easier to discover language overrides in the editor because there is autocomplete there: !
Thanks to for pointing out the language service to me the other day. PR ready above.
/verified? The autocomplete works but no matter what I write there I get the same set of settings? I suppose all of these apply to all languages. ! !
Yep, the idea is for it to show all language-configurable settings. Then, the user can read and write settings for that language. I plan on making it so that the tab says which language you're on, for extra confirmation.


Type: <bBug</bterminal git bash Enter and you will get delay VS Code version: Code - Insiders 1.90.0-insider (, 2024-05-06T08:07:13.626Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ rust-bundle1.0.0 glance0.0.8 project-manager12.8.0 redmodscript-lang0.2.0 redmodtweak-lang0.1.0 lit-html1.11.1 glsl-literal1.0.6 vscode-markdownlint0.55.0 vscode-eslint2.4.4 composer-php-vscode1.45. intelli-php-vscode0.12. phptools-vscode1.45. profiler-php-vscode1.45. rust-syntax0.6.1 gitlens14.9.1 EditorConfig0.16.4 prettier-vscode10.4.0 auto-close-tag0.5.15 auto-rename-tag0.1.10 copilot1.186.856 copilot-chat0.16. todo-tree0.0.226 path-autocomplete1.25.0 redscript-syntax-highlighting0.0.3 auto-comment-blocks1.0.1 dotenv1.0.1 debugpy2024.6.0 python2024.6.0 vscode-pylance2024.4.1 remote-wsl0.88.2 hexeditor1.10.0 vscode-extension-auto-import1.4.3 indent-rainbow8.3.1 vscode-yaml1.14.0 rust-analyzer0.3.1950 crates0.6.6 shader1.1.5 vscode-styled-components1.7.8 vscode-stylelint1.4.0 vscode-mdx1.8.4 highlight-matching-tag0.11.0 vscode-import-cost3.3.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
does this reproduce if you disable shell integration, ?
If I uncheck Shell Integration, it works well after terminal restart.
I have more details in with what's going wrong.


The issue was introduced by this PR where becomes extremely slow
I had the same issue and setting to does the trick.
When I just hit the enter key on a bash prompt it takes about 4 seconds for the prompt to return. I ran process monitor and noticed many many (maybe over a hundred) instances of being spawned to run the shellIntegration- script.
Any idea where this ticket is tracked? Every reference to the issue is closed marking duplicate.
Closing an unfixed issue that everyone have ? I don't get the point
I closed this accidentally, have reopened.
worked for me !
Hey guys I'm having the same issue. Running a single is taking over 15 seconds to complete the command. After disabling , bash looks way better
The problem seems to be related to The issue happens also if I start (outside VsCode) my bash thus (same as VsCode does for its terminal): Each time the prompt must be shown (eg, after simply pressing the Enter key) a delay of about two seconds happens. Most of the delay is caused, it seems, by the function In particular, commenting out the line 178 seems to alleviate good part (not all) of the delay. Edit: More specifically, the culprit seems to be If I change the line 109 from to (effectively forcing "the switch to the faster function"), the problem goes away. (BTW: the faster function seems to have a bug of its own, it produces an extra prompt!)
Process monitor screenshot shows it re-running this over and over 89 times when I press enter at the shell prompt "C:Program FilesGitbin..usrbin" --init-file "c:UsersarthuAppDataLocalProgramsMicrosoft VS Coderesourcesapp/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-" !
Disabling is another workaround that improves the delay for me.
Hello Guys, This setting worked for me.
This helped me, thanks!
will move you to the old backend stack which significantly reduces the functionality/capabilities of the terminal. shouldn't do anything. is the right workaround for now, expect a fix soon though
what caused so many bash invocations when shell integration is enabled?
we started reporting the bash prompt in order to better position shell integration markers and understand the prompt.


Apparently printf is just extremely slow on git bash
I had this terminal slowdown problem, in git bash, and found setting fixed the problem - the terminal was back to being fast. However, after the last, or recent, insiders update, even with that setting set to , the terminal is slow again - and it's showing the icons, etc. like it is ignoring this setting: ! !
you probably just didn't restart the terminal. This is now fixed and will come in the next Insiders and likely 1.90.1
Actually, I had the shell integration disabled for the last several insiders updates, so it has been off for a while. Terminal windows have been created and closed many time since. For whatever reason, when launching VSCode and the terminal session was restored, this last time, the integration feature was ignoring the flag. I terminated the terminal and started another, and the integration went away again. So basically the integration flag was ignored when the terminal session was restored. I just did a quick test of quitting VSCode, with a terminal window open, then relaunching, and the integration was still disabled. Unsure what happened. Guessing, also, you type-o-ed the version? I am already running 1.91.0 insider !
what happened was the terminal was restored which re-creates the process after vscode starts with the original environment, args, etc. No the next insiders build on Monday and v1.90.1 (stable)
when will be the next minor update, not the insider build so this terminal slowness is resolved?
FWIW, I can also observe the prompt's slowness on Linux (bash 5.1.16(1)-release on Ubuntu 22.04.4 LTS) on the order of a half-second or so (still annoying but bearable). looks like a temporary workaround for Git Bash only; will we fix the underlying cause of the slowness?
I also observe this to be slow over linux using an ssh remote. It's much slower if I have a starship prompt enabled (4s) and around 1s if I have the default debian prompt.
I have this issue (Win 10, git bash). The suggested workaround of disabling shell integration then restarting terminals worked for me.
Also having this problem. Disable terminal integration worked for me too. (Win 11, Git bash).


I re-enabled terminal integration with the latest Insiders - ! and it the problem seems to have been fixed. For me at least.
Yes, it's been fixed in insider's already.
Perfect solution
When is the release date for the VSCode stable one?
no exact date, but probably later this week
, Turning off shell integration only sorta helped me out. It does return a result slightly faster, but it does not return the prompt back for 4 seconds or so, but only with python poetry workspaces/folders opened. This slowness goes away if I don't have a workspace/folder open, a non-poetry python one, a javascript one, etc. There's now a '(packagename-pythonversion)' at the top of my prompt when I open a python poetry folder and that seems to be taking forever to generate after each command. Definitely wasn't happening before my last update. This seems like a separate issue? Or is it related somehow? Happy to open a separate Issue if needed.
I don't know if this is the same as your issue but I've found that, if I already opened a terminal in a workspace before changing the setting, I had to kill the terminal for that workspace and open a new one so it would be initiated with the updated setting.
Yes. With the feature disabled, issue does not happen . But the feature will not work also . I can live without that feature but I like it. It makes my IDE look smarter. It's strange. I remember the feature was there earlier without any issue.
Was the fix included in 1.90.1? The shell integration is still too slow even after I updated to 1.90.1. It still takes over a second for all those bash commands to run every time press the enter key at the terminal. I have to keep it off to keep my Windows git bash terminal usable. It seems like it takes around a second and a half to get a new prompt with that setting on. Is this expected?


I just updated to this version: Version: 1.90.1 (user setup) Commit: Date: 2024-06-11T21:01:24.262Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0.
it should be fixed yes, can you run and paste in the results?
$ for i in {1..10}; do time _vscreport_prompt; done real 0m0.236s user 0m0.045s sys 0m0.092s real 0m0.194s user 0m0.045s sys 0m0.076s real 0m0.210s user 0m0.030s sys 0m0.122s real 0m0.217s user 0m0.015s sys 0m0.152s real 0m0.216s user 0m0.061s sys 0m0.138s real 0m0.245s user 0m0.045s sys 0m0.123s real 0m0.202s user 0m0.015s sys 0m0.091s real 0m0.212s user 0m0.061s sys 0m0.091s real 0m0.230s user 0m0.000s sys 0m0.153s real 0m0.212s user 0m0.045s sys 0m0.108s
It seems like it's taking a long time to parse the prompt. My git bash prompt is user MINGW64 /c/path/to/dir (master), where the my /c/path/to/dir is a 29 character path. But sometimes it's a lot longer. Does a longer path make it slower?


When I cd to a 135 character path, and try to time it it just prints 633;D;0: $ time vscreportprompt 633;D;0 $ vscreportprompt 633;D;0
those numbers aren't too bad, but regardless I think we need to rethink how we're doing this prompt reporting feature. I'm going to stick it behind a setting in so it's just disabled completely by default.
This is still unreasonably slow, IMO. If I'm running a shell with the extensions the shortest possible interval between two commands seems to be over 700ms on my machine: ! Running without the shell integration, it's closer to 250ms, and that may only be because that's how fast I can press the ⇧⏎⇧⏎ keys: ! Despite the improvement over 1.90.0, I still feel like I have to disable the shell integration. It's 2024. Having to wait a perceptible amount of time just for the terminal prompt to re-appear feels like a huge regression to 1980s computing. Is my floppy drive trying to seek to a specific sector?
v1.91 which I think is being released today includes the changes I mentioned in , disabling the prompt reporting stuff completely (for the stable build): !
I'm running 1.91.0 (insiders) and I still see a significant delay between prompts (on windows, using git-bash terminal). Turning the shell integration off speeds it up quite a bit.
it's only disabled in the stable build. Insiders keeps the slower code as it provided reliability improvements and the plan is to optimize it soon.
While v1.91 does seem to improve the delay, there's still a noticeable delay for me so I'll be sticking with the option disabled.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Hello, we have been recently testing out our extension for accessibility bugs, and we believe we may have found one directly linked to vscode. The extension we are using is Bridge to Kubernetes. Does this issue occur when all extensions are disabled?: Yes VS Code Version: Visual Studio Code Version 1.73.1. (user setup) OS Version: Windows 11 Version 21H2 (OS Build .376) Steps to Reproduce: on NVDA/JAWS. Visual studio code application and setup Bridge to Kubernetes extension. cluster config file and load 'stats-apo' project. 'Ctrl+Shift+P' open command palette in View menu. 'Bridge to Kubernetes: Configure' and press enter. using down arrow key to select 'stats-api' in connect to kubernetes (1/4) stage and press enter. '3001' in connect to kubernetes service: stats-api (2/4) stage and press enter. whether NVDA/JAWS is announcing the given placeholder text at edit field or not.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.73.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Hi The bug still exists with the new vscode version. I edited the original post. Thanks!
I think you just worked on improving the accessibility of the quick pick - thoughts on this?
A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #Win32; #Visual Studio Code Client; #BM-VisualStudioCodeClient-Win32-Aug2022; #WCAG1.3.1; #Element:Placeholdertext; #AILimited; #JAWS; #NVDA;
have you looked into the feasibility of supporting this?
Sorry I'm not sure I totally follow here.


Just to make sure, can you attach a gif? /gifPlease
Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, files are preferred as they are displayed inline on GitHub. You may find helpful as a browser-based gif recording tool. If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording ( in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue. Happy coding!
from the above description, I believe what expects is for the placeholder text to be read before the selected item is. From my testing though, that is working already (I tried and
Thanks for the comments and I will try and get a gif for you folks in the upcoming days!
sadly gif does not record audio. I will record a video and send it to you internally.
video uploads on GitHub issues work now so you can always attach here :)
I have attached a video below! Basically, the place holder text should be read with NVDA. The accessibility folks have flagged this as a bug. Thanks! https://user-
do you have Accessibility mode turned on? Just checking. You should have gotten a notification about it.
you can turn that on with
Let me test that today thanks!
where do I find ?
and search for . The alternative way would be to run the command via the command palette
Thanks for this it was set to auto. I will turn it to on and try again
It is still not pronouncing the text in the edit field. Would you classify this as a bug or is this just a part of VsCode?
I can reproduce the issue - I'd expect the placeholder text to be read before the selected item is, but that does not happen.
Example: In a multi root workspace, run . I'd expect it to read to me: "Select current working directory for the new terminal"
Logging shows that the quick input's aria label is correctly set. After that though, when an item is selected by default, its aria label takes precedence
Perhaps when is true, we could not select an item by default so that the placeholder text will have focus every time?


thought that was the behavior today? Just opened the Command Palette... focus is in the input: <img width="830" alt="image" src="https://user-"
I mean when you run a command that opens a quick pick such as !
commenting out this code fixes it
so I think we need to check there if and not focus
Looks like this use to be reported in
! odd I don't repro with that command you have... wonder if we have a conflicting setting. Also VoiceOver did read out the placeholder in this case.
for me, the placeholder is not read in most cases (but it is with the changes in the PR)
my repro steps were when in a multi root repo, run that command. the first quick pick placeholder isn't read
Hi and I see this as moved to the backlog. Do we have a rough date in which this could possibly be looked at again? I plan on telling the testers that you two are looking at the bug. Thanks!
I did it in "holiday mode" as a lot of us are disappearing for the holidays. I'll leave it on January
Thanks for the update that totally makes sense. I will let the testers know. Happy holidays!
do you see a way to do this? it's not clear to me where the item is getting focused
is open to testing the PR once it is available
We'll try to fix this in February with the following read by the screen reader via : placeholder of input box (note this doesn’t logically have to be the placeholder, it could be an aria label set somewhere) number of items in the list the label of the highlighted item in the list (aka the first item in the list)
I just discussed with and he says "I need an ARIA expert because I can’t get this to work nicely. is what we use today on the quick pick input box. That points to the focused item in the list. This is needed because true focus always stays in the input box. The problem is that if an element has AND the is ignored. I’ve tried a few other solutions and haven’t had luck, unfortunately. Looking for creative solutions" might you have suggestions here?


Just to provide an update... After chewing on the problem yesterday, my best idea is to try to mirror this design pattern as much as possible: Applying it to the quick pick means making the following changes: in a11y mode, we do not focus any of the items in the list. Doing this, we can easily ensure that the placeholder is read out because aria-activedecentant won’t be set yet in a11y mode, When the user types something in the input box, aria-activedecendent is removed and we remove the "active" state of the elements (thus focus goes back to the input) When pressing down the first element is highlighted. aria-activedecendent is set on the inputbox pointing to that item. The item gets read out. Nothing new here. While this pattern is fine, it's not really what I want because the QuickPick isn't really a combo box (though I'll admit it's close). I’m sad because I would rather not have specific a11y mode behavior here… but this is the best I think we can offer with my ARIA skills. Tl;dr: I need a solution for reading the placeholder of the quickpick input box first and then read out the first highlighted item in the list (the aria-activedecendent)
Hi team. I’m reading the thread and I’m probably missing something but I’m concerned that there is perhaps a misunderstanding about how the quick input experience works in general and the particular issue of the Bridge to Kubernetes extension. Perhaps I’m missing the problem, but the quick input list works well for me. Here is an example: the command palette by pressing CTRL +Shift +P a. NVDA announces the label and placeholder text for the editable field as follows: “Type the name of a command to run. combo box has auto complete editable Press 'Enter' to confirm your input or 'Escape' to cancel”. type git, for example, and select the Git clone command with the arrow keys and Enter. a. Upon selecting the command, focus returns to the editable section and NVDA reads the prompt as follows: “Provide repository URL or pick a repository source. combo box has auto complete editable Press 'Enter' to confirm your input or 'Escape' to cancel Provide repository URL or pick a repository source. blank”.


use the arrow keys to select the option to clone from remote sources and press enter on it. a. Upon pressing Enter, focus returns again to the editable field and the prompt is read again: “Repository name (type to search) combo box has auto complete editable Press 'Enter' to confirm your input or 'Escape' to cancel Repository name (type to search) blank”. I wouldn’t expect this to behave any different. The only instance where I have observed a different behavior is with the Bridge to Kubernetes extension where, upon selecting the connect command, for example, screen reader focus seems to jump directly to the list instead of the editable portion which is the standard behavior, maybe because aria-activedescendant is set at a time when it shouldn't? why you would like the placeholder text and the first highlighted item to be read together? I understand the placeholder text as the label for the editable field, therefore it is relevant only when the editable field is focused. By focused in this context I mean that it has screen reader focus, not keyboard focus. When we manipulate aria-activedescendant we are communicating the screen reader to focus on a different control, therefore the label of the control with focus shouldn't be read. The label of the list portion is "Quick Input list", and that is actually the hint that we are now exploring the list of options. I fully agree that we should stay away from an A11Y exclusive mode as much as possible.
because this is the behavior of a sighted users today. They are able to see the placeholder in the input box and the first item in the list is already focused (using ). This allows a user to be shown the quick pick and be able to hit to accept the first item in the list. Putting the "quick" in "quick pick". Today, users of a11y mode via the setting have a different experience, which is what you describe... no item is initially focused and a user in a11y mode must hit down arrow to get to the first item in the list.


My wish is that we could have the same experience for users of a11y mode and not... but my research above, albeit not expert level, has given me the perspective that it's just not possible... and that it would be easier to fix the bug you call out which can be simplified to: "When we chain quick picks we need to remove on any item if one exists so that the 2nd quick pick reads the placeholder"
Thanks I think I understand now. Since this is really not a combobox, I would then suggest a change to the way this works from a keyboard and screen reader perspective. Please take this as a general idea which could be significantly refined or completely abandoned. and Shift +tab can be used to move focus between the edit field and the list box. Tab works now, but shift +tab doesn't return focus to the text field. Visual keyboard users can press Enter in the text field to trigger the first element in the list which is selected. Blind screen reader users can tab to the list to hear / read the element selected and press enter from there. text in the text field changes selection visually and updates an aria-live region with the selected item in the list. In a way it is better than manipulating aria-activedescendant because the text is still editable. note: It should be a visually hidden live-region which will only contain the visually highlighted item at a given time. while focus is in the list filters the list as it does now but doesn't update the aria-live region because screen readers are tracking ffocus in the list itself therefore there is no need to announce anything. focus is in the text field, pressing down arrow changes selection in the list and moves focus to the list itself. quick pick changes resulting from selecting an option, we reset focus to the edit field so that the placeholder is read. Screen reader users can then tab to the list to hear the selected item / navigate, or start typing in the edit field. remove the combobox role from the text field because we agree it is not a combobox. note: As a blind screen reader user myself, I don't know how the experience looks / feels like from a visual perspective.