This was also discussed in and apparently fixed in , but I'm still experiencing this. Steps to reproduce: to in settings. a file, and add the following contents: Ensure that there's an empty newline at the end. Save it. Then hit Undo. Nothing will happen. Hit Undo again, then it will work as expected. You can even hit Save multiple times, and each time will add one extra step to the Undo list. So hit Save 10 times, then you can hit Undo 10 times and nothing will happen. Could you take a look at this if possible?


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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.51.1 OS Version: on both Fedora 32 and Linux Mint 20 Steps to Reproduce: clone issuesvscode1400markdownPreviewRootRelativeImg . doesn't display in ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes This issue had already occurred in past: In the latest insiders vs-code build - it's not fixed as well.
I took a look at this and found that the issue is that the resource vscode-webview-resource uri is invalid, is missing before I was looking how to fix it but I can't find the place where the gets mapped to a can you give me some code pointers?
here is my quick and dirty fix for this issue:
Start by looking in the markdown link normalizer I believe this is passed the raw image links and tries to transform them into url that VS Code can render in the preview
Thanks and after spending some more time looking at this I think I found a proper fix for it


Issue Type: <bBug</bOpen extension recommendations Click on one In the editor, click the ignore recommendation button Note that the extension is removed from the recommended extension list as expected Click on the undo button in the editor Note that the recommended extension is not placed back in the list. VS Code version: Code - Insiders 1.25.0-insider (, 2018-06-26T05:18:23.085Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ html-snippets0.2.1 jshint0.10.19 vscode-eslint1.4.12 tslint1.0.33 vscode-great-icons2.1.35 vscode-gutter-preview0.12.2 vscode-azureappservice0.8.1 vscode-cosmosdb0.7.2 azure-account0.4.1 csharp1.15.2 vs-keybindings0.2.0 team1.136.0 debugger-for-chrome4.7.0 addDocComments0.0.8 cordova-tools1.4.0 </details<!-- generated by issue reporter --! Testing:
Note: this only applies to non-workspace recommendations. Will look into
Closed with


If the knows which languages a user tried in their first day, it could unlock more specific questions to further improve the language onboarding experience. How though. tracks the edited count for languages that run surveys; which are the languages we care most about right now. Only issue is that the storage key isn't exported, so the doesn't know about it. any general thoughts on the idea, and best practices on how to make the storage keys known to the ces survey code; so they can be read and attached as params to the survey URL?
The CES code already has access to the same . Can't you copy the maps the surveys to storage service keys over to CES and read them from there?
Sure, was mainly worried that this creates some copy/pasta. Will take that approach for an initial pull request draft and gather feedback.
No worries. We can also extract the common code to a new file, sibling to those two.
are there verification steps for this?
Sorry that they are so complex and time-intensive. I can also verify that I see survey responses from insiders that include the language data. a fresh VS Code Insiders instance , ensure that you are in the treatment group a Java file and save it. VS Code open for 1 hour to trigger the new-user survey popup and click to open the survey that the URL it opened contains
Ok, see you in an hour!
The treatment service does not seem to like me, for some reason. Unmarking as verified for someone else to give it a shot. Note that you need to repeatedly open VS Code windows with new user-data-dir's until you get into the treatment.
Also attempted this but no survey after an hour. Confirmed I did get an initial
when the experiment enables the survey you should also get a event? Did that work?
Testing again
Worked! [redacted]&javaLang=1


In the recent Edit Sessions UX study we ran, we saw several participants searching in vain for the terminal item in the compact menu on , sometimes for minutes: ! Could we consider bringing it back? I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that was a browser application. Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of through our welcome views. ! cc
Yes that is why it was removed. It doesn't do much but if it helps reduce confusion I guess it's worth it?
Not against the idea of having the terminal menu in web but in its current form it's useless and doesn't allow me to actually show a terminal pane, it just deadends all over https://user-
Reverting in
when I enable the menu again and fix up the terminal command, the run/customize task items give this on the scripts/code-web sample-folder: <img width="1229" alt="image" src="https://user-"That does actually run, not sure what it's doing exactly though. Is that a custom execution task running in the web worker ext host? If so you might need a context key on those menu items to only show them when a custom execution task is registered?
Unless I'm missing something, I believe only registered tasks will show there - if they're running when you select them, then I don't think there's an issue.
I think there's a built-in fake task when running code-web is what I mean, when run in actual then running it might do nothing. In that case it should hide similar to how we're changing the behavior of New Terminal depending on whether extension contributed profiles exist


I wonder if this could be a 18 issue? //cc
Yes , this is addressed in Node v20 and we have also backported the fix to Electron in However, we haven't backported the fix to but we can.


VSCode Version: 1.7.1 OS Version: Win 10 Pro Add an option to set environment variables before starting the terminal. Something like: Or maybe you want to split variable and value something like: Obviously the same goes for Linux and Mac
I'm curious what your use case is for wanting this in VS Code but not in Windows?
Here are some use cases (first two from personal experience): Different paths to libs per workbench Test your application with different languages/translations. It would also have made a much better work-around for You just don't want to set set the right vars every time you open a terminal.
! how should i fix this problem
If you are asking because I mentioned in my previous comment, I have no idea about that issue. That one is not my bug report. I just ran into that issue when I was searching around if the request I wanted to submit was not a dup.
Its not hard to see in the Python context an app needing a specific PYTHON_PATH, and other languages needing class paths/library paths. My thoughts here is that the tasks may be the workaround - a task can have associated env vars - and a make/rake/grunt/gulp/fabfile or something could be used to set it all up for your project.
I would love to see that too. For me it's about setting workspace env variables to be used with node gyp. Like OPENCV location
How does one configure this on the Insiders build?
It will be in the next build of Insiders, you will be able to use the new settings:
I can confirm that it works great for me, i now use it in almost all my projects Thanks!
UPDATE Again: Just found :man_facepalming: ! UPDATE: DOH! I just realized . God I love this editor! Amazing job. Is there any way to make this project specific? I am using this now for GOPATH but would love if it changed to the current working directory, which the integrated terminal seems to be aware of when it starts up. Maybe there is a variable I could set the envs to that contains the same value used by the starting terminal.
Anything in is already specific to the root folder that is open in VS Code. This is called the Workspace settings.
how to specify the GOPATH env variable inside the integrated terminal to be the same as the one inside your ?


I am trying this on 1.17.1 and does not seem to work:
Thanks but in my case the following is what I'm after, but doesn't seem to be working. The use of the variable seems to work fine because it stops the underlined errors in code related to gopath, but the env var on the terminal still is bork. I'm mostly good because I also setup an install task that works. Now if I could only get that to like the libraries do correctly so things would compile automatically on changes (which I realize many would not like). ! By the way, here is an (old) task that works. But, it is interesting that everyone has different variable names for the same thing (workspaceFolder v.s. workspaceRoot): !
You are using in the env var for the which doesnt get resolved. Should we add resolution of such variables when using the setting? For vs see
Resolving variables in the setting is tracked in
After upgrading from 1.17 to 1.18, the setting doesn't work anymore (OS Version: OSX High Sierra) version 1.18: <img width="1064" alt="screen shot 2017-11-15 at 10 12 25" src="https://user-"version 1.17: <img width="442" alt="screen shot 2017-11-15 at 10 16 13" src="https://user-"
Just tried on my Mac, it works as expected. One thing to keep in mind is that the env vars will not affect terminals that were created before the env vars were to the setting. Can you create a new terminal and check there?
it was indeed on a new terminal after the env was . I've retried it on two high sierra machines recently.
I tried on a co-worker's high sierra machine. Works there as well. Can you try on our Insiders? Can you try with extensions disabled?


Type: <bBug</bThe issue shows up if I have a custom PS1 prompt that looks at the exit code of the previous command (using ). Here's a minimal configuration in the .bashrc file on my remote Linux host: Expected results: When I run in a terminal outside vscode or disable automatic script injection in the integrated terminal, I get this: Actual results: when I enable integrated terminal shell injection, I instead see this output running the same commands: That is, the exit code is now always 0. I tried manually injecting the scripts using the command from ; no change in behavior. Looking at the script that gets loaded (.../server/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-), I see these lines: As an experiment, I tried moving the call later and opening a new terminal, which fixed the issue for me: So it looks like the step that clobbers the exit code is the step. Remote OS: RHEL 8.10, bash 4.4.20 VS Code version: Code 1.91.0 (, 2024-07-01T18:52:22.949Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 4.18.0-553.5.1.el810.x8664 Remote OS version: Linux x64 4.18.0-553.5.1.el810.x8664 Remote OS version: Linux x64 4.18.0-553.5.1.el810.x86_64 <details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
In VS Code version 1.92.0, I still see this issue. In this version I now see that the method calls instead of just , but running this after the function still clobbers out the return code to zero. says this about running :


<!-- 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.31.0 OS Version: Windows 10 Steps to Reproduce: a system with user home containing a space some gulp task configured you will have: <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No I think it was introduced by this commit: it is now using a global gulp which is installed in user home instead of local one. The command has never escaped space in path though
Thank you for catching this! The fix will be available in the next Insiders build.
Why are you looking in now, was that on purpose?
Ah that was already fixed


Steps: multi root workspace with 2-3 folders right click into empty space below last folder select "Remove Folder from Workspace" nothing happens //cc
I guess this should remove the last workspace folder.
Not sure, if you invoke this command from F1 list, you get a picker asking which folder to remove. We could do the same here.
Sometimes the empty area takes the last workspace folder as context and sometimes not. So we should be consistent and check what other actions do on the empty area. Maybe the only exception is actually drag and drop, which on drop on empty area drops to the last workspace folder.
! context menu of empty area should be something like this.
! and also change this icons when there is no folder selected.
works fine, but "Open Folder Settings" does not bring up a picker, should it?


Somehow I missed the change in the and only now found it out. What I do not udnerstand is why we need all this code? I think this handler should be removed and the action should be called like it was done previously. Code pointer: It would be great if we could tackle this in December. Thanks
The reason for this code change was that creates a handler for command that passes no arguments to the action: So instead I used with a handler that would forward the argument. It looks like there are other debug commands registered in this way in , so I think moving the code for startDebug there makes sense. The handlers there are shorter and less generic, I'll see if rewriting the startDebug one that way causes any issues
what you need is calling the start debug with a configuration, and I believe we already have a way for doing this. can you please provide a pointer to where you are already calling start debug with a configuration. are you calling start debug from the main side or where from exactly? I can also look into this. You can just let me know how to verify that I did not break your scenario.
The extension API's implementation passes a debug configuration to the debug service's startDebugging here:
I'm trying to start debugging from the process explorer. Since it's a separate browser window, it doesn't have access to the debug workbench service, and it's also not an extension, so it can't leverage the extension API for starting debugging. Currently, the process explorer window sends an IPC message back to the issue service in the main process. This then sends an IPC message to the main renderer process to run the debug start command: The path is also used by the native menu to trigger commands from the main process.
ok got it. So the best way it seems is to what you have done going via the action. Can you try to clean up the handler. And if that does not work I can look into an alternative solution.
Sure, I'll work on cleaning up the handler today


On Windows: something with a rich hover in a tree view, like an extension or an item in the activity bar +tab off the window back to VS Code the hover is still there and stays around around until you hover something else with a rich hover, or click on it and hit escape


Type: <bBug</bThank you for all the improvements to walkthroughs in the latest release, however I noticed that the following issue started popping up after the changes to "save" your place in a walkthrough when changing tabs. When you have a walkthrough open: to a different tab in the same editor window back to the walkthrough that the media on the right side of the walkthrough is no longer present steps 1. and 2., note that the media has reappeared. If you repeat steps 1. and 2. once more, the media will dissapear again. This process can be repeated any number of times to "toggle" the media's visibility. Jumping between steps will also cause the media to reappear.


Screen recording: VS Code version: Code 1.87.0 (Universal) (, 2024-02-27T23:42:56.944Z) OS version: Darwin arm64 22.6.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (34)</summaryExtensionVersion ------ vscode-markdownlint0.54.0 vscode-eslint2.4.4 gitlens14.8.2 EditorConfig0.16.4 prettier-vscode10.1.0 go0.41.1 vscode-drawio1.6.6 debugpy2024.2.0 isort2023.10.1 python2024.2.1 vscode-pylance2024.2.3 jupyter2024.2.0 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.348.0 makefile-tools0.8.22 vsliveshare1.0.5918 ansible2.13.148 java1.28.1 vscode-yaml1.14.0 sonarlint-vscode4.3.0 code-spell-checker3.0.1 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-java-debug0.56.2 vscode-java-dependency0.23.5 vscode-java-pack0.25.15 vscode-java-test0.40.1 vscode-maven0.44.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --


We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.


Copied from My workaround is export VSCODEGITASKPASSEXTRAARGS="--title=foobar" but the proper bugfix should happen in VSCode's GIT_ASKPASS implementation.
I experience the same problem, from the moment been released. Working through remote ssh the git processes stay open, without anything happening.
Still facing this issue on WSL.
Will be fixed in upcoming 1.62.2. Meanwhile a workaround is to and then manually
I can confirm that this is fixed after updating to 1.62.2 ().


Steps to Reproduce: to 1 window on a folder open the command line run = only the folder opens, but not an empty window I would expect here 2 windows to open, one is the folder and one the empty window since no argument was given to open any folder or file.


Testing a Markdown file with headers up to H3, enable Sticky Scroll and scroll up and down in the editor. Stick Scroll a header leve and press . Try to scroll up and down with the arrow keys. Unclear where the cursor focus is. Try typing, the editor doesn't have focus Focus should should probably go to the editor on the selected header. That is the behavior with breadcrumb navigation
This is the general behavior of Sticky Scroll and also reproduces if you select a level via the mouse
Verified on OSS


Type: <bBug</bA corrupted file is stored in CachedExtensionVSIXs and never re-downloaded, preventing extension from being installed until the file is manually deleted. Repro: Attempt to install an extension while the Azure DevOps service is not available and returning errors. Result in this comment: The corrupted vsix contains the following HTML instead of zipped data ! Shared Output: VS Code version: Code 1.84.2 (, 2023-11-09T10:52:57.054Z) OS version: Darwin arm64 23.1.0 Modes: Connection to 'SSH: ox' could not be established Canceled <details<summarySystem Info</summary Connection to 'SSH: ox' could not be established Canceled </details<details<summaryExtensions (31)</summaryExtensionVersion ------ vscode-ron0.11.0 vscode-eslint2.4.2 prettier-vscode10.1.0 kotlin0.2.32 copilot1.139.0 copilot-chat0.10.2 copilot-labs0.17.1121 vscode-github-actions0.26.2 better-cpp-syntax1.17.2 vscode-peacock4.2.2 vscode-clangd0.1.25 membrane1.6.1 vscode-dotnet-runtime2.0.0 vscode-postgresql0.3.0 remote-containers0.321.0 remote-ssh0.107.1 remote-ssh-edit0.86.0 cpptools-extension-pack1.3.0 hexeditor1.9.12 makefile-tools0.7.0 remote-explorer0.4.1 proto0.0.4 vscode-yaml1.14.0 vscode-gitweblinks2.9.3 rust-analyzer0.3.1748 even-better-toml0.19.2 shellcheck0.35.0 es6-string-html2.12.1 vscode-lldb1.10.0 vim1.27.1 clang-format1.9.0 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
cc who was looking into this in
<!-- 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!
bumping to see if this issue is still occurring and if the fix has been verified!
It's somewhat fixed. You can try again and the second time it will work. But the error message that appears doesn't indicate that. perhaps it should retry at least once if the zip is corrupted before showing this error? Note the bottom right popup asking to manually download where a retry could've sufficed. <img width="1304" alt="Screenshot 2023-12-06 at 6 14 41 PM" src=""
Thanks for the feedback. This bug is to fix not to cache corrupted VSIXs and please validate that. Regarding trying again, I do not think we should be showing this as this might be random.
Verifying with a code review


String Text: Show the name of the file. When tabs are enabled and two files have the same name in one group the distinguinshing sections of each file's path is . When tabs are disabled, the path relative to workspace root is shown if the editor is active. Context src/vs/workbench/electron-browser/main.contribution:English (en) Resource vs_workbench Query: Typo in source string. distinguinshing-distinguishing. Should'nt it be "the distinguinshing sections of each file's path are " and not is? Reference: $/?issue=yes


To reproduce. click smiley in the bottom right of editor window. The feedback form should appear enter several characters, press "Enter" (the new line should appear) continue entering characters while you can You should stop at "1 characters left" (declensions?) After that you will not be able to enter anything On the screenshot. There's a newline after "1". I reached the end of input and unable to enter more characters. But counter still says "1 characters left": <img width="468" alt="" src=""Mac OS 10.10.5 Yosemite
This is interesting. I created this to reproduce the behavior. do you have any thoughts on this? Here are a couple ideas we've talked about before. 1 - Remove the text area completely and replace with just the tweet button. This makes sense because we're submitting to twitter anyways. 2 - Hack the text area element to get better behavior. This would involve looking for new line characters based on the batter described by OP. I'm not a fan of this as it seems error prone. If we go with option 1, I'll work with Brad and get some design love on the form. any thoughts? I created PR to fix the "s" on singular count issue.
Thanks for your amazing job and thanks for asking! :blush: If the "Tweet" button will not require having a Twitter account, then it's a solution, I guess. I feel a bit weird reporting those super-tiny issues that still require developers time. Is the related (then we should star it)? Probably even disabling line breaks (like turning into line input) could be a solution.
Yes that is the exact issue. Starred it! I thought about disabling line breaks, but I think it would be a good thing for the user to do, considering Twitter supports line breaks. The Tweet button wouldn't require a Twitter account, but once the Tweet button takes them to twitter they would need to login.
Well, the need to login on Twitter is a requirement to have a Twitter account :blush: I wouldn't think it's a good UX :relaxed:
Right. Unfortunately Twitter doesn't support anonymous tweets.
After some internal discussion we decided to go with a dialog redesign. Will work with our UX designer to get some help.
Closing as it will be fixed with .


Does this issue occur when all extensions are disabled?: Yes Search rearranges the items according to how well they match, so items are no longer in the original groups. Because of that we remove the separators. (See, e.g., the theme picker.) Initial state: <img width="622" alt="image" src="https://user-"When typing: <img width="651" alt="image" src="https://user-"Steps to Reproduce: items and separators in the quickPick (grouping). to search VS Code Version: Version: 1.77.3 (Universal) Commit: Date: 2023-04-12T09:19:37.325Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin arm64 22.4.0 Sandboxed: Yes
Hi which extension is providing this quickpick?
Hello ! This is my debugger for .NET apps QuickPick implementation:
Any updates?
I can repro this. I'll get this fixed ASAP but as a workaround you could listen to the event that fires when the user updates the filter value and then clear out the separators from
Thank you,
I have a fix for this. It won't make it for this release on Wednesday, but it'll be in the following release (late May/early June)


<!-- 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. --There is Title Case, Snake Case, Lowercase, Uppercase, but no Camel Case. It would be nice to transform: -
It would be a great feature. You could use that extension: until then. I also think that they should work on the to exclude articles and even custom words. instead of which is not accaptable in many academic organizations.
<!-- -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!
<!-- -a7ce-58b9-b1f9- --This feature request has not yet received the 20 community it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our . Happy Coding!
<!-- -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!
Up for a PR anyone?
I to do this. I have more details in the PR description about how different use cases should be handled. I don't really have a strong opinion on it. I wrote a personal extension long ago that has it's own set of rules, so I probably will keep using that over the one I implemented in the PR.


In OSS not insiders (so not a candidate) Steps to Reproduce: shows error This is because the gets run in a separate process than the Extension Host and so the vscode.l10n API isn't available. Proposed fix is to not localize the single error message being localized since it's not surfaced to the user.


<!-- 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/No <!-- 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. --- VS Code Version: 1.85.1 OS Version: macOS Sonoma 14.2.1 Steps to Reproduce: a python file or other file with a debugging extension installed Debug view and see the welcome view showing Run and Debug Actions. a diff Editor for the same file debug view now shows an Expected: Debug view shows the same welcome state as when not in diff view as this language has debug extension installed. <img width="694" alt="image" src=""Actual: !


<!-- 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. --- VS Code Version: N/A OS Version: N/A Steps to Reproduce: presence of in the example above means it should apply only to documents, not "all" as the text suggests


Type: <bBug</bFuzzy search icon is visible in Go to Symbol view (Shift + CMD + O) which on press opens terminal recent search with fuzzy search. I think that button should be excluded from Go to Symbol view and be visible only in terminal recent search view. VS Code version: Code 1.73.1 (, 2022-11-09T02:22:48.959Z) OS version: Darwin arm64 22.1.0 <img width="607" alt="image" src="https://user-"<img width="597" alt="image" src="https://user-"


STR: VS Code with locale set for language prompt and close it VS Code and repeat 1st step Language prompt shows again. has logic for storing an ignore key after a prompt was shown, but is using the wrong key (language instead of locale). The same variable mixup has caused prior breakage of the feature.
Forwarding to since he owns localization.
I partly own localizations support in VS Code especially recommending. It seems you come up with a fix. Do you mind opening a PR?
Ignore above comment, I see the PR now.
I'm still seeing this in insiders I clicked the on the notification and then restarted. After a few seconds, the prompt came up again
Found it. Only "Don't show again" triggers that logic, but just canceling doesn't. I wonder what the right behavior should be. Other prompts also depend on "Don't show again" (using the option, ) for a similar logic and otherwise pop up again on next launch. cc for guidance.
Clicking is never meant to be not to show again and user has to explicitly select action. I think this is general behavior for all prompts. I would recommend to discuss this UX change separately and mark this as verified otherwise.
Marking as verified based on comments above


A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #Visual Studio Code Client; #BM-VisualStudioCode-Win32-Nov2021; #Win32; #Narrator; #NVDA; #ScreenReader; #WCAG4.2.5 #AINotInScope; #FTP; #STP; Application Name: Visual Studio Code Client Windows Version: Windows 11 1)Turn on Narrator/NVDA. 2)Open Visual studio code editor. 3)Open the command Pallet by pressing "F1" key and type "Theme" 4)Using Down arrow key select "Preference color Theme" and press enter key to select. 5)Using "Up/Down" arrow key select different available theme. 6)verify that screen reader is announcing the associated label for the 'recently used' and 'Other commands' or not. Screen reader does not announce associated label for the 'recently used' and 'Other commands'.. Screen reader should announce the associated label for the 'recently used' and 'Other commands'. Screen Reader users will not get the complete information about the controls. !
The issue here is that the group label "recently used" does not get read. I suggest to append the group name to the aria label of the first element in the quick pick that belongs to that group. I think it should be a low hanging fix.


VSCode Version: Code 1.12.2 (, 2017-05-10T13:20:36.315Z) OS Version: Windows_NT ia32 10.0. Steps to Reproduce: "JSON" file Expected outcome styled as (invalid) content token. Actual outcome styled as comment. Still properly marked as invalid, though. Remarks is OK. Same steps in JavaScript file is OK. ! Ad "JSON" in quotation marks: .


I am writing a debugger adapter. I use ProgressStartEvent/ProgressUpdateEvent/ProgressEndEvent to report some debug opertions' progress information. In previous versions, the progress information was shown in right-bottom corner, however, in 1.86.0, the progress information is shown in status bar instead. I think this is not a good idea, as user might not be able to notice the progress information. If there is a workaround if I still want to show progress information in right-bottom corner of VS code? Thanks! Bill Zhang
I haven't yet found a 1.86 commit that specifically changes this behaviour. Have you perhaps been trying out this new 1.86 feature?
If this is a confirmed regression, it would help to know which change caused it. We maintain a based CLI tool  that automatically downloads and runs previous VS Code insiders and asks for each build if the issue reproduces. It takes up to 8 steps to find exactly the build that caused the regression. Steps: install (if not yet done) follow the instructions until you found the offending build (its fine to leave the commit empty) report back the commit range in this issue Thanks!
The progress information was shown in status bar, not a pop-up window as before versions, so I have no way to enable/disable notification. In addition, notification was shown as before in right-bottom corner.
85 does not have this issue.
If you cannot find the actual commit causing this using , then you need to provide a minimal repro for us to try out.


I have tried the vscode-bisect, but it failed: PS C:gitBIOSDBGV4srcextensionnpx --yes --reset [build] deleting cache directory C:UserszhiqzhanAppDataLocalTempvscode-bisect √ Commit of released insiders build that reproduces the issue (leave empty to pick the latest build) ... √ Commit of released insiders build that does not reproduce the issue (leave empty to pick the oldest build) ... [build] fetching all builds from [build] total 171 builds with roughly 7 steps [build] downloading build from [build] unzipping build to C:UserszhiqzhanAppDataLocalTempvscode-bisect.buildsVSCode-win32-x64-1.85.0-insider... [build] starting desktop build ... √ Is good or bad? » Good [build] downloading build from [build] unzipping build to C:UserszhiqzhanAppDataLocalTempvscode-bisect.buildsVSCode-win32-x64-1.86.0-insider... [build] starting desktop build ... √ Is good or bad? » Bad [build] downloading build from [error] Error: read ECONNRESET You can run vscode-bisect --verbose for more detailed output and vscode-bisect --reset for a fresh start without caches.
At first, it is quick in downloading vscode-insider, but later it takes a long time to download it. I am not sure why. !
thanks a lot for trying it though, maybe some connection trouble. I can try it if you tell me how to reproduce.
I create a simple debugger for testing. code: vsix: I am not sure whether you know how to start a debugger or not: 1) install test-debugger- 2) open a empty folder and then create a ! 3) select Debugger For Test ! 4) Start Testing debugger ! 5) You will see progress information in status bar !
If run in 1.85.2, it is as below: !
thanks! Is it possible that you have snoozed notifications either globally or for the extension?


You effectively see the same notification but when it appears in the status bar, it means the notification is hiding because of the "Do not disturb mode". When you click the status bar entry you can see how it changes to the notification toast.
Yes, you are right. But even in below setting (BIOSDBG V4 is my extension): ! The notification is hidden unless you click the right-bottom icon. ! I think it makes me confused and it is not easy for user to notice this. Thanks!
There is indeed a change that happened as part of our latest release, but I think for the better: debug had always decided to show notifications for debug progress in the status bar via this directive: A change I did last milestone actually made to support it now: So I am deferring to debug component to further triage, but I think this is actually expected behaviour.
I think we should revert to the old behavior for consistency as that's what users have historically seen


<!-- 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. --- VS Code Version: 1.79.0-insider OS Version: macOS 13.3.1 Steps to Reproduce: VSCode in a computer with a relatively old version of Git (2.16.2 does it). a project under version control. control fails silently and only shows the Publish button. Trying to publish causes an error. This seems to be related to a change that makes use of the option in , which doesn't seem to be supported by old-ish Git.
sorry about this. I will try to get this fixed this week.
I am also experiencing the same issue. VS Code Version: 1.79.0-insider OS: Windows_NT x64 10.0. git version 2.17.1
It looks like the option was in git 2.18.0. Ideally you would want to keep your git installation up to date to keep up with the security fixes. Having said that I do understand that there are scenarios in which one cannot install the latest git release, so I have pushed a fix for this issue. The fix will be included in the next Insiders release.
Thanks a lot! I agree with keeping git up to date. Unfortunately I use VSCode with the remote extension in many servers where I don't have control of what version of Git is installed, so having at least some basic Git functionality there is much appreciated.


Hi, I encountered the same issue with my VSCode + WSL1 (I haven't upgraded to WSL2 for some reason) git version: 2.11.0 VSCode Version: 1.79.0
could you please share the complete contents of the ? What version of git are you running inside WSL? This flag should only be in case you have a version of git that support it.
Same issue here
Affecting me too. This seems like a major breaking change. Is there a bugfix release planned? Thanks.
could you please share more about your environment? What version of git are you running (git --version). Are you also using WSL, or any other remote environments? Anything that helps me reproduce the issue would be extremely valuable (ex: the contents of ). Thanks!
Thanks Ladislau Using git 2.17. I don't want to upgrade to insiders build Get Outlook for iOS
could you please run and share the exact output. My current hypothesis is that for some reason we are unable to correctly detect the version number and that is why we incorrectly add the flag.
Let's continue the investigation in this issue Thanks!


Light Theme the Extensions view the Extension item in the list -all letters turn black, the contrast is not good !
Looks like these buttons are inheriting the codicon styling, and as a result, the color. I removed it from Light+ V2 to reset it back to null. Ideally this button wouldn't use codicon styling cc


Remove Manual Folding Range doesn't work Originally posted by in select a range in the editor invoke . Selection turns into a folding range put the cursor at the beginning of the collapsed line invoke . Should remove the manual folding range
It works when the cursor is at the second column or to the right of that, but not when it's right at the beginning of the line, which is exactly where it is placed after running the create manual folding range command.


<!-- 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. --- VS Code Version: 1.56.0-insider OS Version: MacOS Big Sur 11.2.3 Steps to Reproduce: Settings and and editor it manually. a rule: editors can't be edited anymore. <!-- 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 direct to the extension publisher. The 'Help Report Issue' dialog can assist with this. --


Request completions, commit on Expected: Regular completion, no method body OR completion that is otherwise identical to both settings being . Actual
I want to understand this better, since this kind of behavior is also present in other completions I think: how should interact with completions that can or cannot contain snippets? For instance, the class member completion can be a snippet, but it doesn't necessarily have to be, which is why it still shows up in the example above when is false, but the difference is that it's no longer a snippet (i.e. there's no tab stop in the body of the completed method). I guess this bug is saying that this completion should never be offered in its non-snippet form? Is this the case because not having the tab stop in the method's body degrades the user experience? Is it because of some other reason?
Ugh - okay, so there's plain completions completions with insert text completions with tab stops and for some reason, is the one that enables tab stops. Did I get that right?
I think so, yes. Not sure if this this is relevant, but note that while is a setting that is user-configurable in vscode, while is not. Andrew B once told me that's because is supposed to indicate whether an editor supports insert text in completions or not.
I believe it's controlled by setting
and say that this should never have been user-visible in the first place. The flag shouldn't have been passed in as-is to TypeScript. If anything, the editor should use a flag like to blanket enable/disable other snippet features.
I don't see the removed setting anymore so marking as verified.


I'm using to mount a remote Azure Blob storage container into my local file system with FUSE. Once I open up that mount point (say ) in VSCode, network traffic immediately goes up to around 100 kb/s. In the storage provider's API logs I can see many thousand operation requests per second to files located at any hierarchy level inside my storage container, but also files that do not exists (e.g. ). I was assuming this is related to VSCode attempting to watch these files for changes, but can't use inotify on the remote share, so falls back to polling the files with a crazy frequency. However, applying the following settings didn't have any effect: Same issue occurs with or AWS S3 + and I presume also for sshfs, davfs2_ and the like. When killing the sub-process, I can observe a short decline in network usage until the process almost immediately restarts.
In this case I wonder if we should simply not install the file watcher at all if a setting is configured to disable it. I see no other workaround other than maybe addressing this in our external file watcher where we pass on these exclude rules.
Verification: run with and filter dev tools console to to see only file watcher related output configure to have an entry open a folder verify that in the output for the watcher you see no indication that the folder is being watched compare this to how the output looks like when you not have such a setting
<!-- 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!


<!-- 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. --Steps to Reproduce: created this simple snippet: I expand the snippet, I get this: Expected this: It uses the first variable as a part of the placeholder of the second variable. The second occurrence of the second variable is not substituted properly. !
Confirmed... Looks like we capture the value of 1 "replication". For now you can workaround by "inlining" the second occurrence of $1, e.g have two times


Type: <bBug</bSimple Browser to visit a webpage that offers a download. the download. happens :bug: I plan to submit a PR. VS Code version: Code - Insiders 1.80.0-insider (, 2023-06-14T09:02:23.566Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
<!-- 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


Version: 1.94.0-insider Commit: Date: 2024-09-09T17:10:54.809Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce:
<!-- 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!


<!-- 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. --- VS Code Version: 1.62.3 OS Version: Chrome Version 96.0.4664.55 (Official Build) (arm64) macOS 12.0.1 Steps to Reproduce: vscode web version on localhost (use any build similar to ). Make sure the test repository has a jpg file such as the . Use a chromium based browser (not safari). on a .jpg file in the side pane explorer. Note that it takes 1s for the image to load, even when hosted from localhost. Click back and forth on other files and note that text files display immediately but any custom editor or image viewer that uses a webview always pauses for a second before loading Chrome/Edge service worker console and look for the service- version; note that the version increments each time the same webview is opened (and closed). It takes approximately 1050ms to load every image as shown in the following screenshot ! The service-worker for any webview is instantiated inside  with a query string that includes the unique id of the host frame. This is not actually needed or used by the webview code in but causes chromium based browsers to reinstall and reactivate the service worker even though the underlying service-worker code has the same code, eTag and content hash. For some reason Safari does not have the same delay. If the code is changed to only include the query parameter actually used by the script then the end to end browser time is reduced to 50ms on localhost, a 95% reduction The slow load time is experienced when navigating ordinary files in the editor with no extensions installed.


It is also experienced (and why I noticed it) when developing custom editor extensions that use the webview. This makes it appear that built in editors such as the monaco editor are almost instantaneous, but third party editors appear to be 20x slower to load. ! Please see accompanying pull request, as a one line code change.


<!-- Please search existing issues to avoid creating duplicates. --- VS Code version: 1.62.3 (Universal) Jupyter Extension version (available under the Extensions sidebar): v2021.10. Python Extension version (available under the Extensions sidebar): v2021.11. OS (Windows Linux distro) and version: Mac Python and/or Anaconda version: 3.7.12 Type of virtual environment used (N/A ...): conda Jupyter server running: Remote I expect code cells to begin executing immediately and (for simple code snippets) to finish executing immediately (e.g. print('hello')) Once the jupyter notebook starts to contain a non-trivial amount of stuff, I start to observe the following behaviors: (1) code cells that contain simple tasks (e.g. ) start taking several seconds or more to complete, (2) it may take several seconds or even minutes for vscode to even visually show that it will start executing a code cell, and (3) in severe cases, the whole vscode editor will become unresponsive and I will need to force shut it down. Below is code for a jupyter notebook that contains a minimal example. The problems start to appear once you've cycled through the code cells 2 or 3 times. I think one of the main contributing factors to this issue are just notebooks that have a lot of "stuff" in them. To demonstrate that, the last code block prints 50 scatter plots as pngs, which the native jupyter lab server over the browser handles just fine... but vscode seems to have issues. Moreover, in this simple example I have observed instances where it starts to take a while to save the notebook and the editor may even become unresponsive. Other things to note: I am running this jupyter notebook on an AWS EC2 instance with ~90GB memory 48 CPUs (using a AWS linux ami: ). I have not yet observed these same issues when I have the kernel running on my local mac machine. <details<summaryJupyter example </summary<p</p</detailsHere is a screenshot where it takes almost 3 seconds for a simple print statement. I've seen worse in some of my code related to real projects, though. This is just what I was able to reproduce with a minimal example.


<img width="1593" alt="Screen Shot 2021-11-22 at 4 48 27 PM" src="https://user-"
Thanks for filing this issue & I'm sorry you're running into this issue, please could you try the following: Check the performance withouth any data frames in the outputs You can run most of the same cells, but not display the outputs (e.g. don't run the cells with ) I'd like to check whether the perf is a result of large outputs. If that doesn't make any difference please could you: Install VS Code Insiders Go into your settings and search for and change the logging level for Jupyter extension to Reload VS Code Try the same thing & provide the logs from the output panel (use the command to get to the output panel)
Thanks . Not displaying large amounts of output does help. I experimented with the code a bit and here are my observations: (1) If I disable the cell with just the statement (but still outputting the figures), while it helps a little, I still see a significant slowdown. In particular, once I execute the code block that prints the figures (see below) and it is done, I try to execute the first code block again (containing the import statements), but there is a good 30-60 second delay until it will start to executing. (2) If I still create the figures but no longer display them (see below), this helps immensely with performance... there are basically no issues. (3) While still hiding the figures as in (2), but I go back to displaying and increasing the number of columns and rows of that are display to 200 (see below), then there is small decrease in performance. (4) If I do the same as (3), but take it even further by displaying 500 rows and columns of , then performance significantly degrades (see the screenshot). Once it was done displaying , it took ~19 seconds for a print statement, ~35 seconds to make the figures (normally takes a ~3-5 seconds), and it took over a minute to execute that last empty cell (the execution time was hidden once it was done). <img width="1585" alt="Screen Shot 2021-11-23 at 10 14 06 AM" src="https://user-"
Thanks for the feedback.


Please could you: Install VS Code Insiders Go into your settings and search for and change the logging level for Jupyter extension to Reload VS Code Run the command An editor will be opened with some text such as , please copy all of that & paste that into this issue Try simple print statements (without any data frames, and figures, lets keep it very simple) Please ensure the notebook is empty & does not contain any outputs only 1-2 cells with simple print statements. Provide the logs from the output panel (use the command to get to the output panel) Reload VS Code Repeat what you did earlier Provide the logs from the output panel (use the command to get to the output panel) Please note, I'll need two logs, one without any data frames, no plots, just print statements. The other is the one with dataframes and the like.
Here is the text for : Even if vscode totally froze up while trying to run something in jupyter, I was still always able to ssh into the server no problem. Here is the Jupyter output from just the print statements: <details<summaryLog</summary</detailsHere is the Jupyter output where I print large dataframes and plots: <details<summaryLog</summary</detailsFew other things I've observed: (1) In the second log above, I see there are some lines like in it, but I was not always able to reproduce that output. (2) Here are some additional logs that I observed while it took 15 minutes to execute a cell with a simple print statement (but it was executed after cells with the dataframes and plots): <details<summaryLog from </summary</details<details<summaryLog from </summary</details
Thanks for the logs. Transferring to VS Code due to connectivity issues with remtoe SSH
Also having this issue with jupyter over ssh, in a notebook that has a decent number of plots.
This issue happened with me also (especially when i am insider a docker container inside the remote machine)
I have the same issue, even when I freshly open a notebook with some outputs it is very slow and unresponsive. <img width="273" alt="image" src="https://user-"I have a stable connection to the server: !
Same problem, sometimes it works fine, sometimes it is unusable, stable and insider !
After discussion in sync.


Possibly add logging for every message that's only turned on if the user explicitly is told to (for debugging purposes).
experiencing similar issues when working on jupyter via ssh to an ubuntu server from an ubuntu pc
ALso had the issue where running a cell lags(or starts after some time) for jupyter notebooks when using remote SSH aws azure
Still the same problem
I also experience the same. I observed that: It happens with Jupyter notebooks, but not in the Interactive window. It does not happen if you connect to a Jupyter kernel that is not managed by VScode. It happens when your notebooks has many figures. I hope these may help diagnose the problem.
Same here..
As an additional info to what enlightened us. Jupyter execution on remote ssh machine slows down (i.e., gets stuck) when notebook size is large (64 MB). VS code executing notebook cell normally for smaller sized (ie., 1MB ) notebook
Would it be possible to share such a notebook? Is the size 64 MB with or without ouput in the notebook? If its a large file you could optionally email it to one of us (us = Microsoft maintainers of VS Code)
sorry that is confidential work for the time being.
Experiencing the same issue as well. Networking is not a problem since I connect to the notebook's machine on a local network
I've also been having this issue lately although I think it only happens in certain circumstances. I can't share the notebook I'm working with at the moment as it's private (sorry!), but it does have many matplotlib figure outputs and dataframe outputs. The notebook itself is only 3.6 MB in size. I'm running the notebook on a Linux server with Python 3.9.7, specifically I'm connecting to the machine remotely with "Connect to Host" to edit and run code on the server remotely. Latest version of VS Code and all extensions, connecting from a machine running Windows 11. It seems connecting on the same network as the machine with my Linux laptop doesn't result in any issues, and I haven't noticed any problems with running the notebook from there. However, connecting from a different network when working from home causes the same notebook to be very laggy, including lagging for 30+ seconds on simple code cells containing e.g. just a print statement.


I don't see how network speed/my connection to the server from home could be the issue (12ms ping, ~5 Mbps upload / ~50 Mbps download connections). Maybe there's something in the different OSes having different results, could also be unrelated though. I should try connecting with a Linux machine not on the same network and see if I can reproduce the results.
Same problem here, just a correction it is not dependent on the figure number or commands difficulty, will take to execute 30 to 40s, and yes with a separate instance of Jupyter Lab server (not managed by VScode). Directly connecting to Jupyterlab over ssh port forwarding order of magnitude faster. Workflow: Windows to Linux remote SSH (cluster) Another instance in the cluster used to set up JupyterLab instance Change Jupyter server to remote of the previously created instance execution super slow (even delay between starting and finishing) ~ 30 second delay followed up by ~ 40 s execution Connecting directly from Windows tunnel to JupyterLab ~ few seconds execution Note: Both the Jupyter Lab instance and the initial remote ssh share access to the file system, just different hardware. Also after changing to remote, some shenanigans happen with the vscode, unable to open files, etc, had to restart everything to make it work again.
I've had the same issue with VScode and Jupyter - notebooks becoming unresponsive after a few cells are used. The console shows continuous (every 20 seconds) reconnecting. with the level set to "trace". I can share a relevant file if it is helpful.
I've had the same slow issue with VScode and Jupyter when connecting to a remote docker container via ssh, and I've also observed that keeps producing tremendous streams
If someone can share a notebook that triggers this issue (lots of outputs, graphs with lots of data, etc?) that would be helpful, thanks
I noticed that if I switch the format from svg to png (by changing the setting ), the notebook would run smoother.


My network: Roundtrip latency: 5.520ms Up: 2898.6 Mbps Down: 3007.5 Mbps Authority: ssh-remote+** Roundtrip latency: 21.320ms Up: 25.8 Mbps Down: 385.0 Mbps A test notebook (1KB zip file), need , and to run:
Having the same exact issue and it renders the jupyter unresponsive: ! And it's still running. A temporary solution I found is to click on "Clear outputs for all cells" and more often than not it works smooth again. Only works if the cell stops executing though...
I think notebook size may be the reason.
I resolved my issue by closing the JUPYTER: VARIABLES in the terminal below Maybe in my case was an issue with the output variables inside the jupyter section ..
I resolved it by using a jupyter server running on the remote machine which was not started by VSC. I'll use that until this bug is fixed unfortunately
life saviour! "Clear outputs for all cells" worked smooth as butter (:
Happy to help. I saw in one of the other tickets this bug has a synergy with notebook size, and since clearing all outputs reduces notebook size, this might be a temporary fix until the size increases eventually and we need to do it again. I would love to see this fixed as this bug is the biggest hindrance to me day-to-day vscode experience.
Same here, this issue was driving me crazy. That's the solution indeed, I had a lot of local memory usage in my code, not sure about what was the actual issue. EDIT: it seems I spoke too early. When a cell takes very long to compute, vscode seems to "disconnect" from the kernel, and any subsequenc cell evaluation waits forever without running.
I pushed a change which should mostly fix this slowness with large outputs. I think there are more optimizations we could do. The issue comes when a save happens, and this blocks the remote extension host process for some period of time. Then a symptom of that might be that an execution appears to hang or take a long time. Would appreciate anyone trying this out in tomorrow's vscode insiders build.


If you're seeing an issue related to the variables view, that wouldn't be fixed here, however I recently pushed a different fix that may help with that, and you could try it out in insiders + the jupyter pre-release extension.
I have been experiencing these slowdowns (specifically on an AWS server) and I don't use the variables view. I definitely found that clearing cell outputs eliminates the hangs. I'm confused how this is caused by saving though, because I just found that the notebook I was working on wasn't being saved. I was doing some work tethered to my phone as I rode a bus into remote mountains. Certainly noticed that the bad connectivity meant even more waiting for things to execute than usual. Unfortunately, when I got back to stronger internet vscode was complaining it couldn't connect and was hanging when it tried to save. I figured it was fine since I saw 's comment and naively interpreted that as meaning I should feel comfortable that my notebook was getting saved each time it hung. Nope. When I finally had to reload window to get things back to working I found that all the code I wrote on the bus was no longer in the notebook (no worries, I had copied it out just in case, so no loss). I'm trying the 2023-01-13T07:49:05.588Z insiders build right now (is the "tomorrow's" build that should have the changes?). I think it is still too soon for me to be able to offer an opinion on how much of an improvement this fix might be. It is hard because the problem is erratic: sometimes cells execute immediately and sometimes it takes 20 seconds or longer.
Yeah, that version has the latest fix, you might have hit a different issue. And the issue might still have been kicked off by the notebook attempting to save. I'll leave this issue open to track namely, we still send notebook data between the processes more often than we technically have to, and I think that can be improved. Sorry about that, glad you had it saved, the intent is that the unsaved changes would have been persisted on the frontend.
I can confirm that this change is a big improvement for my use case. If those additional optimizations ever get prioritized that would be amazing and appreciated, but I'm already grateful for this improvement. Thank you!


On second thought, closing this issue, and moving other work to
I have tried the insiders version on a podman container accessed on a machine over ssh (so I do vscode remote via ssh to the machine and then I use remote containers to access the container). It does not open a terminal and seems to be spinning forever with the following error in the logs: 2023-01-27 10:40:00.790 [info] [LocalProcess0][resolveAuthority(attached-container,27)][1013ms] waiting... 2023-01-27 10:40:00.818 [error] Shell server failed: Error: stream ended with:4 but wanted:9 at u (c:Usersvince.vscode-insidersextensionsms-vscode-distextension) at c:Usersvince.vscode-insidersextensionsms-vscode-distextension at s (c:Usersvince.vscode-insidersextensionsms-vscode-distextension) at Socket.<anonymous(c:Usersvince.vscode-insidersextensionsms-vscode-distextension) at (node:events:538:35) at endReadableNT (node:internal/streams/readable:1345:12) at process.processTicksAndRejections (node:internal/process/task_queues:83:21) May this be related to the recent changes or shall I seek for another bug report and eventually open a new one?
Not related to this change- you can open an issue against the Remote Containers extension, I'm not sure how to interpet that error
Hello, I have installed latest Insider's VS Code, maybe it's a bit better now, but in general issue is still there. Very slooow Jupyter Notebooks on large content. I'm using jupyter/r-notebook docker image to run on AWS EC2 instance and have 2 options to acces it: from browser on 8888 port to web version of Jupyter notebooks. It works lightning fast and responsive. over SSH to EC2 instance and then "Attach to running container" So if I compare those 2 options there is a huge difference in UI when notebook has some data and charts. For me it feels like VS Code continuously sends data to server. Even dropdown for intellisence takes few seconds to load.


It's so sad that I'm unable to use VS Code Jupyter Notebooks for my work. But if I create a brand new empty notebook in VS Code - everything works like a charm!
We have experimental saving logic for Remote SSH, it would be great if you can give this a try and see if it improves the performance on large notebooks Install latest VS Code Insiders Remote SSH into your remote machine Add to your Remote/User settings Reload the window Then test the scenarios which used to slow or block the network Thanks in advance!
The improvements are noticeable, thank you for your great work! However, the latency is still there and appears to be significant from time to time. I love this ssh-notebook function, and I believe there must be more folks like me. Hope your team can prioritize this issue. Appreciate!
Hi, I just checked VS Code Insiders 1.81.0 version with "Remote Save" feature enabled in settings. I have generated in a loop 30 charts in first cell and after this I run code in a new cell. It still hangs for a while after generating charts for the first run. If I run second cell code again, it executes immediately as expected. So we still have an issue when a lot of data (or visual data) was generated recently. I checked the same code in web UI of Jupyter - and it works fast. Anton. From: Peng Lyu Friday, June 30, 2023 12:33 AM To: microsoft/vscode bo44arov Mention Re: [microsoft/vscode] Jupyter over remote ssh sometimes becomes slow and/or unresponsive (Issue ) have experimental saving logic for Remote SSH, it would be great if you can give this a try and see if it improves the performance on large notebooks Install latest VS Code Insiders Remote SSH into your remote machine Add "notebook.experimental.remoteSave": true to your Remote/User settings Reload the window Then test the scenarios which used to slow or block the network Thanks in advance! Reply to this email directly, view it on GitHub, or unsubscribe You are receiving this because you were mentioned.Message ID:


Issue Type: <bBug</bKeybindings GUI (Sometimes optional) Scroll down/up over empty when columns shows when contexts from some other rows VS Code version: Code - Insiders 1.31.0-insider (, 2019-02-01T18:34:04.940Z) OS version: Windows_NT x64 10.0.


Chinese (Simplified) : <img width="321" alt="image" src="https://user-"English : <img width="272" alt="image" src="https://user-""Create Manual Folding Ranges from Selection" is not in Command Palette when use Chinese (Simplified) VSCode Version: 1.71.0 (both macOS & Win10) Chinese (Simplified) Version: 1.71.
Thank you for your feedback. We are currently reviewing it (reference ).
Could you please assist here? Thank you.
The problem is this label: should accept an  but it only accepts a string. deeper: and deeper:
The workaround is to use  to find this item.


<!-- 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/No <!-- 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. --This problem occurs on the vscode server. Here is the version information. Version: 1.91.1 Commit: Date: 2024-07-09T22:08:03.155Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 Steps to Reproduce: I'm not sure if this issue has been fixed yet. I reproduced the problem on the vscode client, installing the plugin, and connecting to the remote. My system is Windows OS. ! I'm trying to reproduce this problem. On a windows server, the fsPath is spliced by . When verifying, The authority of the URI is localhost:8080. Therefore, the verification fails and an error is reported in the search box. I took a look at the code and changed fsPath to path in line 257 of the file. The query works fine. But fsPath is still concatenated with . I would like to ask, what is the difference between fsPath and path? When does fsPath use to concatenate. Looking forward to your answer. !
I found the reproduction scenario of problem three. This is the IDE version information.


Version: 1.91.1 (user setup) Commit: Date: 2024-07-09T22:06:49.809Z 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. Steps to Reproduce: the vscode and remote-ssh extension to a Remote Server any project a file that is not in the current workspace the search view and select Search only in open Editors button Keyword !
Can you file separate issues for these three? Or at least a separate one for the first two? I'm not sure if I understand what you're saying here, can you rephrase? What OS is your remote? I'm assuming it's windows if the path uses path separators?
Okay, I've submitted questions one and two separately. This means that you open a file in the editing area that is not in the working area. You can refer to the file opened using the Open File... menu in the gif image. My remote is linux.
Also, please confirm if this issue is also present on vscode server, I am seeing this issue on vscode server as well
Hmm, yes, I can reproduce this issue.


Testing Issue Type: <bBug</bextension search box, type Bug start showing up instead ! VS Code version: Code - Insiders 1.26.0-insider (, 2018-07-30T05:11:25.700Z) OS version: Darwin x64 17.7.0 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
what should we do in this case? We aren't able to change how these match. We could disable fuzzy finding entirely


Have file named in explorer Copy/paste it Window hangs This is from We shouldn't attempt this when the number is = Number.MAXSAFEINTEGER. It loops forever here: This bug will happen whenever incrementFileName fails to modify the file name.
I guess only interesting thing about this what we should do in this case as we need to create some new file name? Add without changing the original number?
that sounds reasonable


All of a sudden, I no longer have GHPRI installed. When I go into I see Settings Sync removed it 11 hours ago, but I'm 100% sure I never uninstalled it. I know I have Settings Sync enabled in both and are those scenarios doing unexpected things to my settings sync? !
I am sure that 4 days ago I re- the extension. Today, I'm on another machine, and GHPRI is again gone.
Lets sync on this
Closing as I couldn't repro.
I was able to reproduce this issue. will sometimes remove and then readd the GitHub Repositories, Issues & PR, and remotehub extensions, except it doesn't readd the keypair to the config, so when I return to my local installation the extensions will sometimes disappear. Not sure why it doesn't always reinstall though. Sometimes won't readd the missing extensions in time, so it gets removed. When the extensions are without the keypair, the local machine can occasionally readd the missing config and keep the extension installed; other times it won't and the extension is removed. Local machine logs from yesterday: Extension config history: Remote removes extensions: Remote readds extensions, but not marked as installed: After I reinstall the extensions locally: logs from a repro today: Extension sync history: Removed extensions: Readd extensions:
Thanks for logs and info. Reopening for investigation.
I am able to reproduce this with following steps: 1: Install GHPRI pre-release extension and sync .dev: Trigger Sync. Note that this is a builtin extension here. 2: Trigger Sync - Make sure GHPR extension is installed. 1: Uninstall GHPRI extension 2: Trigger Sync - Make sure GHPR extension is uninstalled. .dev: Trigger Sync. Make sure GHPRI extension exists in builtin extensions. 1: Trigger Sync. Nothing changes. 2: Trigger Sync. Nothing changes. This step and above step are important because, even though nothing has changed, these machines update their last sync state to have GHPRI extension has builtin extension. 1: Install GHPRI pre-release extension and sync 2: Trigger Sync GHPRI extension is not installed. Come back to Desktop 1: GHPRI extension is removed.
Improved extensions merging to make sure the builtin extensions are handled properly.


Each machine remembers what builtin extensions it syncs and make sure it won't remove them while syncing. Also some logs to get more information if the issue still occurs.
If I uninstall GHPRI from desktop and then Sync Now in , the extension appears to be 'uninstalled' on , is that expected? ! After reloading the extension is still installed though.
I don't have a second desktop to verify with at the moment.
Yeah in your case it is expected because, GHPRI extension seems to be user installed and settings sync is removing that.


Steps: extension that registers a document and a document range formatting provider open a test workspace that activates the extension and trigger a range format. You get:


run open in your favorite browser add a breakpoint at notice how the breakpoint is hit every few seconds this ends up transmitting data from the server to the client
A heartbeat fires every 5 seconds so we can detect when the pty host becomes unresponsive: Open to ideas on how to improve this but it's working as designed right now.
Idea: determine if the pty host is responsive or not on the server process only communicate the status of the pty host from the server to the connected renderers when the responsiveness of the pty host changes.
That should work, we only care about the event when it's going from unresponsive-responsive anyway.


Seeing 2 test failures today for integration tests in Web ():
feel free to skip them if needed, they're known to be flaky. This was my top priority for debt week but it was completely consumed with the settings sync preview.
you mean flaky in general or only for web?
Flaky in general, it seems especially on web though.
We can leave them running, I am not seeing them failing often, just found this one. It is not something to look at now, but eventually. Will revisit if I see this again more frequently.
ok seeing them fail again today, pushing to disable them when running in web via checking for . Your tests seem to have a questionable use of , I see one error being that is called multiple times. Why do you not rewrite to use async and promises?
Another one:
I ended up disabling them all for web:
Maybe this has now leaked from the tests into the code itself. I'm creating a new terminal within an extension using the API and give it a pseudo terminal. Sometimes the terminal is shown but no output is displayed and does not work. But I can also see no error or trace. This happens for me in vscode 1.44.2 using linux.
Is this still an issue?


VSCode Version: Code 1.15.1 (, 2017-08-16T18:07:25.676Z) OS Version: WindowsNT x64 10.0. Extensions: ExtensionVersion ------ overtype0.2.0 python0.7.0 theme-dark-plus-contrast0.1.101 cpptools0.13.0 monitor-file1.0.1 (4 theme extensions excluded) Steps to Reproduce: there is such line in a *.bat file rem set SERVERVERSION=5.7 cursor on it, and uncomment with "Ctrl+/" expected: set SERVERVERSION=5.7 actual result: REM rem set SERVERVERSION=5.7 Looks like uncomment is unnecessarily case-sensitive. It should uncomment despite it is 'rem' or 'REM'. I don't care whether with next "Ctrl+/" it will add Upper-Case 'REM' instead of 'rem' - it is not problem. <!-- Launch with to check. --Reproduces without extensions: Yes/No


<!-- 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/No <!-- 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. --- VS Code Version: Version: 1.74.3 (on ) OS Version: Linux, Gnome, Chrome Steps to Reproduce: an image in the media-preview extension click on the image and select copy to paste the image somewhere Nothing happens. Also note that Cut and Paste make no sense here as menu items. I assume that these are just the default context menu options from - perhaps these should be removed entirely from the preview extension and we could manually implement copy?
Hey I would like to work on this issue.
assign this to me
Are these the correct steps to reproduce the issue? I'm unable to verify it on my mac. Can you provide more information? I previewed the image and then copied and pasted it. <img width="950" alt="image" src="https://user-"
I would like to wokr on this issue.
I would like to try solving this issue.
You right-click an image and select "copy", then you click a folder in VSCode's explorer and select "paste". The image should be pasted into that folder but it doesn't.
I would like to work on this issuse. here, I tried to copy and paste (Ctrl+v) it. But it doesn't work. https://user-
After a day of researching, I think I can explain why this issue happens.


Basically in the core webview module (see ), three default context menu actions (cut, copy and paste) are to the menu, which are accessible throughout all webviews, and happens to be one of them, so after you right-click anywhere in a image previewer, you will be able to see these three actions. After you clicks one of these actions, the editor will post an message to the image previewer, telling it to cut, copy or paste. If there is a correspondent listener for this perpose, the image will be actually cut, copied, pasted, but unfortunately there is no such listeners defined. This problem has existed for quite a bit of time. The original modification that cause this problem is from here . It is origianlly meant to allow users to copy selected text within an extension's README page. There is also a closed issue that describe such issue in . Personally I think providing action cut, copy and paste for all webviews is a little bit hasty, since there are not universally required for each webview, and even some of them need, the subject to be copied may vary from different webviews, or even different places in a same webview. I can solve it by disabling the default actions first (there is a option to achieve this), then let image previewer to implement its own copy and cut functionality, but I think this is rather a quick and sloppy solution. There should be another better way to solve this issue.
What about adding a handler :
Here's what I tried VSC insiders without any extensions Open a folder with a .png file Open the png file in vscode Right click and select Paste into folder in vscode = does not work Paste into markdown cell in vscode = does not work What am i doing wrong?
Pasting image data into folders isn't supported by VS Code. Pasting into a notebook cells works fine for me though. To verify though you can also paste into an external image editor


If that's the case the fix here would be one of: Try falling back to something like in the font family setting, eg. Support custom glyph rendering for those characters, I really would rather not supporting this unless we absolutely had to though.
This bug is still present in Version: 1.84.2/macOS 14. I tried using Symbola, SF Mono, Menlo and Monaco as the main fonts, without success.
I double checked today and it looks like Chrome Version 127.0.6533.89 renders Braille characters without hollow circles on MacOS. <img width="952" alt="Screenshot 2024-08-02 at 10 50 29" src=""(I have a macOS app that's rendering the top bar differently)
So... I spent a bit too long today investigating what was happening here and here's how I've resolved this issue for myself: Before / After <img width="163" alt="Screenshot 2024-08-07 at 22 22 32" src=""<img width="163" alt="Screenshot 2024-08-07 at 22 22 42" src=""In case the diagnostic steps are useful to someone, here's the portion of my search tree that resulted in this solution / bodge.... I looked through my macOS font book for which fonts were providing symbols for (U+2879) and ended up finding "Apple Braille" and "Apple Symbols". "Apple Symbols" had the wrong amount of whitespace when I set that as the fallback font and the "Apple Braille" looked like a drop-in replacement. Turns out, Apple Braille looked different in the OS's Font Book vs in VS Code. The reason for this ended up being that Apple Braille has multiple variants and... for some reason... the version of Chromium being used in VS Code uses either Outline6Dot or Outline8Dot variants by default (these have the hollow/outline circles) instead of the Regular variant which does not have hollow circles. I assume this has to do with the font-renderer-level behaviour. None the less, the of the specific font variant within the "Apple Braille" family that I want to use was "AppleBraille" and adding that to the stack makes it use the correct-for-me variant of the OS-provided Braille symbols!


Alternatively, you can also do what I did recently and change to a font that includes braille characters (like ).
I considered creating an issue for this for the editor as well, but the visualize progress isn't as important there and it's more possible people may want the filled/empty circle rendering in the editor to more easily identify which circles are filled.
This failed the macOS build when merged:


We should also take out the "Terminal" menu when using the custom menu: ! //cc
pushed a fix for this only to the release branch. What we do for master is up for discussion. please verify once the build is out in 30 mins. Thanks
Thanks I didn't know about this code.


VSCode Version: 1.8.0 OS Version: Windows Version 6.3.9600 (Windows 8.1 Enterprise) Steps to Reproduce: High Contrast on Windows VS Code, look at the glorious High Contrast theme a different theme, because you would rather work in that VS Code, your theme choice gets overridden. Essentially, I'd like to be able to disable the auto-detection of the High Contrast theme I'm using in Windows via some setting, because while I prefer Windows in High Contrast mode, I dislike looking at VS Code's High Contrast theme.
I wholeheartedly agree. I'm okay with the default being auto-detection, for the accessibility scenario, but it should definitely be possible to disable this functionality via settings.
An option makes sense to me. If someone wants to provide a PR
Done,
Could you please re-open this issue? Unfortunately, my PR only affected the high-contrast swap that occurred when changing Windows theme while VSCode is open, not the initial theme that is set when VSCode starts, or opens a new folder. I have a new PR that completes the fix.
[x] To verify (Windows): Normally VS Code switches to HC mode automatically when windows is running in HC mode. Verify this new setting can be used to prevent this automatic switch from happening (both on startup as well as when Code is running and you change HC mode in Windows).


<!-- 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. --- VS Code Version: 1.56.1 OS Version: Windows Steps to Reproduce: a (reasonably long) markdown file and scroll down a bit. the dynamic preview for the markdown file. It opens the preview at the top of the file, but should open it where your text editor (containing the target markdown) is scrolled to. This is not adjusted until the user scrolls or resizes the window. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- 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. --


One desired behavior of writing a custom is that when the user accepts a given suggestion, the provider is immediately triggered again for another suggestion. We need to track when users accept (or reject) suggestions so that we can measure improvements that we make. Without using the experimental API, the best way to track if a completion is accepted is to provide a value for the field in . When supplying a command, the retriggering behavior is disabled [1]. As a workaround, I tried to indirectly trigger an inline completion via the command , however, it does not work (not sure why, this does work with my unit tests but not when I try to call it from a command I supply via ). [1] I believe this is the code block that retriggers automatically, one can see that the retrigger only happens if the command is the default command:
Note is related.
Note that [1] points to the autocomplete source code, not the inline suggestion feature. I'm not aware of any disablements.
Ok, that's incorrect -- however, adding a 'command' to disables the automatic retrigger.
Place the cursor after and press enter. Then accept. Notice that is not suggested.
That monaco repro / editor is really cool
Thanks! The best thing is that you can use the "Monaco Editor Playground" launch config in the VS Code repo to debug the playground example :)
<!-- 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!


Using the workspace TS version, 5.5.0-dev.: ! ! !
Closing for verification


Diffing the files: original: modified: <img width="1127" alt="image" src="https://user-"It would be better to line up things differently and give preference to having lines with smaller indent be boundary lines. fyi
Very nice idea!! Very valuable example. I can implement this in the experimental diffing algorithm, and soon we can discuss to deprecate the smart diffing algorithm ().
Implemented in the experimental diff algorithm (not smart). Let's try to deprecate the smart diff algorithm in favor of the experimental in the next milestones.
Closing, as this is implemented in the experimental diff algorithm, which is now the default. To verify, try it out in the playground:


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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.44.2 OS Version: macOS Steps to Reproduce: an extension providing in-editor comments via the comments API an editor containing comments the terminal at the bottom a command which causes the comments to be updated. For our comment provider, we automatically detect comments associated with your source control commit. So, for example, use the command line to checkout a different commit. comments will change, causing some of the previous comments to be hidden. When this happens, the editor is focused. This causes you to lose focus on the terminal. The end result UX is that you're typing commands in the terminal, and your focus gets stolen to an open editor for no visible reason, making it annoying if you wanted to keep running more commands. Notably, this depends on the way the comments API is used. I believe many comment providers do not respond to source control, and require clicking a button to activate/deactivate, so it's likely that's why this hasn't been reported before. For us, this is really annoying, and I could see this hitting other providers in the future. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No, because you need an extension which contributes via comments API
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.562 --- <!-- score: 0.513 --- <!-- score: 0.501 --- <!-- score: 0.493 --- <!-- score: 0.492 --<!-- potentialduplicatescomment --


<!-- 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?: No <!-- 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. --- VS Code Version: 1.86 OS Version: macOS 14.3 Steps to Reproduce: run profile programmatically with isDefault = false seems to restore the previously selected state "isDefault", or if there is none, makes the first profile "Default". behavior works for me. But unfortunately after the profile is created and before its state is changed manually in the UI, it reports isDefault = false. Expected: isDefault matches the UI state at all times. //
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.86.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
This works for me, but note that the synchronization of the new profile is asynchronous after its creation. This is intentional because it's common for extensions to create a profile and then set its properties, like we don't want to cause that to override what the user previously set (especially since making isDefault a 'live' property was a later addition to the API). For me, adding a listener like triggers shortly after its creation
Fascinating! I can't reproduce this bug today.
It seems like there is some inconsistency here
A simple snippet like this surfaces the issue for me: The console is saying And the GUI has run 1 as (Default)
Looks like this is working now:


Add the possibility to persist the content hover sizes
To test, please read the following. Currently the implementation of the persistance mechanism of the content hover works as follows: The content hover has a default maximum size which is defined as follows: const defaultMaxHeight = (().height / 4, 250); const defaultMaxWidth = (().width 0.66, 500); Whenever the content hover is resized, the last hover dimensions are stored. Next time the content hover is shown, the maximum dimensions are updated as follows: const currentMaxHeight = (().height / 4, 250, lastHeight); const currentMaxWidth = (().width 0.66, 500, lastWidth); The content hover is rendered naturally within these constraints. If the lastHeight and lastWidth are smaller than the default max dimensions, then the current max dimensions are unchanged. Therefore the next rendering of the content hover will be the same as the initial rendering. Test that the content hover works according to these constraints. There is some discussion going on about how to better implement a persistance mechanism. We could also persist the size for example on a per-token basis in the editor. Let me know what you think is best!
Do you have an example of how it should work? Regardless of how I resize it, it is not remembered.
You may see an example of how it works here. The content hover is resized to a bigger size in the gif. The current max width is increased to a higher value and at the next rendering of the content hover, the widget takes on a bigger size. To see this behavior you should choose a content hover where the content does not fit in the visible widget, where there is a horizontal scrollbar. I opened an issue for persisting the content hover on a per-token basis here: as an alternative idea.


deferring from as I spent more than an hour on it
This is a little different to how we do it in the terminal because the command palette entry: is registered separately to the command: also doesn't show up at all as a command anymore: Insiders: ! Stable: !
Commenting out the schema fixes the problem for runTask and the commands below.
here needs workspace trust:
removed because the change was reverted so it doesn't work


reported by the aria label for search results should read content first then location IE line/column info ! cc for historical context
Makes good sense, and should be an easy fix.
Interesting - this works as expected on macOS
When replace is disabled, we have a label that looks like Otherwise, if replace is enabled, we have: Would you rather see something like for non-replace and for replace? Not too sure why this would be different on mac. What does the aria say on your machine?
Thanks for looking into this. I have not tried on Windows, but when shared his screen (on Windows), the announcement read the line/column info before the actual content. Do you know where that would be coming from?
should be fixed in
I just tried on Windows and cannot reproduce the behavior that demoed - in which the line/col info was presented before the actual content. We will need to hear from him if it still happens and if so, how to reproduce.
Did you just try on insiders? I just changed the functionality
and Note: is redundant b/c that's the user input search term and users already know what they are looking for, and it takes longer time for screen reader users to hear the actual content.
thanks for clarifying. Re The reason for was to distinguish between that and a . Do you think that we should keep the part of or get rid of both given they require the user's action to get into that state? Another option would be to append to the end of the message.
The reason that we state the match again is for regex users. If they have a fairly general regex, they might want to know what actually caused it to match. Although we could also argue that the line context is more commonly valued by search users, since many people don't use regex.
Thanks for that context I agree that we should optimize for the most common case here.
-- I recommend taking out redundant prefix, including 'Replace'. This is similar to one of the recommended best practices creating alt text. We recommend avoiding any redundant words, such as "Image of " or "Graphics of " b/c users know what they are interacting with.
Using the example from before, we could probably do something like 'VSCode is cool' found in match 'VSCode' in line at column 15 when replace is not active. What do you think the replace case should look like?


The user will know if they're triggering a or , so the idea is to remove both of those terms. So, for search: for replace:
Since the replace hasn't occurred at this point yet, wouldn't be past tense in the results. We can say, instead, but is that too wordy? Also, I feel that the match string is still useful here for those who search for regex, so perhaps that could go at the end? Or we could just read it if they have regex search enabled.
fyi, 'm going to move this to that may iteration because I will be offline for the rest of the April iteration.
I might fix it for you
It sounds like line number is still expected from the comments here, but only the column number is stated. e.g. 'matched context' at column 34 found (1) 1 of 1 Also, finding a match in the first column will state that it was found at column 2
I see why you were confused but is text not a line number there. So this is working as designed.
not sure what you mean by this
created since it seems like a different issue