When running VS Code (or the Monaco editor) all theme colors are exposed as CSS variables. That means components don’t need to use JavaScript to read and set colors but can simply rely on CSS. When a theme changes, the variable values automatically update. Also, with CSS variables you have less code and everything in one place. The (long) list below is all users of . Those that only set/update colors are candidates for adopting CSS variables The names of the CSS variables can be "derived" with the following logic the theme color id and replace dots with slashes For instance the color id is exposed as CSS variables . Find a sample adoption in this commit: [ ] [ ] [x] [x] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x]
Hi, is this issue still up for grabs? I would like to be assigned to one of the bullets.
Yep! Just feel free to grab whichever one you want and open a PR for it :)
Hi! I would like to grab
Hi How did you linked your PR in every line of the description in this issue? I am not able to edit the description and I opened a PR for 12 hours ago. I guess edited the description to add your PR but not mine?
Maybe I mentioned this issue in the pr?
Yes, I was just wondering if there was an automated way of doing this, but I dont think so. Thank you!
I wrote a small helper that generates dynamic CSS rules but with the css variables filled in: You can use this for simple cases. Hopefully, it prevents some typos. The code is at:
Terminal is done, the following are intentional exceptions: We need to pull the color into TS to pass to as it uses it in canvas calls. We need to apply 0.5 opacity to the resolved color for the background, using won't work as it will fade the text.
Tunnel view, comments, and tree view are done.
what is the recommendation when more than the color is part of a ? To give an example: Here, we conditionally make an element if we have a . We cannot just blindly move that over to CSS because we then lose the check for the color.
I don't know. Has to stay in code....
can I listen to a change for a color key via theme service to conditionally toggle a class based on a color being defined or not?
Yes, and
If anyone else is still working on this, you can get completions with this handy extension
What is the recommendation if I have to hardcode a codicon css, for eg., I am deriving the codicon class programatically as follows If I have to move this to CSS then I have to hardcode the codicon class as follows Is it ok to hardcode codicons like this?
Looking at where verifiedPublisherThemeIcon is used, it's always in a dom node that also has the class . Better avoid the codicon class name, but use
Interesting issue where a migration to CSS variable caused a bug (). It looks like some visual behaviour is defined by the OS/runtime and not by default user agent CSS to fallback to. So if your CSS variable ends up as , you get some default (?) and the result is that the OS styling is disabled. Relevant SO for my case:
I looked over mine again and they are all there still intentionally: I don't think we can get the same effect of in CSS using the variable. Same as above. This is needed as the color is handed off to
please check those occurrences anyways so that we can remove them from the todo list
For , I couldn't find references to . For , we use the RGB values from the foreground var and we use a custom alpha. Since this only applies to the text, I don't think that there's a CSS-only equivalent. We could create a new var for this or just leave this as is; I'm not sure what's best in this case.
you're setting there so you can probably use a plain style, unless the element also has a background color as that would also apply there.
The element also has links, which have a normal alpha, so then the link opacity is affected.
you could have another rule with higher specificity that re-applies the link color?
For you could define a new (terminal hover specific) color. The default value of the color can express that it is a function of To access a color value use
As discussed in standup, tabs have quite an involved CSS ruling that involves not only colors but also other properties. I would like to keep it this way via and not invent various class names to get a similar effect to make maintenance easier there.
Closing this as I believe we are done here


We very likely do not need to ship all of this in the web bits: This was already once done before in , and when dependencies got renamed this was once again forgotten about.


+F to open the editor find widget. Focus should be on the find input box. case-sensitive search. to the case-sensitive search button. :bug: Keyboard focus is on that element, but it's not clear that keyboard focus is on that element. !
works fine on my machine with Light+ and Dark+ theme, what theme are you using? ! !
Thanks! I guess the problem depends on the theme. The problem seems to occur on at least Quiet Light, Solarized Light, and Monokai.
Can confirm the the issue in those themes on my windows machine. I never sent a pull request to vscode but that seems easy to solve, the question is what highlight color would fit best each theme, i might take a look later unless there are some rules about how to set some of the theme colors... the colors effecting this seem to be "focusBorder" and "inputOption.activeBorder" I would love to offer some new colors later today/tomorrow and pull request them
I propose giving a bit of contrast to the "focusBorder" I think that focus border should have a bit of contrast from background as this is marking elements the user needs to spot quickly, even in themes with less contrast light quiet light i think this is best to increase contrast in those areas, this is only showing for elements put in focus and wont change the feeling of the theme by much. Here are the new colors i propose and will commit and pull request later if those look acceptable For Quiet Light: ! For Solarized Light: ! For Monokai: !


open vscode for web on macOS ctrl+click into a tab that is not active context menu opens but also the tab opens fyi this is similar to and requires the same fix. Interestingly on Electron this does not seem to be an issue, maybe produces context menu event in Electron but not in Web?


When rendering Markdown preview, Unicode newline characters U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR are replaced with an empty string at the source preprocessing stage. This behavior was introduced in to but it breaks the document in multiple ways: double-click word selection does not work as expected, screen readers may announce the text incorrectly, line wrapping and hyphenation does not work correctly, markdown-it plugins that rely on or may work incorrectly, even linkify fails: and so on. Since then it was fixed at the markdown-it side, and is no longer needed: It would be better to revert this change, and keep the Markdown source as is before feeding it to the parser. Steps to reproduce: a Markdown document like this: preview: Expected result: LS and PS are displayed as is, links end at Unicode newlines. Actual result: no Unicode newline characters displayed, links also consume the immediately following word. <!-- 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: OS Version: WindowsNT x64 10.0.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!


Does this issue occur when all extensions are disabled?: No VS Code Version: 1.73.1 OS Version: Windows_NT x64 10.0. Steps to Reproduce: ! to the extension bar. to hover some items. Some one may not show the default scroll bar, but the problem is exists. ! I have tried to fix it. It seems caused by the visual bug from the issue . The scroll bar will show when the content is too long. This solution is great, but it causes another little bug in the screenshot. I think it's unwise to remove the tag, so I tried another way, just add to the tag : ! I'll make a PR after this issue has submitted.
I can't reproduce this srollbar for all extensions in the list: !
This bug is not 100% recurring. Some extensions' descriptions may just exceed the calculated.
What's ur testing extension id?
These extensions have the problem on my machine.
! !
Maybe it's related to high-resolution screen. I'm sure it's an accidental problem, but it still exists. If you have the conditions, try adjusting the screen resolution scale to 150%.
there should be some bugs when doing sub pixel sampling whether it's related to windows DPI settings. can you reproduce this regularly without changing DPI?
Caused by can you please have a look at this?


Ref Right now I see: as a menu entry and command name "Get Started" as the tab name when looking at the welcome page "Show welcome page on startup" and "Reset welcome page walkthrough progress" "Getting Started with VS Code" as a walkthrough name There's a mix of "Welcome" and "Get Started" usage that makes it hard to differentiate between concepts. We could either revert back to "Welcome" for the welcome page itself or rename it to differentiate from the first walkthrough. Thoughts <img width="424" alt="CleanShot 2022-11-21 at 10 19 04 src="https://user-"<img width="200" alt="CleanShot 2022-11-21 at 10 19 12 src="https://user-"<img width="516" alt="CleanShot 2022-11-21 at 10 19 20 src="https://user-"<img width="273" alt="CleanShot 2022-11-21 at 10 19 23 src="https://user-"<img width="625" alt="CleanShot 2022-11-21 at 10 19 56 src="https://user-"
for historical context on naming here
Yeap..I believe changing the label in the tab to "Welcome" instead of "Get Started" is a good option - It should say Welcome on the tab here instead of Getting Started: ! When the user navigates away from the welcome page, the tab name should change to the walkthrough's name: It should say Learn the Fundamentals on the tab here instead of Getting Started: ! And this breadcrumb should say Welcome: !
"Welcome" was the old page and we "Get Started" as new name during development. "Get Started" did fit better for the walkthrough style, was a more action-style verb and used in many other apps. Not sure if more thoughts went into it, as the mockups that started in were before my time and already used "Get Started". I haven't many users ever get into Get Started or Welcome as command, so renaming would be low risk.
Is there a user issue mentioning the confusion? Asking to understand if we also need to account for user keyword search behavior in the command pallet when looking for walkthroughs or the Getting Started page after its been closed. Currently, most walkthroughs use the "Get Started" terminology - Searching for "Get..." in the command palette surfaces the walkthroughs. I wonder if search terms are influenced by the page on which users first saw the walkthroughs and will the naming change have implications on the keywords to find walkthroughs?
No specific issue that I know of, I'm just spotting the issue of the strange overloading myself. might know if we have any hard data on people searching for the command. But I'd also assume it's quite unlikely compared to going to the "Help" menu, for example.


I suspect this comes from
You're right, this is: Right now, the module assumes that it will be called in the following order: It is possible that if a is skipped by the browser that we don't mark and that would cause an error at
Good morning I'm having trouble logging into the app. I get the following error. Uncaught SyntaxError: Failed to execute 'measure' on 'Performance': The mark '<REDACTED: user-file-path' does not exist. I hope you can help me with the solution. thank you.


I've seen this a lot over the past month and it seems like a major issue for notebooks, please consider investigating further for November ! ! ! ! While running integration tests today (23rd November): ! Version: 1.74.0-insider (user setup) Commit: Date: 2022-11-23T05:25:25.108Z Electron: 19.1.3 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
it's likely related to the position performance optimization this month.
Can you try debugging. I can never reproduce this The best place to start debugging is: Let me know if you want to pair on this later this afternoon too
Was finally able to repo this but not reliably. It seems to rely on a new being created, but this doesn't always happen. The most reliable repo for me: with a notebook and text editor in a single editor group the notebook editor down to create a new group below the text editor grab the notebook editor and drag it right to move the bottom editor to the right I think the root cause is that the notebook widget is passed the wrong position. I'm going to work around this by making the notebook editor ignore the position it is given, however this will also undo the performance fixes we made this iteration for notebook layout I don't fully understand the grid layout code but it seems that is being set incorrectly in cases where a new BranchNode/SplitView is created. Here's what I see happening after step 3 of the repo above: setter is called calls which creates a new the constructor, a new Split View is created is called on it. At this point, of the split view is: the time layout is called on the notebook editor widget, is computed as zero. This results in the wrong layout. Looking at the code, we can see that is passed in as the absolute offset in step 4: <img width="1104" alt="Screenshot 2022-11-30 at 12 48 54 PM" src="https://user-"If I then slightly resize the window, here's what happens: call on the split View for the new group now is: we layout the notebook editor, is now correctly computed as
Created new issue: , thanks for the steps


Very often I loose the yellow markers in the editor for references, see here for example: ! Here I find references of  and quickly dismiss the results of the one file before clicking on the other. Both files were opened before.
Didn't reproduce for me. Please update with repro steps
steps be in a multi root workspace with and close all editors open click on  of (at the end of the file) run (I have it bound to command) expand by clicking it once in the references view click the first result remove the 2 references by clicking on the X starting from the first click on the last result from no more highlights in the editor at all Full video: !
When removing the -entry (all together or all by removing all its children) I am not (always) getting the selection change event.
anything special for reproing this? I haven't been able to hit it.
Selection change event should be fixed now.
Thanks
fyi noticing a few behavioural differences now, which maybe we tolerate but users might not: clicking on a file name now opens the first reference, previously I believe it was not navigating but just expanding/collapsing (see video 1) triggering find references seems to reveal a reference in another file in some cases (see video 2) ! !


A bug in our tracker for dirty models, somehow never reported but obvious in an issue I noticed with Copilot. The end result is that you see a dirty indicator e.g. in the explorer but no editor that is opening and associated with it. Steps:
Tried to look at the steps to repro but seems the link to the copilot issue is broken or at least I am not able to access it.
I'm still getting this with copilot nightly in insiders <img width="652" alt="image" src="https://user-"
Please note that my change does not fix the Copilot issue. The steps to verify are unclear: it is expected when you see an untitled editor opening. You must test with auto save on.
Setting back verified label based on the screenshot.


Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-


Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders


a change to the file and save, do not commit the diff view from the SCM view up and down in the notebook diff view :cheese: see cell metadata area skittering on screen (the recording below does not capture how frequently the skittering actually happens) https://user-
Just ran into this again: https://user-
I opened for that, I think we can actually just reopen this one
This issue should be gone now since we fixed the horizontal bar issue.


re The automatic perf monitoring has shown a high number of calls to . This means the call/function itself is slow or it is called at a very high rate (so that the profiler always sees it running) The most common stacktrace via which this is reported comes through .
/duplicate
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I don't think this is a dupe because the callstack comes in via which I don't see in the other trace
But I think the root cause is same for both that is slow as mentioned in the summary of the other issue. Hence I marked it as duplicate.
Pfff - that would mean it is catastrophically slow. My suspicion is that it is just slow but that comes in combination with being over eagerly called? Maybe some event leakage or some over eager calling through some other means. This symptom might disappear when has become fast but I think we need to understand why it ends up on a hot code path in the first place
Will investigate why this is being eagerly called too.


I think these used to be blue: <img width="297" alt="image" src="https://user-"vs <img width="193" alt="image" src="https://user-"
Using the "Default Light+" theme this is working (on main). So it is either already fixed ( or theme dependency (unlikely) but what theme is this? <img width="1004" alt="Screenshot 2022-12-21 at 17 59 20" src="https://user-"
Ran into the same issue with my theme. After a recent vscode update the coloring of the icons is gone. I'm using the theme.
I also cannot reproduce from source, but it still reproduces in latest Insiders using :
Today's insiders also doesn't have colors for me, so this might be a packaging issue or something specific to my setup. Are you able to reproduce with Insiders? <img width="661" alt="image" src="https://user-"
Yeah, I can repro in insiders with an empty profile
This also happens in other places that show symbol icons and is only happening because of how things are ordered in the packaged CSS. what's the procedure to fix this? <img width="1250" alt="Screenshot 2022-12-22 at 17 32 26" src="https://user-"
While the CSS rules in a single file will remain in order when being loaded or packaged, there are unfortunately no guarantees to the CSS rules order of multiple files. That is because CSS files can't express dependencies on other CSS files, so they will be loaded or packaged in any order. The exact order depends on the internals of the AMD loader/bundler, but it isn't guaranteed to be consistent, as it can depend on fs read times, etc. I think it is a coincidence that this works every time when running from source. The correct way to fix this is to use to ensure the desired rule wins regardless of the css file order. I speculate that this only worked before (when CSS was generated from JS) because the dynamic CSS was injected in a tag towards the bottom of the element.


Type: <bBug</bAt some point recently the "view" -"testing" menu stopped opening the testing view. The menu item is present but clicking it has no observable effect. Additionally, the option is no longer available in the activity bar on the left. Note that it's not simply hidden. It's also missing from the context menu to show / hide items as well. This was working up until a few days ago. What does work is the command pallette. I can see from the logs that the extension is loaded, and by typing "testing" into the command pallette, I can still open the view, and from there on it functions normally. VS Code version: Code 1.74.2 (Universal) (, 2022-12-20T10:26:09.430Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (46)</summaryExtensionVersion ------ better-comments3.0.2 aws-toolkit-vscode1.60.0 better-tests0.3.1 atlascode2.10.12 emmet-jss1.0.0 path-intellisense2.8.4 dart-code3.56.0 flutter3.56.0 vscode-markdownlint0.48.1 vscode-eslint2.2.6 githistory0.6.19 xml2.5.1 gitlens13.2.0 prettier-vscode9.10.3 vscode-pull-request-github0.56.0 go0.37.0 rest-client0.25.1 git-graph1.30.0 dotenv1.0.1 djlint2022.10.1 vscode-docker1.23.3 isort2022.8.0 python2022.20.1 vscode-pylance2022.12.20 jupyter2022.11. jupyter-keymap1.0.0 jupyter-renderers1.0.12 vscode-jupyter-cell-tags0.1.6 vscode-jupyter-slideshow0.1.5 remote-containers0.266.1 cmake-tools1.12.27 cpptools1.13.8 cpptools-extension-pack1.3.0 vsliveshare1.0.5788 awesome-flutter-snippets4.0.1 printcode3.0.0 material-icon-theme4.23.0 gotestexplorer0.1.13 vscode-yaml1.10.1 LiveServer5.7.9 pdf1.2.2 cmake0.0.17 alphabetical-sorter2.0.1 vscode-maven0.40.2 JavaScriptSnippets1.8.0 markdown-all-in-one3.5.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Which extension is providing this? Maybe it isn't activating successfully. The Extension Host channel of the Output tab may reveal something.
Technically, this isn't an extension. It's the built in testing support. I think it's this feature:
/gifPlease
Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, files are preferred as they are displayed inline on GitHub. You may find helpful as a browser-based gif recording tool. If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording ( in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue. Happy coding!
Hi, I'm helping Iris look into the issue. Here's a video of what we're seeing. "testing" should show in the activity bar and in the context menu at the start of the recording but isn't listed. But the functionality that it should point at is still accessible via the command pallet, shown later in the video. !
That is because you moved the Testing view into the secondary sidebar. It therefore does not appear in the context menu on the primary sidebar. You can reset its location by dragging the beaker icon back into the primary sidebar, or using the command.
fyi if we want to make view location stuff more clear here
there seems to be a bug still with the Testing main menu entry. It should open the view wherever it is. Repro: testing container to secondary side bar secondary side bar View Testing =no response
Oh, right, I was just going off the last screencap. That's strange, but should be fixable...


start the GH auth flow from window1 focus window2. This step is not necessary if you use multiple screens and the browser is on the same screen as window2. But because I couldn't easily record both screens I manually focus here. continue the GH auth flow in the browser the flow returns to window2 instead of the originating window I grabbed the URL and it has a windowId in it: But perhaps the windowId gets lost somewhere along the way or perhaps there is a bug on the main process. Anyways, here is the recording: https://user-
Alex and I talked about this and based on what I'm seeing, I don't think it's an auth issue and seems to be a Uri Handler issue. If it was an auth bug, I would expect the to be missing from the URL but that doesn't seem to be the case here.
logging revealed something that I then was able to verify in code: the change in changed the kind. When previously a was passed, now it is a . So the code here needs to be adjusted: I think the code could get some type love and not use for that matter. The full value I get logging in the router is:
Hm, I am actually not a 100% sure if that commit caused the regression because I also see you changed the receiving end, but the problem is still the of and being passed in when previously it was just the
Great catch, that's exactly right! I did not adopt the serialization format in the router. I'm open to suggestions, though I'm not sure there is anything that can be done here. The whole point of these implementations is to (de)serialize live objects into opaque JSON things. You can add a bunch of interfaces that lock things in, but in the end we still need the generic and methods, so I'm not sure we'd gain anything.
Basically what  does by avoiding having to code out the underlying raw methods of the IPC flow and have just a typed interface for both sender and receiver. Yes, in the end you cannot know for sure what data is sent because we cannot enforce it, but (or something similar) at least allows to only have 1 place for types and when changing something, it would show an error on both ends.
How would you adopt that in the router?
So I've never been able to repro this bug... are there some steps that really focus on this fix?


Yesterday I ran VS Code Insiders from the Downloads folder, and I used . And today, after updating to latest Insiders I had to log in again. Here's what I noticed in one of the logs: I often also use which downloads various versions of VS Code Insiders and uses a custom user data dir. Often I end up being signed out . cc
I have seen this error before and I had a time when I had to log in all the time, but not for a while anymore.
Now again I hit this almost daily that I have to re-login.
After 1on1, learned that this is caused simply by launching VS Code from a different path. A suggested fix is to not destroy existing credentials on startup when we fail to decrypt but only do so when we actually need to write new credentials to the store.
What are some verif steps? I'm a little confused on what you mean by "launching VS Code from a different path".
verification: Launch VS Code insiders, make sure you're logged in to something Close VS Code Insiders Open a terminal (not in VS Code Insiders) and run (This will spin up old insiders builds): Note that you are not logged in to anything (expected) in the terminal say or doesn't matter Now once is done open your VS Code Insiders You should still be logged in to your stuff


<!-- 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.74.2 OS Version: macOS 12.6.2 Steps to Reproduce: an extension and specify a relative path to an in the in png format, and specify repository as . (Our repository is private) get a warning , despite the icon showing correctly in the marketplace and the VS Code extension manager (We also have images in our that we hosted externally. Our repository is private after all). Extension:
I get the same warning ! despite my fields being defined as Source: Interestingly the icon shows up in the marketplace just fine. !
I see the icon is served from the CDN now and we can remove the warning about the relative icon path. What about badges in the and images in the README markdown, are these also served from CDN?
Those are all served from the raw GitHub routes, this is why vsce needs to know what repository hosts the sources.
But the icon isn't, not anymore at least... Our repo is private, the icon works just fine and is uploaded along with the vsix and hosted in some CDN. Images in the readme are indeed served directly so will require this check or an absolute URLs.
Ah! This is just the workbench linter. I also forgot that we actually show the icons served directly from the MP, not GH. Sorry about the confusion, thanks for following up This warning is unnecessary by now, let's remove it.


This looks like we have telemetry loggers without appenders. Can we add a strict check or in the API impl?


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When I use command in VSCode to disable the extension of the current folder/workspace it doesn't work. Other attempts: also invalid when adding options. Expected Result: Disable the specified extension. !
To extend it a little bit: These commands do work, when the workspace/folder is not yet open! (with disabled extensions) Even we did not found any documentation about it...
Right, this works only when the window is not opened. I do not think we send the CLI args to the opened window. Also this option is to disable the extension for the current session only. This will be reset when user restarts VS Code without this option. I will update the help doc.
Thank you for your reply. I understand that the disabled will be reset when VS Code is restarted, but I still hope that the command will take effect in the current window, such as the following. Is it possible to solve it, or other alternatives?
I am not sure if it is possible to update the args for the current window. CC
Only when you trigger a reload:
Thank you. So for the user, there's no way to solve this problem, right?
You cannot change the args of the current window as a user.
I would like to add, that this feature is not documented online somewhere right? I could not find anything about it... I just stumbled over it. Can an extension do this? Well it would reload the screen anyway, which is what we would like to prevent...
Yeah not even internally you can change without a window reload at the moment unless a specific component supports this of course, which depends on the use case.
Question: The user can simply disable a extension per Click, even defined if globally or per workspace, is there no such API an extension could call doing this? Its related to this comment: And we have currently 2 approaches (extensions) trying to improve the situation: Disable extensions Unwanted recommendations see for screenshots
would know
There is no API for this - May I know why an extension has to do this? Related, Have you tried the new profiles feature that is in preview? - This can be enabled using setting where you can create different profiles (settings, extensions, .... ) for different scenarios/use cases and switch seamlessly.
Hi, Yes, this is required in Vue, You can view the details here: I tried to use the profiles feature, but it seems that it cannot configure “Built-in Extensions”, and it is not very convenient to configure it once for each project, especially in teamwork.
You can configure enablement state of built in extensions in profiles. May I know if you tried this and if does not work and file an issue, because it is supposed to work. You do not need to configure for each project. You configure a profile once and open the workspace using this profile.
I just tried it, the profiles feature can't meet this requirement, first of all, the exported configuration file is compressed, it's hard to read and modify., After formatting it, I found that it can't disable the extension. When I switch between different profiles, it's more like uninstalling those extensions that are not selected, but built in extensions cannot be uninstalled. I tried using a new profile, then disabled a built in extensions in VS Code and exported it, and when I imported it, the extension wasn't disabled.
This is not hand written and machine generated. Yes, but built in extensions can be disabled and profile carry this information. Can you please share the profile?
Ok, here is the exported config file after disabling built-in extensions. Extension id: vscode.typescript-language-features VS Code: 1.75.0-insider
Thanks for the profile. I could repro the bug. Filed a separate issue tracking the bug so that it can be verified too.
Thank you for your patience and reply, I wish you a happy new year.


These 2 methods are called when any setting changes: I would have expected an early return if no related setting changed.


Found this in devtools, I played a bit with settings: <img width="1904" alt="image" src="https://user-"
Let me know if you can repro and find out the issue is deep in the list/tree.
Got you repro steps! the workbench window rather small. into 2x2 editor layout, so you get even smaller editors <kbdCmd ,</kbdto open the Settings Editor in one of the editor groups for <kbdCmd W</kbdto close the Settings Editor That exception shows up!
I just closed two other duplicates of this. There are repro steps since June. Let's see if we can drive this to a fix. Let me know if you believe it's deep down in the list/tree.


(See attached recording) I have enclose it in new use cmd+left to go to start of line ghost suggestions get accepted https://user-


Testing We shouldn't have tooltips here: !
what do you think? Currently, all toolbar actions have tooltips.
Yeah, unsure. All toolbars/actionbars have it but most have an icon and not the same text as the tooltip
Both options are fine for me. Whatever you prefer. I am slightly leaning towards no title. So we do not have hover in a hover (feels IDE-ish and heavy).


There's an unnecessary whitespace in "i18n/vscode-language-pack-". The whitespace after "command:" makes the link dead. !
you can add a comment to this string like so: to ensure that the command never has a problem like this. Notice that the example string has, in the Locked area, a at the start of it. This will make sure there is no whitespace between them.


a TS file Bug The repo index downloads quickly but TS initialization takes a long time From a profile, I noticed that some calls from the TS Server take between 200 and 400ms: ! I also noticed that we seem to be making network requests which invoke for a bunch of repos with names that look like file paths. ! Following this further, I noticed the request on JS/TS sends over two copies of every file: Note that these paths are transformed into URIs that look like: The first one is the correct path AFAIK? Not sure where the second one is coming from, but it seems to be the request that generates the network requests Does remote hub have two file system providers, one for and one for ? If it does, should JS/TS ignore the open documents?
Yes, there are two file system providers, and you can just deal with the URIs.
I consistently see two requests for TS server, is that expected? <img width="966" alt="image" src="https://user-"
Yes, we start two instance of the server: one fast one and one for project wide support. Hopefully with caching though this does not actually result in two network requests


Tracks picking up the Ts 4.9.5 recovery build Includes:
To verify, open a TS file and check the TS version in the language status item


<!-- 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. --I am not happy with ctrl-shift-f. My steps: hit ctrl-shift-f enter the search term see several search results. want to go to the first match : There is no easy way to get to the first search result. After that I want to use up/down keys to go through the search results. The focus should not be in the source code. Screenshot of state of Step 5: ! Goal: Up to now I use the mouse and click on the first search result. If I use the mouse, I am at this state: ! After thinking about this some days, I think the best solution would be to map the ENTER to "Go to first search result". But not like F4, since F4 moves the cursor to the file, and not to the search result list. The ENTER should give the first item in the search result the focus. Then I can navigate to the matching result, and the next ENTER will bring me to the source code line. This would be great for all people who can't or don't want to use a mouse. Related:
Hi again! I'm just a bit confused on this part: For me, F4 moves to the first match, not the first file. Is this not what you're seeing? !
I think right now this might be the best you can do: is a better command to consider than what you were using. The problem is that <kbdEnter</kbdis used to re-run the search if you make any changes to the inputs. But the above keybinding does focus the first result without moving the cursor, and then <kbdEnter</kbddoes move the cursor.
thank you very much. If I add they keybinding via "Open Keyboard Shortcuts (JSON)", it works. But not always. After alt+enter I would like to use the up/down arrow keys and see the preview in the files. The strange thing: sometimes up/down shows me the places in the files (and the current entry in the result list is highlighted in blue color), and sometimes up/down does not show me the preview in the files. We are on the right track, but not there yet. Thank you very much for your kind support.
For me, F4 moves to the first match. If I press up/down keys, the cursor moves in the file. But I would like to move up/down in the search result list and see the preview on the right side (in the window of the source code editor).
Hmm, that's interesting, I'm also seeing that the files aren't previewing after using . will look into this more.
I think I can get reproducible steps to the state where the file doesn't open when you have it highlighted in the tree view a long search it is searching, run using the up/down arrows to browse the search results, the file preview isn't triggering :bug: tree node is focused, but not selected :bug: This bug might be related to This is weird in that it only happens sometimes.


Not sure why this is happening, probably just need to restart, but I notice the notification is different depending on whether I press F5 to continue or press the play button: F5: <img width="1320" alt="image" src="https://user-"Debug play button: <img width="359" alt="image" src="https://user-"
I think is from js-debug?
Logs would be helpful, this indicates V8 responded with some kind of error (which I haven't seen before...) Alternatively, are there steps you take to reproduce this issue that you can share? /jsDebugLogs
Please collect trace logs using the following instructions:
I don't care about the error, I think it was some process in a bad state. The issue is one notification is a warning and one is an error <img width="185" alt="image" src="https://user-"!


Steps: from command line run it stalls We maybe missing a web worker related directive in our HTML files? //cc
Yeah, looks like needs to allow-list
May candidate? But I am unsure when/where/how the CSP are into effect. where do you see this? I have checked CSP allows blob as worker-src codespaces CSP allows blob as worker-src code-tunnels blob also allowed blob also allowed ????
I saw it with our web bits from our server, so basically: download server run it access the web UI I am not sure this would be a candidate for today, but maybe recovery and only if we see an actual issue from it. So far this is only an issue for perf testing, but we do not perf test our server, only atm.


When developing extension the warning in : is wrong because it doesn't check if the extension is supported on older VSCode versions:


Install Java extension pack Open VS Code repo Cmd+Shift+B Java extension prompts error and the task detection never finishes
We have to wait for extensions to be registered before reading the tasks because of task contributions from extensions. I don't think we can change this. thoughts?
We could have a timeout per task provider. If a task provider doesn't provide tasks for 3 minutes after we ask for tasks then it's likely it will never provide tasks. That would let us show the tasks for all the other extensions except the slow one.
I just hit this again , in a VS Code instance that had been running for quite some time. Are there logs that we can provide next time this happens? I enabled trace logging and looked in the Tasks output channel but did not see anything other than a warning about shell tasks being unavailable.
I will try to get to this in March, no logs are needed as we understand how this could happen
Original repro steps still work
Steps still work sometimes - saw this when I reproduced !
Alright, onto something - the consistent repro for me is when there's a multi-root workspace - with each repo contributing a default build task. the build task see quick pick with a bunch of tasks, not just the default build tasks When that's the case, yields none because none of the tasks have a property set yet and that is required for this predicate to be true So enters here and by that time, the group is defined ! and since there are multiple, this gets called
Then it enters and concatenates non-defaults to the defaults. I don't think we want to do that. !
the fix is to only get the defaults and show those. we don't care about the others here. !
Regression introduced by , but there's also the timing component as indicated above - the group isn't set when we expect it to be. Perhaps in the single repo case, the hasn't yet been set by the time , the second attempt, occurs
I think we should be awaiting before running the build command
Apparently this still happens
ok in OSS where I'm reproducing, it goes in here like I thought ! then there are no workspace tasks found ! so it goes here !
only the are used here !
so the issue is the aren't resolved in this case. it's not timing dependent - I can repro long after the window has opened. !
I think here should have a size 0 !
interesting - I wonder if this is the issue !
worked: ! failed: !
so I think what's happening is if I trigger the build task before folder open, the promise is set but the tasks for that folder aren't parsed. then we return that promise indefinitely. I think checking if the is is in order here and in that case, we want to update the workspace tasks instead of returning the promise
yep - I believe that works. ! So the repro is to run the build task before the folder opens.
Just reproduced twice. When I did, both times it said this:
still happens in the build I created with the latest fix. note that i don't see extensions getting activated in the status bar here at all I also don't see the workspace folder undefined message anymore, but still see that the tasks are unavailable in the current environment.
the moment I change the file, it starts to work. IE when this is called
While it's possible (extremely rare) that a user will still hit this if they run the build task before a particular execution context has been set, this fix will prevent that from reproducing. To verify, open VS code (typically a restart) and run the build task. If you do see the quickpick instead of the default build task getting, run, then the next time you run the build task, you should not see it. The above should be hard to reproduce though - and only possible if you time it just right. Before, this would happen more frequently and was reproducible until window reload.


<!-- 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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.


I try to add a keybinding with ${selectedText}. but it will resloved as a normal string. Steps to Reproduce: ! Version: 1.75.0 (user setup) Commit: OS: Windows_NT x64 10.0. Sandboxed: No
would you happen to know why the variable isn't resolving to a value here? Is there something that the command must contain to resolve variables?
The decision for whether variables should be resolved in a command needs to be made on a per command bases. If you want, you can run your commands arguments through the variable resolve when your command is called. For example, the terminal uses the variable resolver here:
From It would be great if more variable resolution was achieved in keybindings - I think it has been requested many times.
verif steps: a keybinding for : that the keybinding correctly sets to the current path.


This is a weird statement that seem to do nothing. I am creating this bug to accompany a PR to fix it. If there is an actual reason I am also happy to add a comment for it.
Thanks for the fix


an object that has many long property values There is no scrollbar the prototype There is a scrollbar !
Probably only with the horizontalscrolling setting enabled? I know that's a bit tricky
What's the setting for that? I don't have any scroll setting that appears debug related enabled. Just sticky scroll for the editor.
I think you have set, right?
No I do not.


Testing When I was on the section of the walkthrough I clicked on "open remote repository" and it had the dropdown. I noticed that I couldn't just click outside the dropdown (back on the welcome page) to make the dropdown disappear and instead had to use the "esc" button. From my experience with other dropdowns if you click away from the dropdown it disappears and think that behavior would make sense here.
does the quick pick come from ? If yes, who should I direct this issue to?
Yes that's where the quickpick comes from. owns the desktop git extension.
could you please help with this? Thanks.
Clicking outside of the dropdown still doesn't escape. !
It turns out that the "Remote Repositories" extension does not leverage the picker from the git-base extension so the fix that I made is not relevant. To verify this, please download the latest pre-release version of the "Remote Repositories" extension.


With `"editor.wordWrap": "on"`, the color hints (inline color decorators) may be double-displayed near the wrapped view edges. ---- Version: 1.75.1 Commit: User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/ Firefox/111.0 Embedder:


<!-- 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.76.0 OS Version: Windows 10 The most recent VS Code update broke bracket colorization for PHP files, when you close a PHP tag then open it again before using a closing bracket. Steps to Reproduce: a PHP file a PHP open tag , open a bracket with , use an end tag , step 2, but with a closed bracket show as red, and the coloured line that joins the brackets doesn't show. Note: The red brackets are normally only used for errors, so it makes it look like there's errors in the file Screenshot: !
Same problem here on Unbutu! Could you fix it please?
Same error on ubuntu Ubuntu 22.04.2 LTS
Also happens if you just have the opening tag but no closing tag at the end: !
Hello, thank you to open this topic. I have the same issue while writing PHP code on VSC. It would be great if could be fixed. Have a nice day !!
Same issue here on Mac OS 13.2.1
Same here
For anyone who needs this fix before the next update: Add this to your settings JSON (fix via PR )
I have a similar issue using math equations in markdown, the image on the left is version 1.76 and the one on the right is 1.75.1, both of them with the same settings (by sharing them). The fix suggested by did not resolve my problem. Should I open a new issue since it is a different language and context? !
Possibly related on Stack Overflow:
Related: :
Same issue with me
You should scope it to language, otherwise the bracket setting applys to all languages
The update and modified settings as suggested by didn't solve the issue I mentioned in . Might be related to . Below is the today's insiders version w/o any extensions with the same issue despite even scoping the brackets as suggested by above. !
omh same here lol..


On Windows: clone open workspace look at the workspace settings: all files are associated with schema . Note that this is a relative path to the workspace file open both files and check that code completion gives back property . You can also click on the JSON language selector ( next to JSON in the status bar) to see the schema that is associated :bug: No code code completion or schema association
76 candidate PR:


Type: <bBug</bContext changes causes images to flicker and, worse, quick picks to close. Run Open walkthrough Open step or Hit the button Quick pick closes right after clicking and image flashes. VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-08T05:22:25.379Z) OS version: Darwin x64 22.3.0 Modes: Sandboxed: Yes <!-- generated by issue reporter --
Seems as the context changes, which changes focus and closes the quick picks.
I can't repo this on OSS. But used the developer tools on insiders to debug it. fires the context changed event too many times which causes us to reload the media I removed rebuilding step if the step is already open which should fix the issue for the walkthroughs. But there is likely a larger issue to be fixed with the being fired too many times. You can turn off settings sync and try the steps described above - no repro.


Version : 1.76.1 Commit : Date : 2023-03-08T16:32:15.546Z Navigateur : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.4985.0 Safari/537.36 Edg/102.0.1235.1 with the extension installed (stable) switch the display language to French, reload VS Code switch the display language to English, reload VS Code open the remote menu, see that there's still a French menu entry in there ! Open the extension view ! I also see it the other way around: !
Ahhh so it looks like this is returning remote-repositories extension: with the old german manifest. What’s odd to me is that remote-repositories is being returned by and ... but even still, I don't know much about this code, but I would expect that the cache would cache the manifest in its raw form with the placeholders and then allow the runtime to translate the manifest (which could be optimized to cache both raw and translated form and only re-compute when language changes)
I'm giving this one to you since it seems like a issue from the caching changes.
It seems we are translating the manifest always even if it is cached. But, I observed that some how (I do not know, may be in the old code), cache is having the already translated manifest. Therefore, while translating nothing gets translated. We do update cache every time but it seems if the version has not changed, we reuse the entry from the cache. There is no reason we have to reuse the entry from the cache. So fixed it by recomputing the cache entry always while updating the cache.


Type: <bBug</bWhen working in a CSS document, if I use the query, a pop-up occurs stating: I have not noticed any negative impact besides the pop-up obscuring terminal menu. When looking at the output, the log states: VS Code version: Code 1.76.1 (, 2023-03-08T16:32:00.131Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ better-comments3.0.2 prettier-vscode9.10.4 gml-support1.7.4 vscode-language-babel0.0.37 git-graph1.30.0 powershell2023.2.1 vsliveshare1.0.5834 vscode-css-variables-autocomplete0.3.1 LiveServer5.7.9 code-spell-checker2.19.0 vscode-icons12.2.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Type: Bug same probleme, working in a CSS document, using query, a pop-up occurs stating: VS Code Version: 1.76.1 (Universal) (, 2023-03-08T16:32:00.131Z) OS version: MacOs Monterey 12.6.3 (21G419) Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin x64 21.6.0 Sandboxed: No
A similar error seem to be happening when writing in a .scss file. Writing or pasting makes the error popup appear, but a does not. To be a little clearer, here's a list of patterns with that can be pasted in a .scss file to trigger the error : - ( there's a space here at the end) - - (note: does not trigger the error.)
Type: Bug same problem here, working in a CSS document, using query, a pop-up and related terminal occurs stating: Error: selectionRange must be contained in fullRange at Function.validate (/Users/james/Desktop/Visual Studio ) at new t (/Users/james/Desktop/Visual Studio ) at V (/Users/james/Desktop/Visual Studio ) at c (/Users/james/Desktop/Visual Studio ) at (/Users/james/Desktop/Visual Studio ) at Object.asDocumentSymbols (/Users/james/Desktop/Visual Studio ) at i (/Users/james/Desktop/Visual Studio ) at n.provideDocumentSymbols (/Users/james/Desktop/Visual Studio ) <img width="1231" alt="스크린샷 2023-03-26 오전 10 32 42" src="https://user-"
Mismo problema, esperar alguna actualización para que lo corrijan? ! !
I'm having the same issue.
I'm confused. It says this was fixed but I'm still having the same issue. Nothing i've clicked on in this page is telling me how to fix it and use
I will be in the next insider build
Same issue
Same issue
As mentioned, the fix is in 1.78. If you still see this, please add the build you are on and a small code sample to reproduce.


<!-- 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.76.1 OS Version: macOS 13.2.1 (22D68) an that uses a schema other than or . For example, : text renders as a hyperlink (dotted underline), but isn't cmd/ctrl+clickable like other like OSC 8 hyperlinks with the / scheme. Other OSC 8-capable terminals (like ) will open the link correctly. Here's a video demonstrating the issue with several other URL schemes: https://user- As you can see, only and URL schemes result in clickable links. If I remember correctly, this regressed in the 1.74 -1.75 update, which leads me to believe it might be related the introduced in that version. This functionality can be super useful for tools like , which let you add hyperlinks to line numbers in diffs. When this functionality worked in VS Code 1.74, those links would be clickable: !
Since everything supported this, I relied on it, damn. Would be amazing to have this back. Only non-heuristic way to get clickable file links in the terminal that handle all paths (e.g. paths with spaces)
We currently do not allow non-http(s) links due to allowNonHttpProtocols here: This may just be a case of adding that property to , but we need to make sure it won't introduce a security issue.
Hm, running code in a terminal generally means one trusts it. After all at this point it has access to a lot of things. Displaying data from untrusted sources without stripping ANSI escapes is more a problem of the tool displaying the data. I think when a terminal link is hovered, VS Code should just show a little link target floaty thing that shows where the link points to. Other terminal emulators do that. If you’re being paranoid, show a little when a link label looks like an URI but the corresponding link points to another URI. But that’s a situation people have in the web all the time, so they should know it can happen.
sure, but you can some file and it will evaluate sequences which is a common attack vector. The user is typically unaware that could result in execution and/or malicious links being inserted. The hover is probably sufficient, I would want to double check with someone on the team who has done some general URI handling when looking at the PR.
I understand the reasoning for disabling this, as VS Code focuses pretty strongly on security given its popularity (workspace trust, confirmations when opening links, well-defined extension API), but would it be possible to allow non-HTTP hyperlinks in the terminal via a setting? Something like ? It seems like implementing this would be a simple pass-through to 's property on (which you previously linked to). The setting could even have a security warning in its description. It'd be really nice to have this functionality back.
Who needs to sign off on a decision here? This is affecting me pretty much daily (since my testing framework uses this and I simply can’t make VS Code behave)
If would be nice to support at least links, so that one could open files within VS Code, by clicking on a link in a terminal.
+1, our framework uses OSC 8 links as one of the exclusive features vs competitors. Missing support in VS Code makes it irrelevant and degrades our productivity.
Easy testing below, only the first 2 work: Note that we wouldn't be able to support any arbitrary link without additional work as there are security concerns.
bash should work
yeah the file needs to exist for it to work
are you connected to the window via the Remote - WSL extension? If not this is as expected currently.
created to track your 1. For 2 right now proper WSL link support only works within Remote - WSL windows, so making this work well in local windows would be a new feature request.


Using the test-provider-sample, adding newlines on a line marked as a test duplicates the test icon: ! It sorts itself out on the next update (at least in the sample, I'm still investigating to figure out if there's another issue, or that's in my extension). But it still looks bad - especially if a language is debouncing edits and/or discovery may be slow.. You can make the issue more pronounced (as I did for the GIF) by updating the test-provider-sample to have a delay in its updates:
I was able to repro the full issue I'm seeing in Dart (where the icons never disappear) using the sample too: ! My changes to the sample are here: I changed it so that tests can span multiple lines (since the original code split on lines then searched each line) and use the full range as the for the test. Now when pressing in the test, the original issue (VS Code duplicate the icons) still occurs, but also after the updates, since the range computed by the provider doesn't change from the range VS Code currently has (at least that's my guess), there's no update to the gutter icons so they no longer get cleaned up.
That's correct, we let the editor do its default decoration tracking until an update is received from the extension. for testing decorations, I already set , but is there a similar option to avoid extending the range over lines when edited? Or, alternatively, a way to only apply the glyphMarginClassName to the first line of the range. Reference:
You can create two decorations per test. One which has a range, a hover message, etc. And another one which renders the glyph margin with a collapsed range (perhaps the start position of the range). If you use for the second one, given it begins as a collapsed range, it will never grow, it will always remain a collapsed range.


Ubuntu 22.10, Gnome 43.1, fresh VM - The errors are not shown the second time I call and also VS Code seems to start and work I saw , but that should be in by now.


a notebook and run a cell that will continuously update over time to drag the scrollbar while output is still being written :bug: scrollbar is not held and returns to the bottom
Streaming output items are all compressed into a single item in (?), so we would need to stop doing that unless needed (for editing previous lines) Also, the current method only allows passing a single output item, but the output renderer will need to be able to render the entire output as it currently does, or just append the new data. Current: Proposed method that would only be used for streaming outputs and if the chosen renderer contains the method: Another alternative would be adding info to the OutputItem itself, containing only the appended string if appending should happen.


Testing When there's too much output, this link uses to explain what it does: <img width="76" alt="image" src="https://user-"<img width="205" alt="image" src="https://user-"This isn't accessible, you should set such that it's read by a screen reader.


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


Currently when you use navigate accessible buffer you get a quick pick with the options, I expected changing these to scroll to the position without accepting it, and escape to revert to the original scroll position.
As part of this, providing ~1/3 of the viewport of context above would also be good
We'd need to think about how we to communicate the preview information to a screen reader user, as a pre"view" is usually visual
I don't think making this available to the screen reader makes sense, it would just complicate navigating the list. It is useful for sighted users though.
Oh I understand now - you mean on change of the active quick pick item, reveal the line and on enter, focus that line (as it already does)
Yep
To verify, in a terminal with shell integration, run some commands. to enter the accessible buffer. to . Without pressing , use the arrow keys to go between the options. It should scroll to the command if it is outside of the viewport.
Works but I opened


Using here, I cannot enter the accessible buffer https://user-
The issue is that here, the default tab behavior is to focus the terminal tabs element edit: hard to repro, that's not the cause
ok this happens when is not applied to . See here that the buffer editor does get focused here, but you cannot see it https://user-
Repro: run some commands - - - Try to wasn't applied to so the accessible buffer isn't visible
https://user-


<img width="980" alt="image" src="https://user-"
I suggest to move the docs into our wiki. PR to remove these files:


<!-- 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.78.0 OS Version: Windows 10 (x64) Steps to Reproduce: "Centered Layout". the editor by independently moving its sashes (holding down Alt). and restart VS Code. The position used to be remembered in previous versions, but starting with version 1.76, the position gets reset on every start. Only the width is being remembered. It's still broken in the current insider build of VS Code 1.78.0.
Do we already know, which commit causes this regression?
I looked through the commits for 1.76.0 and I suspect it was .
Yeah, it is solved for me.


The Angular language service extension spawns a child process using and listens for the and events. The current version works as expected. Without any changes to the project, simply updating to results in the forked child process acting differently (never erroring and never closing). I'm using Mac 13.3.1 but we also had a report that the forked process isn't working in WindowsNT x64 10.0. either. There was a similar issue (though not entirely the same) a while back: Apologies for the rather involved reproduction... Here's how I'm able to reproduce and compare the behavior between the versions: our the repository with vscode insider version 1.78.0-insiders out the branch (we're actually removing this in the next version so it doesn't exist on ) dependencies with debugging, put a debugger statement before and one in the . The project is built with bazel so breakpoints would have to be put in the compiled JS files. the build script with the extension development host (Dev Client + Server run configuration) In the extension host, open the and then open the template file -- debugger should stop on the fork and if you continue, you will see that the debugger stops in the stderr data listener but never in the or . The output of the stderr also indicates that it is listening for a debugger and that it gets attached. The fork used which should have prevented this. The process also never produces any results or completes. You can have the fork retry by running the Angular: Restart Angular Language server command in the extension host. I've also verified that the spawn args are the same between versions and both include "--ms-enable-electron-run-as-node".
Issue was caused by the allocator changes to processes which now schedule delayed tasks to purge memory cache ;l=1183 and that revealed a bug in the causing the process to hang.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!


<img width="1440" alt="image" src="https://user-"path: Versions:
I have one question wish can get help: how vscode terminal detect the path cwd? why can the path correctlly go to the file with a releative path? <img width="1440" alt="image" src="https://user-"I guess it may use the But seems I can get the cwd in TerminalLinkProvider now: <img width="1440" alt="image" src="https://user-"
We check a few things to determine which to use
vite become more and more popular recent days, I think it would be convinient to support the path with query string: !
When I click, it opens the right file, but it underlines the first query argument when I hover, is that an issue? <img width="539" alt="image" src=""
not much of an issue but it would look more polished by just underlining the whole thing


Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.77.3 OS Version: Ubuntu 20.04.5 Steps to Reproduce: (incorrect category, should be themes) outputs: suggestion: Get warning:
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!


Type: <bBug</bHow to reproduce the issue: and Run the Extension the , and then the pane. Use the dropdown and select the Dynamic Configuration Provider . With the checked out branch, it will show the quick pick options for Option 1 - 3, but will not show a quick pick for the resolved configurations. This seems to work for , but not Expected: ! Actual: ! VS Code version: Code 1.77.3 (, 2023-04-12T09:16:02.548Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I've updated to: and it still reproduces.
for prioritization help as per email thread
Sent a PR for this. But what is the inner quickpick? I'm a little unsure about the approach, I don't think we expect a provider to include some UI. Your extension doesn't own the UI in this flow- you are just implementing a provider method which will be invoked at different times, expected to return a list of configs. It might make sense in one situation to show the quick pick, but we could make changes in vscode to call your provider at a different time where it would be unexpected to have a quick pick pop up. And, any extension can implement a config provider for your debug type. So for example, multiple extensions could all be showing their own UI in this scenario. However, from memory, I think the Python debug extension might already have a similar multi-step picker UI for a scenario like this.


https://user- problem extension:
I have the same problem in tooltips of TreeItem. I thought it was associated with my extension, but apparently not. This behavior does not happen with the GitLens extension.
This issue only happen to stausBarItem at left side
!
this issue should be mark new release label
can you help look into this issue?
Wasn't this always like this? I just tested and it's not hoverable in 1.78.0 either. You can hold alt to hover it though which is a common feature of hovers (outside the editor)
1.78 is the current VSCode version - the one where it broke. 1.77 and below works properly.
Doh, checking an older one
Looks like the hover only sticks if there are textual links in it. Example is the hover on the next to the language selector. I didn't change anything in the hover area recently.
that's how it used to work, it doesn't anymore. and I made some changes around this recently, it was probably us.
this is by design if the content does not contain any links. Hold alt to "lock" any hover
This is happening because you're using an anchor tag, a change was made recently to only force hovering when the hover contained "](". I'll add an anchor tag check.
Curious, because in these tooltips I never used links (html or md) and it worked. Recently this behavior started This tooltip has always been used by my users to copy information, by simply selecting and CTRL + C
previously the logic would disable hide on hover if it was any markdown string which is why it was like that. If the user wants to copy information they can do so by . I know it's not the most discoverable but it's intuitive once you know about it. It's a harder problem than you might expect because if it didn't behave like this we would get the opposite type of issue where hovers are really annoying because they don't dismiss. So we don't hide hovers on mouse over only when there's a high chance of interaction.


Type: <bBug</bCC: I noticed that I can't navigate the accessible buffer using ctrl left arrow or ctrl+right arrow. When using this combination orca treats the whole line as if it were a single word. Except for misunderstandings, this happens because the blank spaces present in the accessible buffer are being replaced by the character 0xa0. I ran the command echo "this is test" in the VSCode terminal and ran the same command in the gnome terminal. Browsing character by character with orca I noticed that in the gnome terminal space appears as 0x20 and in the accessible buffer it appears as 0xa0. VS Code version: Code - Insiders 1.79.0-insider (, 2023-05-04T22:12:16.054Z) OS version: Linux x64 6.2.14-300.fc38.x8664 Modes: Sandboxed: Yes Remote OS version: Linux x64 4.14.146-93.123.amzn1.x8664 <details<summarySystem Info</summary </details<details<summaryExtensions (44)</summaryExtensionVersion ------ doxdocgen1.4.0 vscode-markdownlint0.50.0 vscode-eslint2.4.0 EditorConfig0.16.4 copilot1.86.82 rest-client0.25.1 better-cpp-syntax1.17.2 docomment1.0.0 azure-pipelines1.208.0 vscode-docker1.25.0 csharp1.25.7 vscode-dotnet-runtime1.6.0 vscode-kubernetes-tools1.3.11 remote-containers0.293.0 remote-ssh0.101. remote-ssh-edit0.84.0 azure-account0.11.4 azurecli0.5.0 cmake-tools1.14.31 cpptools1.15.4 cpptools-extension-pack1.3.0 makefile-tools0.7.0 powershell2023.5.0 remote-explorer0.5. vsliveshare1.0.5864 oracledevtools21.5.0 fabric8-analytics0.3.6 java1.19. vscode-xml0.25. vscode-yaml1.12.2 sonarlint-vscode3.17.0 cmake0.0.17 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-boot-dev-pack0.2.1 vscode-spring-boot1.46.0 vscode-java-debug0.50. vscode-java-dependency0.22. vscode-java-pack0.25. vscode-java-test0.38. vscode-maven0.41. vscode-spring-boot-dashboard0.13.0 vscode-spring-initializr0.11.2 gitblame10.2.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
We replace these spaces intentionally, but I'm not sure why . thoughts?
As it is, I can't use orca to select words and I can't navigate by words either.
We replace it with a non-breaking space such that white space appears the same as it would in the terminal. I wasn't aware it has this impact on screen readers (maybe it's just orca?) but we could workaround it by replacing (2 spaces) with . That should keep tables, ls, etc. aligned while fixing the problem at hand. It seems like an Orca issue though as I'm pretty sure a non-breaking space should be getting treated as a space.
I also think this should be corrected on the Orca side because the same problem also exists when I'm editing a file. I can't navigate through words in a text when they are separated by the 0x0 character." Reported this issue on the Orca mailing list.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
This doesn't appear to be fixed: ! ! It is changing multiple lines to include a single space character as expected, but see the first line where single spaces are changed. I'm questioning the fix we came up with though, monaco replaces spaces anyway in the editor: ! I think we should revert this and have orca fix it, instead of trying to workaround their problem which could end up causing other issues for us?
I ended up reporting this problem to the orca developers because the problem also exists when I'm editing a file that has words separated by the character 0xa0. I believe the problem will be dealt with on the orca side.
If I understand what reported correctly, I don't think this is an Orca issue. When Orca is in focus mode, it does not control or consume input events. In other words, Ctrl+Right/Left arrow will do whatever they would do without Orca running. And from some testing, when the words are separated by 0xa0, VS Code (or Chromium) is treating the string as a single word. If, in those same places, I switch Orca to browse mode, Orca IS controlling/consuming the input events, and it already does treat the string as individual words. But if I'm missing something, please let me know what I should be fixing in Orca. Thanks!
Here are the steps I am using to reproduce the problem which I believe is reporting: sure Orca is NOT running. a new document. "This" Ctrl+Shift+U "00a0" followed by return to insert a non-breaking space character "is" steps 4 and 5. "a" steps 4 and 5. "test." Home to move to the beginning of the line. Ctrl+Right to move to the next word. Expected results: The caret would move just past the "s" of "This". Actual results: The caret immediately jumps to the "." at the end of the sentence.
thanks for the follow up, you're right. we should not be replacing it with non-breaking spaces as monaco handles their presentation. When you paste in the characters like describes (I did it by running 'u00a0' in console and copying that) you can see they're treated specially, we also have a lint rule to prevent this in vscode: !


<!-- 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. --<!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.79.0-insider OS Version: macOS 12.6.3 I am working on a file explorer tree view extension and doesn't work properly if is 2 or 3. When expand is 3 only the first level 3 folder expands. I have checked and doesn't get called for the rest of the level 3 folders. If I call again with the rest of the level 3 folders expand. When I use with 2 or 3 on a large folder (hundreds of items) the promise never fulfills even though the folder expands (at least up to level 2). I don't get any error in any of the two cases.
can you share a minimal example that reproduces this issue?
Sure thing, here you have it:
Thank you for the repro repo!
No problem, thanks for the fix!


Callstack is similar to the one mentioned in but the issue remains First failure Second failure
The logs read very normal, we literally hit the 2min timeout. Since these tests do double the work (start VS Code 2 times), I will see if increasing the timeout helps.


I'm seeing some flickering here, just Write a multi-line commit message cmd+enter to commit !


I see this in the console log when I reload vscode insiders window: <img width="1463" alt="image" src=""vscode insiders with the vscode welcome page open (I can't repro without the welcome page) window and you'll see the errors in the console logs


<!-- 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: Steps to Reproduce: an invalid decoration in warning in ext host logs that says instead of the extension name:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!


Testing ! !
This is because of the same problem that caused
appears to be closed now, does that mean this has been fixed?
No, this issue is about fish acting atypical in that it applies the environment before is applied. This is because of how the automatic injection works in fish via an environment variable. Still not sure how we can handle this.
Discussed offline, maybe we could use the first pre exec hook in fish to run shell integration, instead of .
Nice !


On the notebook toolbar we have multiple sections of actions, and the first two are core sections: insert and execution. The Insert section is very stable and it always contains two actions: insert code and insert markdown. However the execution section has actions from both VS Code core and Jupyter extension, and with a mix use of visibility and enablement, it is not user friendly and often leads to mis-clicks. Initial state <img width="811" alt="image" src=""Start execution <img width="884" alt="image" src=""Execution fails <img width="903" alt="image" src=""Execution succeeds <img width="810" alt="image" src=""Initial state <img width="657" alt="image" src=""Start execution <img width="867" alt="image" src=""Execution fails <img width="728" alt="image" src=""Execution succeeds <img width="625" alt="image" src=""As shown above, currently only is using enablement while all others are using visibility, which can lead to change of positions for the actions and often when users want to interrupt or restart the kernel, their position changes and users click on wrong actions. cc
What are users misclicking on? From my memory, I remember Go To vs Restart. I think that "Restart" has a confirm dialog, are there other destructive actions that should also have a confirm dialog? Or, should we use enablement and have all actions always visible?
For Jupyter kernel, I ran into Go To vs Restart and sometimes Restart vs next action on the toolbar (since Go To disappears), and for non Jupyter, it's Interrupt vs Clear all outputs. It might be hard to enforce that but we could probably at least ensure the ones that are always visible won't change their position when the execution state changes. For example, if Go To only shows at the end in this group, and Run All is always replaced by "Interrupt" or "Stop", then it's less likely to mis-click.


<!-- 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.77.3 OS Version: Windows 11 Steps to Reproduce: a git repository a file with brackets in the name, e.g. the file in the git tab and add it to the file Desired behavior: The filename is to the such that the file is ignored Observed behavior: The file name is to but it is not ignored. This is because the syntax of does not interpret brackets literally. To ignore a filename that includes brackets requires escaping brackets with backslashes. gitignore after step 3: for desired effect should be: Proposed fix: Pre-process file names to to escape special characters.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.79.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!


Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -


I had a "Testing" profile with various remote extensions installed. I deleted it (while being in it) and then recreated it empty. I still found all remote menu contributions even though the profile should have been empty. Maybe switching profiles should ask to reload the window when extensions require so? Steps to Reproduce: fresh user data dir, fresh extensions dir create an empty profile install SSH extension notice how the remote explorer view appears delete the profile notice how the remote explorer view is still there, same as the status bar entry for remote
Another case from is interesting: I do not think using a profile is a good idea for when extensions require a window reload to be disabled. So you need to then probably ask the user to reload the window or do it automatically.
AFAIK every extension requires a window reload after being disabled (except for package-json only extensions). We cannot unload code from extensions and cannot enforce them not doing anything anymore. There we always reload the window or at least the extension host
While switching profiles we restart extension host. You say this is not enough to unload extensions? Also while trusting/untrusting a workspace.
No, only those that are activate with code loaded. Here are steps: fresh user data dir, fresh extensions dir create an empty profile install SSH extension notice how the remote explorer view appears delete the profile notice how the remote explorer view is still there, same as the status bar entry for remote
I see this can be reproduced with above steps. But Remote Explorer view disappears with switching profile. So I think this is a bug (either in views or profiles) when profile is deleted. But status bar entries always appear.


Testing I am currently one commit behind the remote branch and I am able to successfully create a link without seeing any dialog. The way the test plan item is written it implies that in this scenario, I should see a dialog. Is that the case or did I misunderstood the test plan item?
Testing with while being a few commits behind, I get the following dialog: <img width="264" alt="image" src=""When I Cancel, I don't get a link. When I Pull & Copy I get a link that is seemingly unaffected by the pull. Why then require the pull? (I tested with incoming commits affecting the file I copy a link from.)
The link that is copied might point to a range that is invalidated by incoming commits, so we notify in order to avoid you copying a link that points to a different area in the file. But perhaps we should also offer a Copy Anyway option here.


Repro: OSS trace logs window ! I don't have copilot installs in OSS so I wouldn't expect anything to happen here. Not sure what the 2 chars are.
Probably


Issue filed by Hi, I would like to ask about a problem related to the usage of WorkspaceConfiguration.Update() We received an issue This happens when the C# extension starts, we are migrating some old configurations to its new name when using a non-default profile. (This doesn't repro when use default profile) See the code here: I tested locally and verified the issue in feedback happens when executing during the extension activation. What I did is created a non-default profile, and put one of our deprecated options in the global profile. <img width="985" alt="image" src=""Then the error occurs when removing the old configuration see this ! The old configuration is removed in this case. Is this our misuse of the API or is this a bug in vscode?
Profile / config - assigning first to Sandeep this is from the C# extension, so if you have additional questions feel free to ask or let me know if I can help in any way.
It would be great if we can have a summary of steps to reproduce
can you provide steps please? Thank you
My repro step: Install the C# extension in the preview channel. <img width="665" alt="image" src=""- Use this sample solution, open it. Create a non-default profile. <img width="515" alt="image" src=""- Open the profile in json editor. Add these to the JSON. Close VSCode and restart it. You can see one configuration is changed. <img width="602" alt="image" src=""C# extension is not activated. And the error log is shown in the extension host output window.
can you verify that this fix indeed fixes the problem you reported. Thank you!
Verified it is solved in 1.81.0-insider


cmd+F to open find widget Close it with escape cmd+up to navigate to previous command Nothing happens, I have to click or run a command to reset focus in the terminal
I can't reproduce this, if you still can are there any more details on the repro case? The keyboard troubleshooting command output would be helpful if only you can repro.
Sorry it's working now, agreed that it was probably a context key thing so I'll check that next time
I can repro this when the serch input have has text selected, PR