<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- Version: 1.59.0-insider Commit: Date: 2021-07-31T00:42:32.346Z Electron: 13.1.7 Chrome: 91.0.4472.124 14.16.0 V8: 9.1.269.36-electron.0 OS: Linux x64 5.13.5 Steps to Reproduce: a project directory that is hooked up with tasks via v2. The file must define one of the tasks as being the default. you have bound to a shortcut (mine is ctrl+shift+b) the key combination to trigger the build picker combobox to choose a task appears instead of the default task being executed as used to happen before.
I'm not able to reproduce this issue. Do you have a repository I can test with? I tried with: If there is more than one default build task, then we have always shown the picker. If there is only one default build task, then we run it.
I'm experiencing this with internal company code which cannot be shared. I can share the file. It should work with any c# based project.
Has the schema for changed at all in the past month?
I've replicated this on other similar projects, even those that have just one task defined.
Thanks for the additional details and for reporting this issue!


<!-- 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. --It would be ideal if the Testing user interface would allow to sort/filter based on duration. Use case: I have a large number of tests in my project and they're slow, I want to sort by duration to identify long running tests. !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.595 --- <!-- score: 0.493 --<!-- potentialduplicatescomment --
I want to work on this shall I give it a try ?
Can I get a little help here ? I think I am not able to find the UI in the app. Is this screen capture same as above ? (Left panel) ! I made two tests locally, but I am not seeing the time it took to run the tests ?
You'll need to use to make the Test Explorer use the native experience.
Hey admin, i have just started my open source contribution journey. Can you assign this task to me? so that i can start working on it.
Feel free to submit a PR
Hey Conor, can I work on this issue
, I found that following changes will be needed adding a class to adding to export const enum TestExplorerViewSorting { ByLocation = 'location', ByStatus = 'status', } inside the file
The TestExplorerView is where it happens. You can do a "find all references" on and that'll give you a good indication of places to update
There is such a line for sort ByLocation , but not there for ByStatus , why is it so
What changes should be made to this file , please help me out
Have a pull request for this:


<!-- 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 unable to start container without extensions enabled <!-- 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.60.0-insider (user setup) Commit: Date: 2021-08-16T05:21:19.431Z Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: WindowsNT x64 10.0. OS Version: Steps to Reproduce: VSCode Insiders Edition on Windows Insider gives error every time when logging in to GitHub and other sites 'writing login information to the keychain failed with error 'not enough memory resources are available to process this command'. Also, have set up ssh, but still requires web authentication for extensions every time I open VSCode. It gives the error, but then continues to login after the error and does not save login information. after opening VSCode insiders login to github error and does not save login information tested on current VSCode and doesn't require login every time and no issues with memory (working) Version: 1.59.0 (system setup) Commit: Date: 2021-08-04T23:13:12.822Z Electron: 13.1.7 Chrome: 91.0.4472.124 14.16.0 V8: 9.1.269.36-electron.0 OS: WindowsNT x64 10.0. Regular Edition does not give the error and I do not have to login to github everytime the app starts.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.528 --- <!-- score: 0.528 --- <!-- score: 0.452 --<!-- potentialduplicatescomment --
! did not fix the issue Snapshot of the error message: !
!
there was an issue with the last insiders build. Can you update to the latest one and let us know if you're still seeing this?
Thank you. I installed the update, but unfortunately, it is still doing it. I did a full memory diagnostic and it did not find any issues with memory, and there is plenty of it available. Version: 1.60.0-insider (user setup) Commit: Date: 2021-08-19T05:15:46.693Z Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. ! !
!
Just updated again. Issue remains. Thank you. Version: 1.60.0-insider (user setup) Commit: Date: 2021-08-20T17:51:50.560Z Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. !
This is likely an issue with the library we use for storing secrets called but it's impossible for me to reproduce... so it'll be hard for me to make progress here.
+1 I am now getting this issue on my laptop Where can I find logs or what information do you need that would assist in resolving the issue?
Hey did you manage to fix this? Same problem..
Third that Same issue also...
I am also getting the same issue as well, both trying to sign in with my Microsoft Account for Settings Sync and with GitHub for Settings Sync, GitLens, or LiveShare. Visual Studio 2022 is also having problems connecting to GitHub, and since the new connection successful screen doesn't display the token information, I cannot even connect it manually.
do you see this only when using a Remote SSH/Remote Container connection? Your original video that it was a Remote connection. To the others in the thread, do you also experience this when using Remote?
I see it when using the Accounts -Sign In commands in the bottom left. Whether I use it to sign in to use Settings Sync or LiveShare (with either Microsoft Account or GitHub), or using GitHub for GitLens. I now get the token information with the instructions: Copy the token. Switch back to VS code. Click Signing in to in the status bar. Paste the token and hit enter.5. But, there is no "Signing in to " in the status bar, just the error message noted.
Are you using a Remote? Like Remote SSH, Remote WSL, Remote Containers?
no, just launching VS Code and attempting to sign in. Seems to be a problem with saving the token on the redirect.
I solved this by changing my pagefile settings by doing: System Properties -Advanced -Performance -Advanced -Virtual Memory -Change -uncheck 'Automatically manage paging file size for all drives' -check 'System managed size' -OK -Reboot edit: I'm not sure why the pagefile would affect it though. I have 128GB of RAM.
Thank you , that seems to have fixed it for me as well.
Thanks a lot it worked for me
Sadly, this did not work for me and I share the doubt about how a page file setting can affect this. I even tried it with the paging file completely disabled. Any other ideas?
if you have nodejs installed, you can run this simple one-liner to see if the problem is how your keychain is setup: or if you're on Insiders: This is using the following open source package: What you should get is something like this: If that succeeds, then the problem is possibly in vscode. If that does complain, then we'll need a fix in keytar itself.
I can try this tomorrow.
Hi Tyler, I understand that you can't reproduce the problem, making it hard for you to investigate. I'm happy to try to help. I am on Windows 11 if that makes a difference. Also, on a completely separate Windows 10 desktop right next to me I do not have the problem. I ran the test you suggested and I got back the expected response for github authentication. However, my difficulties are with microsoft authentication. So I changed the command to look for . I got back 100 account/password pairs. 98 of them had in the account field, for example: (Some digits changed in case they are sensitive) The account fields for the other two were and The password fields look quite different from the one retrurned by github. Something like: Probably the most important thing is that only the password returned with the account looks exactly like the one returned by github, sort of like SSH keys. The formats are the same, the digits are just different. So, if I had to guess it looks like the caller of this function is getting back a lot more data than expected and/or needs to filter it to get only the account.
thanks for giving that a try. The content of is different than GitHub. It has a different secret storage schema (that I could get into ... but lets call it as it is "legacy reasons") Anyway, the fact that the script I suggested worked fine, but VS Code fails leads me to believe that this might have something to do with Electron and how is loaded into that. Let me chat with on this to see if he has anything thoughts
I have a different problem. When I dumped my keychain, I have 123 entries in it so "not enough resources is probably not surprising. I wonder whether these accumulate over time and then the problem arises. Usually, I am asked to re-authenticate once a couple of weeks so it would take a while before they accumulate. I will remove them now so I can use my shit.
For my normal VSCode (which I stopped using since we last tacked this problem), i have the following targets: So probably this is how it looks "in the making". Should I clean that up as well or leave it for testing?
FWIW, I've worked around the problem by deleting all the credentials of the form: where "xxx" at the end is some random-looking decimal number. After restarting and reauthenticating, several subsequent restarts of VSCode did not require re-authentication and the number of credentials of the above form holds steady.
Yes, me too. I am guessing it will slowly grow as tokens expire. The library that gave does not have functionality to delete, so that is probably what is causing this.
I found the same thing; in my case it was a whole bunch of credentials placed there by Adobe Creative Cloud that were taking up all the space. Once I completely cleared out the Windows Credential Store, I was able to get both VS Code and Visual Studio to correctly connect to GitHub again. Get Outlook for iOS From: Vladislav Kosev Tuesday, July 12, 2022 10:37:40 AM To: microsoft/vscode Pierre Plourde Comment Re: [microsoft/vscode] error logging in 'writing login information to the keychain failed with error 'not enough memory resources are available to process this command' () Yes, me too. I am guessing it will slowly grow as tokens expire. The library that does not have functionality to delete, so that is probably what is causing this. — Reply to this email directly, view it on GitHub, or unsubscribe You are receiving this because you commented.Message ID:
That process for keychain setup worked for me, I got the result expected. So what does that mean for vscode? A bug? Every time I restart VSCode or even reload the window, I have to login again for CoPilot and Settings Sync - I use the Github login. Using MacOS Monterrey.
I had the same issue - too many credentials (Windows 11: Start Credential Manager Windows Credentials). Mine included an obscene number of vscode entries, as noted above, so I deleted them all with a powershell line I cobbled together through Google: . It still threw the error so I hand-pruned most of the remaining entries and it took. Good luck! (FWIW, Win 11, 8GB RAM + 24GB Page File) !
I think this one is more likely the cause. Because after I deleted all the credentials in the credential manager, it still automatically logs me out. There is no out of resource error for me. It may be the syncing issue leads to duplicated credential creation.
For the folks that have cleared the large list of credentials in their credential manager... can you please check to see if that number is increasing again? My suspicion is that some of you got into a bad state around the time that I was making heavy changes in this space... but now that that has settled, vscode's code isn't polluting the cred store anymore... This is coming from my lack of reproduction of the issue even though I've tried numerous ways to do it. With that said, users could still get into this bad state though, if they use other applications that use the keychain (like someone mentioned with Adobe products). For this case, we should at the very least include docs in the troubleshooting keychain issues here:
Hi Tyler, I have not had any failures along the lines of the original problem (needing to login each time vscode is started) since I cleared the credentials back in July. Today, I see only about 5 hits from the command you posted. And I think I saw about the same number when I checked at some point between July and now. I tend to agree with your suspicion.
"Target" is localized. Need to chcp 437 first. I now clear my credentials and will try to reproduce.
Thanks I'll update my regex
updated mine and I'm updating your quote so that no one gets confused
Based on confirmation, I will optimistically close this issue once the doc PR goes in... however, if you still see the problem of VS Code's credentials growing an unreasonable amount, please don't hesitate to reach out.
One other thing I tried is a minimal Electron repro where I created 1000 secrets to see if I could reproduce it... I could not. For those that wanna assist in getting to the true root of the problem, I've documented a potential repro here: If you can reproduce the error mentioned in this issue using my Gist, please let me know so we can let the Electron team know. In any case, I'll still close this once goes in.
I have confirmed that once there are too many credentials, the Windows call fails with . This issue doesn't have to do with Electron or Node.
Given this, the best we can do is document that workaround which is done now. Thanks for the investigation
Hi , may I ask how to list the credential? And what's the upper limit? I don't think my box have "too many credentials". But it still hit this issue. Thanks
, isn't it possible to remove the expired credentials automatically? It doesn't seem normal that you must delete credentials by yourself. There is not even a command that does it, you need excel/PowerShell to do it.
We're still blocked by the issue. May anyone please suggest a workaround? Thanks.
see to get the list of credentials.
Thanks, . This is my observation: ! I notice tons of credential created by VS code. To me, the bug seems: vs code incorrectly wrote tons of credentials to Windows, which causes the "not enough memory resources" issue. This is not a Windows issue but a vscode issue. Any thoughts? Thanks CC (, who seems the PM to me)
I think that the working assumption is that there was a temporary problem in VS code that generated the entries in the Credential Manager. See the explanation in this in this same issue thread. You might try deleting those entries in your Credential Manager and make sure you have the latest revision of VS Code. I did exactly that back in July and it worked. I see that at least some of your entries are in or before that timeframe.
Thanks. . I ran Then the issue is gone. I disagree with this statement: I have confirmed that once there are too many credentials, the Windows call CredWrite fails with ERRORNOTENOUGHMEMORY. This issue doesn't have to do with Electron or Node. Again, to me, the bug seems: vs code incorrectly wrote tons of credentials to Windows, which causes the "not enough memory resources" issue. This is not a Windows issue but a vscode issue.
It's a Windows issue because it could be caused by other programs too. See Adding a command to clear credentials sounds like a separate feature request to me. Edit: Actually, if a bunch of credentials are still being incorrectly written even with VS Code version 1.71, that's a VS Code bug.
Hi , are you saying it's by design that VS code creates tons of the credentials? IMO, once vscode creates ton of credentials, it's by design that Windows OS prompts OOM. I read, in different way: both adobe/vscode should not create tons of credentials. It's their bugs to create tons of credentials.
I cleared my credentials back in July and haven't seen any evidence that "VS code creates tons of credentials". Right now, I have 5 that refer to "" user IDs and I suspect that has to do with my Microsoft account history. Tyler said that was a long story and has to do with legacy/older systems. I think I tried to explain before that Tyler suspected that there was some bad code in one of the releases of VS Code that caused the creation of these credentials. This would have probably been in the timeframe of the first half of this year. But apparently, that problem is no longer in current builds of VS Code. So you may be right that it is a VS Code bug, but it appears to be one that is fixed, at least according to my observations.
Thanks, . I think the issue still exists. 2 days ago, I have deleted all extra vscode credential using, cmdkey /list ForEach-Object { /delete $_.Matches.Groups[1].Value } But today, login failed again. Then I observed that vscode creates a bunch of credential again, which does not sounds expected to me. ! , do you have any idea? Thanks
This is why I asked if anyone was seeing the large quantities of vscode secrets after clearing out their secrets. And why I used the phrase "optimistically close" . You've provided new information with that last message and you've confirmed that there's some scenario where this still happens. With that said can you please supply: if you're using a Microsoft account or work or school account (if multiple, tell me about all of them) how many windows of vscode you typically have open give me the full text of one of these keys (don't worry it's only public data)
Thanks if you're using a Microsoft account or work or school account (if multiple, tell me about all of them) -Only hotmail account. etc, how many windows of vscode you typically have open -3 instance. But I use a python script to open them give me the full text of one of these keys (don't worry it's only public data) -Where to find these text?
Hey just jumping on this as per the comment in . I have just performed the credential manager clean out as per the command line in and my multiple VSCode windows are now all signed in, and persist across Exit's and re-open. There were 178 entries for the specific pattern on my machine. Edit: With things now working, there are 22 entries. I will keep an eye on things, and will post back here later on. For initial context: Windows Account 5 windows open at all times; 4 are folders/workspaces, and 1 is general files and unsaved instances
I've started experiencing the issue that appears to be mentioned in (but has now been merged into this ticket), but it appears that VSCode is correctly(?) reading my credentials from Seahorse (on Ubuntu) but still asks me to sign in every time I want to start or join a Live Share session. I've tried clearing out all the relevant credentials from Seahorse, and that (as expected) asks me to reauthenticate with my Microsoft account, but then continues to ask me to sign in whenever I start a new session. From Output Microsoft Authentication, everything seems to look fine to me - it finds two(?) stored sessions and seems to refresh the token fine... :shrug: Details about VS Code and my OS: In addition: It's a Microsoft work account () Usually only one or two, depending on the project. However, Live Share appears to open one window initially (that I have to click 'sign in' on) then opens a separate window (which I also have to sign in on) From Seahorse, I assume it's this bit you need? If you need to know anything else, don't hesitate to ask :+1:
Just chiming in here. I just used the hint with deleting all the credentials for vscode. I had like 100+ of them. After that I signed in to settings sync using my Microsoft account. No more memory error on save. And after restarting vscode it signed me in automatically again.
I have the hardest time reproducing this issue... for those of you that do see it, can you do me a favor and: the Credential Manager open on the side what you normally do (open multiple windows, just use VS Code) to see if you can notice when the number of credentials increases and let me know if there's a particular action that causes it I'll continue to try reproducing this...
Thank for continuing to try. Current it seems to not happen anymore or it happens very infrequently. In credential manager I have: 1 github token 8 tokens - 4 from yesterday and 4 from 30.08.2022. Not sure why 4. 5 numbered from 0 to 3 + one keylist.
those "8 tokens" are in the form right? Can you share them here? And if you don't want to can you at least tell me what's different about them? My guess is just a guid at the end...
Yes, there they are. Interestingly enough They were 4 pairs Two of the pairs are modified today (so they are somehow active, because the date changed from yesterday). There they are (dates are in front)
Just a little context on the pairs... Cred Man on windows has a limit to the number of characters you can store so we chunk them. The are the 2nd part of the other one. can you tell me how many things you've logged into with your Microsoft account? Based on 2 items being updated on Nov 4, I am going to guess...2... LiveShare & Settings Sync maybe? The ones from Aug 30 are odd... around that time, I was not working heavily in credentials land so that leads me to believe that you saw the bug that other folks in this thread are mentioning... the slow slow climb in the number of secrets. It's unclear to me why that happened... I ask myself questions: Were these credentials being used before that date and one day they weren't read properly so new credentials were created? This is possible. The library we use can be a bit dicey... and Windows certainly isn't perfect. before the "sign in every time behavior". Do you recall having to randomly sign in to Microsoft every once in a while? If this is the case, I need a better clean up mechanism... if possible. Were these credentials created accidentally as a duplicate... like could a 2nd window of VS Code think it was responsible for storing the credential and thus it stored a duplicate secret which was then overwritten by the updating of the keylist. Worth double checking... I thought only one window handles the creation of secrets, but maybe I'm missing something. If this is the case, the keylist might be getting mangled with 2 instances of vscode writing to the same place Btw, all of the non-keylist ones can probably be deleted (I'm assuming the date modified on those are a while ago). Those are from the old structure of secrets where all secrets were stored in one (chunked) credential.
Yes, these two. It's not that this doesn't happen, but it is diffucult to remember so far back.
Hi folks it has been a bit... I wanted to let you all know that I made a change that I think will be helpful here. It's available in the VS Code Insiders Build: What I'm hoping you see is no more gradually increasing number of credentials in CredMan. Please give it a try and let me know how it goes. I know it may take days/weeks/months to fully verify that this change made a difference... but it'll be worth it!
Wish I found this issue earlier. I just counted 188 entries in my Credential Manager for . I've been seeing this problem for the last few weeks (months?), where vscode constantly signs me out of my settings sync. Finally looked into it this morning and found the, "Not enough memory resources" output message, which led me to this issue. I deleted all the authenticator tokens from CredMan, and it seems to have resolved the issue (for the last 24 hours, at least). I use VSCode Insiders full-time and update it on a near-daily basis. Some sort of toast message, triggered by the the "not enough memory" error, might be nice to alert the user to the issue and instruct them to clear out their ms-auth tokens.
Spoke too soon. After a few days of daily Insiders updates and whatnot, I've continually been prompted to sign into Microsoft to sync settings, and each time, I end up with a dozen or so new tokens into CredMan. They appear to just grow unbounded. Is that expected? Am I going to have to periodically run the command to clean these up? I assume I'll eventually hit the, "Not enough memory" error at some point if I just let the list continue to grow?
Thanks for the update. We'll be doing more drastic work in this space this month and next and my hope is that this will be resolved then.
I don't know if this is useful or not, but I've only seen a Microsoft Authentication problem when running multiple instances of VS Code. By this I mean: Start VS Code normally, do work... Open another instance with the "Workspaces: Duplicate As Workspace in New Window" command Do more work Shut down VS Code for the day with File-Exit, and not by closing each window individually with X in the upper right. Next day, start VS Code just by clicking the icon in my taskbar. Both instance windows show up in the same state I left them in the day before Work some more I haven't seen a problem for months because I WAS NOT doing the above workflow. When I opened another instance, I closed them separately, which means I only get one window on the next startup of VS Code. But I did do the above workflow last night and today and about 4-5 hours after starting it this morning the Microsoft authentication failed with messages: I have no idea what's causing this, but it seems that problems related to this happen more often with multiple instances running. There were a few people commenting on this issue that they were running multiple instances. I also don't know if this is happening because VS Code was started with 2 instances, like I did this morning, or if it is just sufficient to have more than one instance where the additional instances were started with that Duplicate command after the first instance was created. I tend to suspect the former because I never saw the problem when starting a VS Code session with just one initial instance. I saw it today after starting a session with 2 initial instances/windows. Again, I have no idea, but it feels like the two instances of VS Code are banging on the authenticator at the same time or are running some non-reentrant code at the same time on the way to the authenticator. HTH
I cleared out the credentials, but in less than a day I was back to more than 100 entries. The problem also started showing up on two machines that didn't have it, immediately after the latest update. (As in, 100+ credentials created starting in the minutes after VS Code restarted for the upgrade.) Notably, in light of the above comment, my setup does involve multiple restored windows - and the upgrade restart does restore them.
Thanks all. Sorry to hear this issue has not been fixed yet and sad that I've not been able to repro this. I will say that we have some plans in the works for dealing with secret storage in light of 's archival. More on that later.
I'm also running into this, my Windows Credential manager is full of lines like this: ! See and since yesterday it is full again, so I'd be happy to help debug this if you can point me to the right logging commands.
Not sure related or not, but the latest version would cause consuming high CPU, especially when VS Code thinks I need to re-log in my account.
Even after log-in, CPU usage would not restore. Need to close vscode all over
I think I have finally found the issue and have a PR out for this. Thank you all for your patience and providing good information. To help me, you can get the insider build here: My change will be in the insider build that will go out either Thursday or Friday.
So far so good, I installed the insider build, played with some different git repo folders, and I have only 2 entries in the Credential Manager: ! The second one seems to be fore github copilot.
My change hasn't gone in yet
I haven't seen this problem for about a week on Insiders build, after several attempts to remove all credentials manually or with script. Problem re-emerged few times, but works as expected after another run of the script. Hope update would fix it for everyone and it won't re-emerge again. P.S. I haven't use a lot of workspaces lately (as mentioned in PR), will try to get into bad state before update once again.
Looking at your fix, I might be more aggressive about deleting all the chunks even if one of those deletes fails, for example, could 2 vscode instances be trying to delete the same chunks at the same time? Do you know what the user scenario is that results in very large passwords that need chunking? That might help me test it better...
This isn't possible because deletes are now handled sequentially thanks to that PR. Microsoft Auth via Settings Sync. The limit in CredMan is a measly 2500 characters. A refresh token that gets stored in Cred Man is usually way larger than that. That refresh token also gets updated every reload of a window (every time Microsoft Auth extension is activated) hence the issue with multiple windows writing at the same time when a VS Code update happens.
Your suspected behavior written up in the PR definitely tracks with my usage patterns and observations. I'm looking forward to the fix! Should we clear out the hundreds of tokens inside CredMan ahead of your fix going live? Or will they get cleared/handled as part of your revised operations? Thanks!
you'll want to clear out CredMan.
I just updated to 1.76.1. Now multiple vscode windows cannot sign in sync. A sign-in of one window will kick off others'.
It's likely the same problem since this issue was addressed in 1.77 which is only in insiders and will be released in a few weeks.
I was able to reproduce on my PC with then before update and it "spammed" credentials. After cleaning up credentials, updating, cleaning up again - 12+ days without issues. I think I was asked once (it might been for GHPR extension), but there is definitely no "spam" in credentials so far. However, it took noticeable time to repro it in so hard to tell for sure
Thanks for your report This one...... will be hard to verify.... and I think what you did is as close to a proper verification as we will get. I will mark this as verified and we will see what the 1.77 stable release gives us in a couple weeks. If anyone sees this issue in 1.77-insiders until then, please don't hesitate to reach out.
This issue doesn't look the same as , but I'll wait for 1.77 and reopen my bug report if the issue is not fixed.
I have the exact same issue as and I agree that it doesn't appear the same as . I will also wait for the new fix and see if it fixes my problem.
Now I am asked regularly to choose account so sync my settings from and when the list appears the Microsoft account appears as "(signed in)". I cleared the stored authentications a week ago (before the 1.77 update).
Looks like folks still see this in 1.77 at least partially. I need a new issue because this one is just way to busy... so we'll keep going in
this is useful
Just want to report that on Windows, the keychain could get into a bad state due to this issue, after which even upgrading to the newer version of vscode doesn't help'. One would need to take the actions suggested in , as mentioned above, which solved the issue for me.
it is actually worse now. I am being asked to select the account to sync settings from repeatedly upon launching VS Code. The Microsoft accont I am using appears as "(Signed in)", so the token does not appear to be lost, just disacossiated. I can't see anything within the logs.
Is it worse or did your Windows credentials just get full? That happens to me from time-to-time and it's annoying. posted above provided a recipe for deleting all of the Windows credentials. This fixes it for a while, then I have to do it again.
folks, re-posting what I'm saying above:


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --With , changes in a diff editor: [![enter image description here][1]][1] With , changes in a diff editor: [![enter image description here][2]][2] With , changes in a normal (non-diff) editor: [![enter image description here][3]][3] How to ignore changes in leading/trailing whitespace in a non-diff editor as well? If such a setting doesn't exist, please consider adding one. [1]: [2]: [3]:
I've removed the label, because this issue is about the hard-coded value . If that line of code would be commented out, I think everything would work as desired (the quick diff would respect the setting).
Maybe I'm misunderstanding, but this doesn't seem to work? ! In case it isn't clear in the picture, I just whitespace
I reproduced as well.
Turns out this isn't true.
Sorry about that!
No worries, I know you were just hinting.
Verification: There's a new setting to control this.


<!-- 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.60.0 OS Version: MacOS 10.14.3 Steps to Reproduce: & paste into markdown file <kbd⌘</kbdand click the link .ext)
This is my first go at launching into the vscode code, but hopefully this information may be useful. Perhaps we could update the parsing of the URI schemes in general to strip out the angle brackets when editing markdown? See my findings below for why I'm suggesting this, but I'm also unsure of what problems and side effects doing that may cause. Main points of interest While the Command + Click doesn't follow the web link when you're a Markdown file, it does follow the link in the of the Markdown file. So I think markdown syntax is actually ok In debugging the project a little bit, I found that the link you try to follow that has angle brackets may be trying to or something similar (instead of open a web browser) In the function , I think the scheme of http(s) isn't recognized because of the < brackets in the link portion. See around line 18, where it tries to recognize the scheme, but doesn't recognize it when it tries calling In the file you can add a few new schemes, and then you're able to follow the link just fine. Though, this is probably not the final way the issue should be fixed


Issue Type: <bBug</bthe settings UI. for a setting (e.g. "inlay"). the settings tab to a new editor group. Note that the search you entered previously has been cleared. https://user- VS Code version: Code 1.60.0 (, 2021-09-01T10:54:53.442Z) OS version: Darwin x64 20.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (26)</summaryExtensionVersion ------ vscode-css-formatter1.0.1 vscode-nginx-conf0.1.3 reorder-lines-by-length1.0.2 docs-view0.0.9 pgformatter1.17.0 vscode-eslint2.1.25 gitlens11.6.0 vscode-diff1.4.2 shell-format7.1.0 go0.27.2 postgresql0.0.2 rainbow-csv1.9.1 render-crlf1.5.21 template-string-converter0.5.3 python2021.9. vscode-pylance2021.9.2 jupyter2021.8. jupyter-keymap1.0.0 debugger-for-chrome4.13.0 nbsp-vscode0.0.1 vscode-commons0.0.6 vscode-yaml0.22.0 final-newline0.3.2 vscode-hexdump1.8.1 change-case1.0.0 markdown-all-in-one3.4.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
A function called in is being called after the drop, which is correct. But, the function in the same file name isn't being called when the user does step 3 above. Another repro is to use the "move editor to X group" commands. Therefore, the fix doesn't have to do directly with dnd.


Testing !
The binary is indeed available in the server folder but the libc library it is linked with does not exist on the image.
Ripgrep should also build for rust target in to support alpine images so that it is uses the musl c library.
I can add that, thanks
Ripgrep couldn't build under that target. My understanding is… when building with musl, it uses jemalloc, jemalloc uses backgroundthreadsruntime_support, and that doesn’t support our target. If we can figure out how to un set that flag on jemalloc that might work around it but i don’t know what consequences that would have
from it is not sure whether the bug is in jemalloc config or cargo, but the immediate working solution is to build the crate with I will see if that works.
May I know if there is some workaround for this bug for users? If not, I do not think its good to ship Alpine ARM 64 builds with broken experience.
It will require users to install package that will include the required libraries for the executable built using glibc.
Not with your PR, right And thanks for the PR!
Yup is not needed with the musl binary produced from the PR.
I didn't put up a PR to adjust to download for alpine. Can you take care of it ? Thanks!


<!-- 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: Insiders OS Version: Ubuntu Steps to Reproduce: New machine Install VS Code insiders Open an existing notebook text/latext output is rendered by built-in renderer Install jupyter based on VSCodes recommendation Re-load VSCode text/latext output is still rendered by built-in renderer Note: This workflow is not going to work as we know of a lot of text/latext that doesnt' work with the built-in renderer, & novice users won't know that they need to change the renderer to Jupyter Notebook renderer. I've submitted a PR to remove the text/latex renderer from VS Code
I believe this is where we select the renderer (we currently always take the first one): I agree that automatically deprioitizing built-in renderers makes sense
Starting from a clean user-data-dir, I follow the steps, and it picks the built-in one by default. ! If I pick the extension renderer, it seems to remember that selection.
How do I get the latex mime types to show in that picker? I only see one: !
To verify: sure you have the jupyter extension installed and are in an ipynb notebook a normal python cell, run: the output is rendered nicely <img width="515" alt="Screen Shot 2021-11-01 at 9 20 35 AM" src="https://user-"


Issue Type: <bBug</bI have two files in my project in different locations. and . The 'search in files' popup always shows first, event when searching for the latter: ! please include case-sensitivity in the sort function for this. VS Code version: Code 1.60.2 (, 2021-09-22T12:00:31.514Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2 Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2 Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2 Remote OS version: Linux x64 5.10.16.3-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (5)</summaryExtensionVersion ------ jupyter-keymap1.0.0 remote-ssh0.65.8 remote-ssh-edit0.65.8 remote-wsl0.58.2 hexeditor1.8.2 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --


<!-- 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 a new color which can be used when we split an editor in group. The layout can be horizontal or vertical. Please support different border color settings for vertical and horizontal layouts. For example in the following vertical layout I don't need/want any border. It is easy to distinguish each editor. ! But it is hard to distinguish editors in horizontal layout without a border. !
Sounds reasonable, open for help for a meaningful small PR.
Verification: configure colors for the new theme colors and and verify they apply properly as advertised depending on the split in group layout


<!-- 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. --In Jupyter Notebooks, finding witrh regex works but replacing with capturing groups doesn't. I'd like if it does. I tried as in the usual editor, but the replacement treats as literal. I had to work around by copying the code section to the usual editor, and then find and replace. This seems like an inconsistent UX, and personally quite inconvinient.
Should I have opened this at ? If so, please close this so I can move on.
Thanks again for the help, it makes the find experience in notebook closer to the normal text editor one.
did you create a test plan item for this? I just the verification needed to it.


Pull out most xterm handling from into its own class that encapsulates addons, latest write/parse, _enableWebglRenderer/other renderer stuff, customkeyhandler?, etc. The goal is to make much smaller and enable easy unit testing of previously core behavior by not having so many service dependencies. Expose as public ITerminalInstance to avoid creating passthrough functions like scrollToTop Expose as public but only to TerminalInstance (ie. don't expose on XtermTerminal's interface) will be mostly a glue class (process manager <-xterm), not intended to be unit testable but by integration tests


There are too many issues with local echo and can really degrade the experience right now for local workspaces. We should add an on/off/auto setting where auto is disabled in local workspaces, so opt-in ssh in local terminal support is there.
what steps would we take to verify? Looks like there's a new setting?
I tested the setting


Issue Type: <bBug</bworkspace file Create the other folder. it in Visual Studio Code on Windows  New Terminal, select 'scripts' error: The terminal process failed to launch: Starting directory (cwd) "D:sourcesappscriptsD:sourcesappscripts" does not exist. VS Code version: Code - Insiders 1.62.0-insider (, 2021-10-29T05:16:23.014Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Can you share your file and also do a trace log while creating a terminal?
Thanks, I don't see any logs indicating an attempt was made to create a terminal. Can you pls try again and capture the logs associated with that?
should i wait before logs are written?
You should try to create the terminal (reproduce the bug) and then copy the logs which should contain information about the process
sorry, I missed important setting in repro. I've created reproducible sample. Unpack it and open workspace file. And then try to open any terminal Seems like error is not stored in logs. I see [2021-10-29 17:40:03.486] [renderer1] [trace] RequestService#request [2021-10-29 17:40:03.525] [renderer1] [trace] {"name":"EntryNotFound (FileSystemError)"} [2021-10-29 17:40:03.525] [renderer1] [trace] {"name":"EntryNotFound (FileSystemError)"} [2021-10-29 17:40:04.960] [renderer1] [trace] CommandService#executeCommand [2021-10-29 17:40:04.960] [renderer1] [trace] CommandService#executeCommand _workbench.pickWorkspaceFolder [2021-10-29 17:40:06.367] [renderer1] [trace] terminalInstance#ctor (instanceId: 1) {"cwd":{"{workspaceFolder}","scheme":"file"}} [2021-10-29 17:40:06.572] [renderer1] [debug] Terminal process exit (instanceId: 1) with code undefined [2021-10-29 17:40:06.572] [renderer1] [debug] Terminal process exit (instanceId: 1) state 2 [2021-10-29 17:40:06.572] [renderer1] [trace] terminalInstance#dispose (instanceId: 1)
I've updated bug description with missing part
I have reproduced a similar issue when setting
The issue seems to be caused by commit I have replied here
In the latest insider build this bug it still reproduced with the exact same steps. However folder is different. Before fix it concatenated it this way for folder "scripts" "D:sourcesappscriptsD:sourcesappscripts" After fix you can see the results below on screenshots: This is shown when I try to open 'scripts' folder (from steps in bug) ! This is shown when I try to open 'other' folder (from steps in bug) ! As I can see, concatenation of relative paths became broken. Should we reopen it?
good point, thanks for raising this. Didn't check the version info hard enough in your report
I want to add some words of appreciation of VS Code. I'm using it for 4 years already and incredibly happy about it. And thinking about lots of efforts in the background that you and other team members are putting to make this masterpiece editor, I feel envy that I'm not moving the entire world of development forward like you guys...


Does this issue occur when all extensions are disabled?: Yes As described in the title and the clip below will say the rest, the canvas seems overwhelmed with the output and doesn't wrap it. https://user- The log: Because the lower trimmed part are wrapped, it thinks it don't have to show the scrollbar so we can't view the rest if the line is long enough. This is critical. ! If we put some colors, we will see the lines overflow at the edge: ! Smaller outputs are fine: ! <details<summarySystem info</summaryVersion: 1.62.0-insider Commit: Date: 2021-10-29T07:49:33.336Z Electron: 13.5.1 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Linux x64 5.11.0-38-generic </detailsI haven't got a chance to test on other OSs. This is my test notebook:
this is just a bug, but could probably be considered as part of the discussion about
thanks for the feedback. What are your thoughts on the current behavior, where we supply a link at the top of the output that allows you to open the output in a separate editor tab? This behavior can indirectly essentially solve problems like this.
It's definitely a good design. The issue actually doesn't stop me from doing my job. My opinion is, as you said, it's just a bug - and I just want to let you know.
I'm taking this with the assumption you're not currently looking at it.


VS Code version: 1.63.0-insider Jupyter Extension version : v2021.10. Python Extension version : v2021.12.-dev OS : Windows 11 Python and/or Anaconda version: 3.9.7 Type of virtual environment used : N/A Jupyter server running: Local Render correctly the Markdown text using the default renderer: ! This is the correct rendering for this: ! a new Jupyter notebook a new cell code with the following Python: Ctrl-Enter to render cell Via "Choose Output Minetype", selecting the "non default" renderer (i.e. the one with "(vscode.markown-language-feature") for Markdown: ! Gives the expected result: ! Also, I could not find a setting allowing me to make the functioning "Output Mimetype" the default... Thanks!
The actual repro attached.
this might be another example of the wrong renderer being chosen.
I get the correct default renderer first time now. text/plain is the only other output option. !


<!-- 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. --Hello, great teacher! In the long-term use of vscode, I found that the number of method parameter overloads has a dark foreground color, and my eyes will be tired if I see it for a long time. I ask the teacher to allow us to modify the foreground color to our own suitable foreground color. It will be great for people who have been coding for a long time! Hope this problem can get your support and help from the teacher to improve it in the next milestone. Thank you very much! !
I would advise you to switch to light theme, is what I recommand. !
Thanks for your answer! But looking at the light theme for a long time will make the eyes more tired. These are one of the UI elements that are used very, very frequently. Improving it will be very friendly to most people. From the picture you provided, it can be seen that even in the light theme, it is also very dark, and it takes a very difficult time to recognize it.
If you want to improve the situation more perfect, it is recommended to add the following oval background color settings, which will be very beautiful and modern, and can bring people a very pleasant coding experience more in line with ergonomics. !
The contrast on the numbers needs to be increased. Here's the relevant css:
I would recommend these themes below : official dark pro is coming (dark black) Choose the one which is comfortable for you after trying with all the three hope i was helpful
Thank you for your reply! I tried these topics a long time ago and can't solve this problem.
Hello, teacher! Is it convenient to modify the style of this css?
Hello, teacher! This problem is really important to me, because my eyesight is not very good, so I hope you can accept it and help solve it in the next milestone. After solving this problem, I will no longer report UI-related problems in the future. I really hope you can help solve it, thank you very much for your hard work and efforts!
Hello, teacher! This problem is really important to me, because my eyesight is not very good, so I hope you can accept it and help solve it in the next milestone. After solving this problem, I will no longer report UI-related problems in the future. I really hope you can help solve it, thank you very much for your hard work and efforts!
you can just modify the css just like said. go to , then search for , find next to it, and change it to .
If possible you can switch to the Cobalt theme. I am using it from long time and it's too good.
thanks for your help! I tried the solution you gave, but a similar solution could not solve my problem.
Dear teacher! Can you solve this problem in the next milestone? If the teacher can solve it in the next milestone, the students really thank you very much! You can refer to the following style design: It is recommended to add the following oval background color settings, which will be very beautiful and modern, more ergonomic, and can bring a very pleasant coding experience. !
I edited this issue. I appreciate any feedback on the PR
Hello, teacher! The new year has come, I wish the teachers a happy new year! ! ! In the new year, I hope that the teacher can help solve this problem in time, thank you very much! To solve this problem, there are no other UI related problems to be solved later.
Hello, teacher! VSCode is a great project that gives users the greatest autonomy from the very beginning, allowing users to personalize configurations according to their own habits, so it can fully surpass the long-born jetbrion series in just 5 years. The most important reason is that VSCode's open source thinking and allowing users to customize and configure VSCode development methods to the greatest extent can achieve today's achievements. I hope VSCode can continue to develop this way of thinking and development, focusing on every reasonable request of users and need. Thank you here! vscode contributors
Hello, teacher! VSCode is a great project that gives users the greatest autonomy from the very beginning, allowing users to personalize configurations according to their own habits, so it can fully surpass the long-born jetbrion series in just 5 years. The most important reason is that VSCode's open source thinking and allowing users to customize and configure VSCode development methods to the greatest extent can achieve today's achievements. I hope VSCode can continue to develop this way of thinking and development, focusing on every reasonable request of users and need. Thank you here! vscode contributors
Thank you very much! teacher!
Hey! I also think that text should be more readable. I created a PR to fix that:


The current API does not expose the same level of internal granularity as the user setting allows. This proposal is to expose the telemetry levels. The current and can still be used a simpler API and this one can be considered more advanced and granular. Extension authors cannot just observe the user setting as this will lead to doing the wrong thing.
Another possibility is that we could collect an array of acceptable levels if we're worried about the possibility that the levels will not continue to be progressive but a permissions system instead. I.e. collecting errors and crashes would have be an array . None wouldn't really make sense in this context and would probably go away in favor of an empty array.
This is implemented but will remain in the proposed state for awhile for testing
Closing in favor of


Testing When browsing themes while offline, I didn't get any message that I could not connect to the marketplace and/or could not retrieve themes, with the only visible feedback being that the theme search would instantly return with an empty quickpick. It would be nice if this information could be surfaced somehow.
Verified: !


Are all these settings still "experimental"? This seems like a mature feature !
This is a good point. I believe the wording is used to indicate the functionality has some quirks. We will see if thinks it's fine to remove it.
Yep let's do it, I think we just didn't remember to remove


<!-- 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 (disabling Emmet) <!-- 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: - Ubuntu 21.10 Steps to Reproduce: a .js file which is denoted a React file by VSCode part of the coding implement state for a counter with the following simple line: getting as far as typing I wish to just exit the square brackets however Emmet takes the first position tab results in an HTML string appearing, see pictures Question: How do I move Emmet down the list of suggestions in Autocomplete for a React file, I am using other extensions like TabOut (to get out of the square brackets without any autocomplete) which would be more appropriate. ! ! ! !
This issue heavily affect the react users.
Verification steps: a JSX file. . should not be an Emmet suggestion.
/verified


Tracks shipping the TypeScript recovery build: 4.5.3:
Version: 1.63.0 Commit: Date: 2021-12-07T05:15:48.091Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 19.6.0 !
typescript log: !
this problem appeared after the last update, until friday everything was working fine
is there any temporary solution until fix will be shipped?
this problem to be related to libraries in my work, temporary solution until fix, is locked echarts version to
did someone was able to work around it? it is not working with the latest typescript as well... should we downgrade our vscode version?
Downgrading to 1.62 fixed it for me. You can get it from: Also disable automatic updates before downgrading, otherwise it will push you back to the faulty release.
Closing for verification.
thanks
I had the same issue. Thanks for the fix. :)
THANK YOU SO MUCH, this intellisense drive me crazy since last Friday!
Just tried 1.63.2 and it's still failing with the same message. I submitted a new issue with the stack trace. Contact me if you want more info Version: 1.63.2 Commit: Date: 2021-12-15T09:37:28.172Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.5.0 TypeError: Cannot read property 'flags' of undefined at getPropertyOfObjectType (/Applications/Visual Studio ) at getPropertyOfType (/Applications/Visual Studio ) at resolveESModuleSymbol (/Applications/Visual Studio ) at getTargetOfNamespaceImport (/Applications/Visual Studio ) at getTargetOfAliasDeclaration (/Applications/Visual Studio ) at resolveAlias (/Applications/Visual Studio ) at getSymbol (/Applications/Visual Studio ) at resolveNameHelper (/Applications/Visual Studio ) at resolveName (/Applications/Visual Studio ) at resolveEntityName (/Applications/Visual Studio ) at resolveEntityName (/Applications/Visual Studio ) at getSymbolOfPartOfRightHandSideOfImportEquals (/Applications/Visual Studio ) at getTargetOfImportEqualsDeclaration (/Applications/Visual Studio ) at getTargetOfAliasDeclaration (/Applications/Visual Studio ) at resolveAlias (/Applications/Visual Studio ) at resolveSymbol (/Applications/Visual Studio ) at mergeSymbol (/Applications/Visual Studio ) at /Applications/Visual Studio at Map.forEach (<anonymous) at mergeSymbolTable (/Applications/Visual Studio ) at mergeSymbol (/Applications/Visual Studio ) at /Applications/Visual Studio at Map.forEach (<anonymous) at mergeSymbolTable (/Applications/Visual Studio ) at mergeModuleAugmentation (/Applications/Visual Studio ) at initializeTypeChecker (/Applications/Visual Studio ) at Object.createTypeChecker (/Applications/Visual Studio ) at Object.getTypeChecker (/Applications/Visual Studio ) at synchronizeHostData (/Applications/Visual Studio ) at Object.getProgram (/Applications/Visual Studio ) at ConfiguredProject.Project.updateGraphWorker (/Applications/Visual Studio ) at ConfiguredProject.Project.updateGraph (/Applications/Visual Studio ) at ConfiguredProject.updateGraph (/Applications/Visual Studio ) at ProjectService.createLoadAndUpdateConfiguredProject (/Applications/Visual Studio ) at ProjectService.assignProjectToOpenedScriptInfo (/Applications/Visual Studio ) at /Applications/Visual Studio at Object.flatMap (/Applications/Visual Studio ) at ProjectService.applyChangesInOpenFiles (/Applications/Visual Studio ) at <computed(/Applications/Visual Studio ) at /Applications/Visual Studio at IOSession.Session.executeWithRequestId (/Applications/Visual Studio ) at IOSession.Session.executeCommand (/Applications/Visual Studio ) at IOSession.Session.onMessage (/Applications/Visual Studio ) at Interface.<anonymous(/Applications/Visual Studio ) at () at Interface.onLine () at Interface.normalWrite () at () at () at addChunk () at readableAddChunk () at () at Pipe.onStreamRead ()
I'm seeing the same thing on as well. Downgrading to worked for me as well. Version: 1.63.2 Commit: Date: 2021-12-15T09:37:28.172Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 <details</summary[2021-12-21 15:25:54.627] [exthost] [info] Extension host with pid started [2021-12-21 15:25:54.627] [exthost] [info] Skipping acquiring lock for Support/Code/User/workspaceStorage/. [2021-12-21 15:25:54.742] [exthost] [info] ExtensionService#doActivateExtension vscode.microsoft-authentication, startup: false, activationEvent: 'onAuthenticationRequest:microsoft' [2021-12-21 15:25:54.751] [exthost] [info] ExtensionService#doActivateExtension vscode.configuration-editing, startup: false, activationEvent: 'onLanguage:json' [2021-12-21 15:25:54.754] [exthost] [info] ExtensionService#doActivateExtension vscode.extension-editing, startup: false, activationEvent: 'onLanguage:json' [2021-12-21 15:25:54.759] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onLanguage:json' [2021-12-21 15:25:54.775] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onLanguage:json' [2021-12-21 15:25:54.782] [exthost] [info] ExtensionService#doActivateExtension vscode.typescript-language-features, startup: false, activationEvent: 'onLanguage:typescript' [2021-12-21 15:25:54.795] [exthost] [info] ExtensionService#doActivateExtension VisualStudioExptTeam.vscodeintellicode, startup: false, activationEvent: 'onLanguage:typescript' [2021-12-21 15:25:54.829] [exthost] [info] ExtensionService#doActivateExtension , startup: true, activationEvent: '' [2021-12-21 15:25:54.847] [exthost] [info] ExtensionService#doActivateExtension , startup: true, activationEvent: '', root cause: [2021-12-21 15:25:54.849] [exthost] [info] ExtensionService#doActivateExtension , startup: true, activationEvent: '' [2021-12-21 15:25:54.897] [exthost] [info] ExtensionService#doActivateExtension ms-vscode-, startup: true, activationEvent: '' [2021-12-21 15:25:55.232] [exthost] [info] ExtensionService#doActivateExtension , startup: true, activationEvent: '' [2021-12-21 15:25:55.246] [exthost] [info] ExtensionService#doActivateExtension , startup: true, activationEvent: '' [2021-12-21 15:25:55.479] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onAuthenticationRequest:github' [2021-12-21 15:25:55.548] [exthost] [info] Eager extensions activated [2021-12-21 15:25:56.091] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onStartupFinished' [2021-12-21 15:25:56.096] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onStartupFinished' [2021-12-21 15:25:56.098] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onStartupFinished' [2021-12-21 15:25:56.108] [exthost] [info] ExtensionService#doActivateExtension eamodio.gitlens, startup: false, activationEvent: 'onStartupFinished' [2021-12-21 15:53:52.346] [exthost] [info] extension host terminating: renderer closed the socket [2021-12-21 15:53:52.367] [exthost] [info] Extension host with pid exiting with code 0 [2021-12-21 15:53:55.138] [exthost] [info] Extension host with pid started [2021-12-21 15:53:55.138] [exthost] [info] Skipping acquiring lock for Support/Code/User/workspaceStorage/. [2021-12-21 15:53:55.198] [exthost] [info] ExtensionService#doActivateExtension vscode.microsoft-authentication, startup: false, activationEvent: 'onAuthenticationRequest:microsoft' [2021-12-21 15:53:55.204] [exthost] [info] ExtensionService#doActivateExtension vscode.configuration-editing, startup: false, activationEvent: 'onLanguage:json' [2021-12-21 15:53:55.209] [exthost] [info] ExtensionService#doActivateExtension vscode.extension-editing, startup: false, activationEvent: 'onLanguage:json' [2021-12-21 15:53:55.214] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onLanguage:json' [2021-12-21 15:53:55.229] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onLanguage:json' [2021-12-21 15:53:55.236] [exthost] [info] ExtensionService#doActivateExtension , startup: true, activationEvent: '' [2021-12-21 15:53:55.238] [exthost] [info] ExtensionService#doActivateExtension , startup: true, activationEvent: '', root cause: [2021-12-21 15:53:55.241] [exthost] [info] ExtensionService#doActivateExtension , startup: true, activationEvent: '' [2021-12-21 15:53:55.287] [exthost] [info] ExtensionService#doActivateExtension ms-vscode-, startup: true, activationEvent: '' [2021-12-21 15:53:55.334] [exthost] [info] ExtensionService#doActivateExtension , startup: true, activationEvent: '' [2021-12-21 15:53:55.352] [exthost] [info] ExtensionService#doActivateExtension , startup: true, activationEvent: '' [2021-12-21 15:53:55.431] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onAuthenticationRequest:github' [2021-12-21 15:53:55.598] [exthost] [info] Eager extensions activated [2021-12-21 15:53:55.601] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onStartupFinished' [2021-12-21 15:53:55.607] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onStartupFinished' [2021-12-21 15:53:55.608] [exthost] [info] ExtensionService#doActivateExtension , startup: false, activationEvent: 'onStartupFinished' [2021-12-21 15:53:55.615] [exthost] [info] ExtensionService#doActivateExtension eamodio.gitlens, startup: false, activationEvent: 'onStartupFinished' [2021-12-21 15:53:55.958] [exthost] [info] ExtensionService#doActivateExtension vscode.typescript-language-features, startup: false, activationEvent: 'onLanguage:jsonc' [2021-12-21 15:53:56.730] [exthost] [info] ExtensionService#doActivateExtension VisualStudioExptTeam.vscodeintellicode, startup: false, activationEvent: 'onLanguage:typescript' [2021-12-21 15:58:22.661] [exthost] [error] [vscode.typescript-language-features] provider FAILED [2021-12-21 15:58:22.662] [exthost] [error] Error: Could not create TS service. Service state:{"type":0} at w.service (/Applications/Visual Studio ) at w.executeImpl (/Applications/Visual Studio ) at w.execute (/Applications/Visual Studio ) at u.ensureConfigurationOptions (/Applications/Visual Studio ) at u.ensureConfigurationForDocument (/Applications/Visual Studio ) at /Applications/Visual Studio at b.interruptGetErr (/Applications/Visual Studio ) at w.interruptGetErr (/Applications/Visual Studio ) at l.provideHover (/Applications/Visual Studio ) at o.provideHover (/Applications/Visual Studio ) at /Applications/Visual Studio at We.withAdapter (/Applications/Visual Studio ) at We.$provideHover (/Applications/Visual Studio ) at t.doInvokeHandler (/Applications/Visual Studio ) at t.invokeHandler (/Applications/Visual Studio ) at t.receiveRequest (/Applications/Visual Studio ) at t.receiveOneMessage (/Applications/Visual Studio ) at /Applications/Visual Studio at u.fire (/Applications/Visual Studio ) at r.fire (/Applications/Visual Studio ) at /Applications/Visual Studio at u.fire (/Applications/Visual Studio ) at r.fire (/Applications/Visual Studio ) at n.receiveMessage (/Applications/Visual Studio ) at /Applications/Visual Studio at u.fire (/Applications/Visual Studio ) at w.acceptChunk (/Applications/Visual Studio ) at /Applications/Visual Studio at Socket.T (/Applications/Visual Studio ) at () at addChunk () at readableAddChunk () at () at Pipe.onStreamRead () [2021-12-21 16:03:34.858] [exthost] [warning] TextEditor is closed/disposed </details
Same here for 1.63.2, downgraded until this is solved....
having the same issue here, how do you guys downgrade?
Same happened to me. Had to downgrade to 1.62 (October 2021 update) for it to work.
why is this issue closed? this is still not resolved...
For me, this can be fixed by in Version: 1.63.2 (Universal) Commit: Date: 2021-12-15T09:37:28.172Z (3 wks ago) Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin arm64 21.2.0
I was running node 12. Upgrading node versions also fixes this bug. Edit: Spoke too soon. I saw tool tip working for some locally defined types and thought it was working. It still can't resolve types outside the local file and pops up the crash warning after 5 minutes.
it works for 2 minutes every time i reopen vs code until it crashes again. can u provide what version of ts u have installed in your projects? because for me this solution didn't help. i also downgraded the vs code version and it work for like half an hour and then again the same error
Sure. I hope this can be helpful for you.
I think this is being fixed by While waiting for new vscode to have new typescript, installing ms- seems to help. (Got the hint on ).


I was trying to copying a new setting in the problems hover and it was extremely painful to do so: https://user-
This is editor hover and hence assigning to
FWIW this works fine for me on Windows.


Issue Type: <bBug</bI wanted to be able to copy the call stack through a keyboard shortcut so I created a binding for but found that it doesn't do anything. I tried different combinations of clauses and ensured that my keystroke was not being captured by something else but still no luck. Invoking the command directly in my extension like so also did not work and the thenable resolved to . The comment and post imply this should work outside of the callstack context so I've filed this as a bug as opposed to a feature request for a keyboard shortcut to copy the call stack. VS Code version: Code 1.63.2 (Universal) (, 2021-12-15T09:37:28.172Z) OS version: Darwin x64 21.2.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ vscode-bazel0.5.0 arm1.5.2 vscode-diff1.4.2 fig0.10.1 misc-additions1.0.2 lldb-vscode0.1.0 jupyter2021.11. remote-ssh0.68.0 remote-ssh-edit0.68.0 vscode-remote-extensionpack0.21.0 cpptools1.7.1 errorlens3.4.1 vim1.21.10 clang-format1.9.0 material-theme3.13.6 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
The comment in code applies to the commands in general but that particular command can't be called globally currently. It copies a callstack from one thread and there can be multiple callstacks available so one has to selected to copy. Do you want the keybinding to work on the focused thread, or does that not help?
Yes, defaulting to the focused thread was my expectation.


We should not sync this Should this be per terminal instance? No We should persist similar to recent commands as well Should persisted entries work across different shells? Probably We should invalidate entries similar to commands Let's support removing entries, using a icon that shows only on active and hovered item Let's not use the x for failed, we can improve visualizing errors later on


Testing !
We'll need to repro on mac and look at the sequences to verify whether this is an issue or we're going the right thing.
I think this is working as designed since it's just padding on the top, however we could check the location of the terminal view and if it's on either side, top align the terminal instead of bottom aligning it.


Testing have no terminals, no panel visible reload vs code :bug: the open detected link, open last link commands are in command palette


I have a profile for PowerShell using the and once I enable the the prompt is no longer loading. With it enabled I see this prompt: ! When I disable I get my expected prompt: ! My prompt function within my PowerShell profile:
this is happening because line is throwing because there is no history in a newly created session
champion , should be able to handle this early next week
i could do a pr
also, here you should use and check if the CWD is a filesystem path. like:
that would be awesome! I'm fairly new to pwsh so any comments on the rest of the script would be appreciated too
Under what cases would the file system not be available?
the provider could be something other than filesystem, like the registry, certificate or environment you can see them if you run
just tried , neat
We probably want to keep the CWD even on non-filesystem providers actually, just give it a different scheme or something in that case to let VS Code differentiate it from a regular path. That way we would still get the cwd folder showing up in the tab: !
also, is it only supposed to support powershell 7 and not win PS?
Yep, no windows powershell
does vscode also supports osc 9;9 for CWD Tracking like win term?
some discussion on the topic in , my plan is to move us over to using our own custom sequences to avoid shell integration getting confused and give us freedom to change what them as we please.
let me know if I'm missing something though, I don't think running another terminal's shell integration script is particularly useful. Instead, you would use the arg injection or set it up manually (docs aren't written yet).
I see you have the sequences we support in your profile, these would break when we action as we'd probably move to use
yeah, I will probably remove them after the chages in and get into a release
Good to hear, let us know if you hit any other problems as I have a pretty simple pwsh setup
Can confirm latest build resolves this now on Inisiders: !


I am doing Remote Development, and have a few Source Control Repositories. In the Source Control pane, I have all the repositories listed in the Source Control section. One of the repositories has a file that I want to discard. It is listed under "Untracked Changes", under the repository it is in. If I click the "Discard Changes" button on the line with the file, I am prompted for confirmation, as I expect. But, if I click the same button on the line above the file -- the "Discard All Untracked Changes" button on the "Untracked Changes" header line under the repository I want -- then I am first shown a "Choose a repository" dropdown that lists all the repositories. I don't understand why this choice is needed, since I clicked the "Discard All Untracked Changes" button on the Untracked Changes for a specific repository -- why must I select this repository again? If I choose the repository, I am still shown the same (or similar) confirmation dialog as I was before, so the selection does not seem to be needed for confirmation. Clicking the plus ("+") button (i.e., Stage All Untracked Changes) on the Untracked Changes line seems to have the same issue.
Thank you!


Issue Type: <bBug</bWhile doing some experimentation with Bootstrap and the corresponding scss files, I encountered an issue while changing hexcolor codes. I was able to reproduce it on a different Windows machine (Windows 11 in that case) as well as on macOS (Monterey). Steps to reproduce: Open a large scss file. In my case, I used from the Bootstrap framework. Start changing a color by typing a different hex value. The issue only happened when changing at least two of the six digits and sometimes only after making a couple of changes. It did not happen when using the color picker. will become unresponsive eventually. For example the color pickers do not show up anymore, saving a file takes multiple seconds and the git integration stops working entirely. When the builtin SCSS extension is disabled, everything works fine. Therefore I would assume that this extension is causing the issue. VS Code version: Code 1.63.2 (, 2021-12-15T09:40:02.816Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I can reproduce open a scss file with on the end of line 15, add a character . Note that diagnostics appear, Remove the character, diagnostics disappear (all good) on the end of line 15, add a character . Nothing happens. Hover over a symbol, hover computes forever: Extension host is blocked remove the letter, reload the window disable the emmet extension repeat the steps, now all is working When profiling, the emmet extension is busy in The bug got introduced in 1.53
There are 3 conditions that must be met to trigger this issue: must return one of , , , , or (so that in returns true). File must be longer than 1000 lines (so that is called as noted above). The first must begin with The culprit is from When trying to skip over blocks, this function attempts to peak back 1 character when it encounters to check for a (1)()` is then called to move the position back to where it was at the start of the function, but in this case moves it back to position 1:2. This causes the loop that calls to loop infinitely, as the exit condition (position being to , in this case the start of the file) never occurs. Pull Request Resolves this by checking if the character being "peaked" at is a and breaking out of before is called. An alternative solution would be to not call if is within 3 characters of (as there is not enough space remaining to contain .
Thanks for the explanation I'll comment on the PR.


Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-11T05:19:13.554Z Electron: 16.0.8 Chromium: 96.0.4664.110 16.9.1 V8: 9.6.180.21-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: an extension (such as the C/C++ extension) that uses platform-specific VSIX's in the marketplace. a Remote WSL workspace. Install that extension into the remote. the extension UI for the instance installed remotely, try to select "Install Another Version..." or "Install Another Prerelease Version..." This results in an error: ! (There is a similar error in latest non-insider version, 1.64.2)
Can you please enable the log level to trace and provide following logs while performing this action? Log (Shared) Log (Window) Log (Remote)
When this repro's, I see the following in (with and is set to . I do not see any such setting as ) : is similar: was not logged to for this repro.
You can use following command to set log level to trace
Log (Shared): Log (Windows): Log (Remote Server): Log (Remote Extension Host): Please re-open. Please don't block waiting for me to provide information. This bug is extremely easy to reproduce.
Please re-open.
To verify: Open a remote window (make sure local and remote are on different Operating Systems) Install C++ extension Install another version of C++ extension (right click on the extension and you will see this action) Make sure another version is installed.


Testing Linux some commands in your terminal 1 Terminal Clear Command History 1 Terminal run recent commands the commands are still there, nothing got cleared !
This is by design as clearing history only clears the previous session commands. We don't discard the current session as they're all in the active terminal marked by decorations. It does however clear the active terminal's current session history from the previous session history (which hides by default as they would duplicate the content).
I find this very counterintuitive... As no other clear command in VS Code behaves that way.
I cleared recently opened and the active windows still show up, this is essentially the same thing the terminal history is doing: !
On macOS, i run , and when i run again, i can see all the commands, including those from the previous session. <img width="802" alt="Screen Shot 2022-02-24 at 11 07 24 AM" src="https://user-"
I agree that it's a little confusing. Perhaps we should say instead?
I now get the clear command history and a clear previous session command history command. Neither command seems to be clearing the command history. I'm on Windows with pwsh. !
the change you made was to the quickaccess code, this is nothing to do with the terminal so we need to revert that
can you help with verification steps for this one. Since I do not see the "Clear Command History" in quick pick. Does this only appear on Linux?
the title of the command is
thanks. After running that commend I still see the recent commands. So the command history is not cleared. Is this expected?
I still see previous session history commands given to the terminal after running the command.
is the group called or is it or something similar? Only the first is expected to be cleared. This worked fine for me just now.


Can we add some additional padding to the top of the TOC, to match the container on the right? !
Good idea. Assigning to March, though, because when I padding earlier, the end of the list got cut off, and I couldn't find a quick workaround.
This one's tough. A few attempts: Increasing the padding and doing nothing else results in the last entry being cut off. Increasing the padding and manually making the lists render at different heights results in the last entry showing, but the scrollbar not touching the bottom when the user scrolls to the bottom of the list. Creating a new element to stick above the scrollable list results in the shadow being pushed down. We want to keep the shadow at the top edge of the container. Adding a fake settings group with no settings to try and get the list to add a spacer element does nothing, because a settings group needs settings to show up in the ToC.
how did we get the padding to work before? Maybe we can ask the list widget to provide a padding param to adjust the height?
Before, we weren't using a splitview. The shadow was lower, and there was no sash. If we add padding elements above the splitview views right now, we will have the sash and the shadow intersect again in a + shape rather than a T shape.
Do you want the padding inside the list view, or outside of it? If you want it inside the listview, you can add it to an element and include this in the size returned from . If you just put css padding inside the list by itself, that will mess the list up
I would like the padding to be inside the listview. Adding the padding to the element results in a different focus border shape for that element.
What if you use a margin-top on the first element instead of padding?
I believe in this case, either the whole list gets pushed down and truncated at the end, or if I adjust the list height manually, the scrollbar fails to scroll all the way to the end when the list is also at the end. I also reopened an older version of Code and noticed that the list itself didn't actually have padding. There was padding above it, and the shadow was lower, as a result. !
I wouldn't mind it if the list had that top margin, I still think the line connecting to the user/workspace heading gives the impression that the top is also resizable (like editor grids) so staying away from that as much as possible would be preferred: <img width="855" alt="CleanShot 2022-03-14 at 14 03 38 src="https://user-"<img width="851" alt="CleanShot 2022-03-14 at 14 02 34 src="https://user-"
Verification steps: Settings editor should look closer to In other words, there should be a gap between the vertical splitview sash and the horizontal tabs/scope widget underline. one scrolls down on either side, horizontal shadows should appear below the horizontal underline.
Verified at described, not sure it looks better now than before though because the shadow no longer aligns with the horizontal bar above.


Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially


Testing We should consider increasing the line height for headers in order to provide spacing between lines. !
Possibly related: and
cc
It is also perhaps reasonable to suggest that the top margin is too large on the first header so you end up with more space at the top of the markdown block than at the bottom and it is not possible to balance if you want a header at the top. It might be worth considering some styles that remove the margin-top from headers when inside a ?


Issue Type: <bBug</bRunning tasks with dependencies in a multi-root workspace executes the wrong dependency tasks, if there are multiple tasks defined under the same label but in different root folders. VSCode will just pick the first occurance in the order of the root folders defined in the workspace settings. To reproduce the issue: a simple multi-root workspace, e.g. each root folder, add a with two tasks. One task depends on the other. Example tasks of : and have the same tasks configured except that they echo their respective folder name instead. task of either or . VS Code version: Code 1.65.1 (, 2022-03-08T02:06:27.846Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Experiencing same issue on: VS Code version: 1.65.1 OS version: macOS 12.2.1 BuildVersion:21D62
To verify: or create a multi root workspace with 2 roots, FolderOne and FolderTwo (or names of your choice). each of your roots add a .vscode folder. each of your .vscode folders add a file with the following contents: "PrimaryTask" in FolderOne (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderOne" next to it). Verify that both PrimaryTask and DependsTask echo FolderOne's path. "PrimaryTask" in Folder Two (command "Tasks: Run Task" and choose the task with the label "PrimaryTask" that says "FolderTwo" next to it). Verify that both PrimaryTask and DependsTask echo FolderTwo's path.


<!-- 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.65.0 OS Version: Windows 11 Enterprise Steps to Reproduce: a remote window, create an untitled file and paste these contents. ! this untitled file, a save prompt (modal) will appear. Click Save button. You will see something like this: ! suggested file name is $schema: and only azuremlschemas.azureedg is highlighted and not the whole file name which was suggested This works fine on a local window as the suggested file name is azuremlschemas.azureedg: as shown below: !
For untitled files, the first line is used as file name. I am not sure why there would be any difference between the simple and native dialog but I actually think the simple one behaves correctly here, though there seems to be mentioned highlighting issue.
I think our main concern is the highlight, for the name we would ideally like to have custom inputs from the extension but that is a completely different discussion.
All the simple file dialog knows is that there is a default save URI given to it. The highlight is done by using the basename of that default URI. I took a look at where the default save URI comes from, and it looks like suffers from the same issue of using the basename that simple file dialog does: The best fix seems to be to fix the default save URI. PR incoming.


This tracks the issue discovered in See for this discussion as well. We originally thought that issue had the same root causes as this one, but investigation revealed that was not the case
I've debugged this in an OSS build. It's a difficult consistently hitting the original issue from but I do some really odd behavior around view state being saved and restored Here's what I was doing: active PR view the views window back to active PR view once it is loaded After step 2, I see the following data being written for the views in : ! However when the state is then restored by , I see the following data being loaded (look at the sizes specifically): ! Will try to track down if some other code is writing this incorrect size data or if the reload is somehow restoring it incorrectly on reload
Adding and to see if you have any ideas about what's going on here. I've been debugging through the storage calls (at least on the renderer side) and we seem be writing the values as expected but on reload we still get back the incorrect values
Reopening this as I'm still seeing this issue on
After debugging further, here's what is happening: Basics: The GitHub PR view contains 3 views (from top to bottom): , , On reload with a PR, all 3 of these views start as visible. The PR extension then hides the view by updating a context key Bug: window view is created first After finishes, we have the sizes: we add After finishes, we have the sizes: we add The sizes are now now call for the various views (in a loop) Here however, we have very large saved view size for (1012) This means that when we do for the welcome view, the other two views to become quite small. In my testing after finishes here, the sizes of the three views are: then remove the view (I believe this is triggered by the PR extension changing the view's context key) causes the last view () to fill in the now empty space below it complete this time, the sizes of the two remaining views are: So in summary: the view has a very large saved view size (presumably from initial load) and this large size effects the sizes of the other two views even though the welcome view is immediately hidden However I don't know what the proper fix for this. Should we try saving off the fact that the welcome view has been conditionally hidden for example? Should we try saving a more accurate size for the welcome view? I think I've made about as much progress as I reasonable can in this space without any real understand of the view code. Can you please take this issue from here?
Thank you for looking into this and tracking it down .
Sure - thanks for update
To be clear, is this the bug we are planning to fix? (After refresh the bottom view is taking more space) https://user-
Yes, that's the one.
I can reproduce this behaviour with following sample extension <details<summaryExtension</summary</detailshttps://user- analysis is correct In the beginning first 2 views are visible and are sized equal. After 5 seconds, third view comes in and sizes are still distributed. After 2 seconds, third view is made hidden by setting the context. At this point, last view is removed and its space is allocated to the view (second view) before last view. First view takes 33% and Second view takes 67% of the total size. Instead the removed size shall be equally distributed to all visible views. Used DistributeSizing option while removing the pane and this seems to fix it. https://user- CC - I do not have much experience in using split views and do not know what are the side affects of using option. So please take a look and update/enhance the fix if needed.
Great analysis! the docs say: ! Which means: When using in , all other views will be resized to distribute the total splitview size. Without that option, the regular layout algorithm will happen... usually that means that only the adjacent view will stretch.
I am not sure if the following doc says the same or I am wrong: As per the doc, I was expecting that the removed view space is distributed equally across other views. But it is not and it is doing as you mentioned. This also explains why the views sizes are getting reset to equal sizes after a view is removed (when DistributeSizing option was used).
Thanks for calling that out! I'm improved the docs there.
Given that it is not doing what I am expecting - removed view space is distributed equally across other views. Is there an other option to achieve this?
Not today, no.
It means the above fix has the side affect that views sizes get reset when a view is removed - which I think is ok. CC
First off, thank you all for your investigations. however, I'm not sure this is a viable solution. Any time a view is removed this will resize all views which can feel quite wrong. See the gif below where we hide the outline view. The only other expanded view is quite small and becomes now half of my screen. The same can happen with drag and drop of views as well. !
I agree the new behaviour is not ideal but it is acceptable when compared to existing. Probably we can improvise it by not to distribute space when the view is collapsed? BTW I also observe the same in editor groups. https://user-
I've approved the PR. I think the change we have made is a band-aid that helps, but doesn't cut to the root of the problem. I thought through various view/hide scenarios and in each case, I had a different feeling about what I expected to happen with the sizing of the views. IMO, our previous behavior was more correct from the pane view side as an intentional "hide" operation on a view should not redistribute every view in the container. However, the problem here is that there is a problematic extra view that is not controlled by the user. In this case, we are just trying to get sane sizing. If we invest more time in this, I think the fix lives at a higher layer.


Currently says that the coverage folder is generated at the root of the directory. But this isn't currently the case, the coverage folder is generated under the directory instead.


Enable triggering go to definition on a markdown reference link to jump to the link definition Go to def should jump to the definition at the end of the file
Related
Created a PR fixing this
Works well, I was a bit confused to see this tooltip with 'Execute command' though, is there a way to make that more context-specific? !


<!-- Do Not Delete This! bugreporttemplate --Version: 1.66.0 (system setup) Commit: Date: 2022-03-30T05:50:14.623Z Electron: 17.2.0 Chromium: 98.0.4758.109 16.13.0 V8: 9.8.177.11-electron.0 OS: Windows_NT x64 10.0. New "striped" gutter decorations were in . These decorations do not respect the existing SCM: Diff Decorations Gutter Width setting: Changing the above setting has no effect on the new decorations.
I think this was an oversight and have a PR that can help address this. Thanks!