Currently in VS Code when users open a notebook document, they don't need to pick a kernel manually only in following two scenarios: The notebook was opened before and users run the notebook against a kernel already. That kernel will be picked automatically, no other kernel would replace it unless users pick one manually. There is only one kernel contributed to this notebook. When users run a cell, and there is still only one kernel, the kernel will be used. Before users run any cell, and there are more than one kernel, the kernel picker will not show any active kernel info (it shows "Select kernel" instead). Above two scenarios cover two use cases: open an existing notebook, or work on single controller notebook (e.g., GitHub issue notebook). However this doesn't cover two common workflow open their existing Jupyter notebook (created through other Jupyter frontend/service) in VS Code create new Jupyter notebooks when they have already specified their preferred kernel Especially that VS Code is still growing to be one of data scientists' Jupyter frontend/editor, almost every new users will run into workflow 1 and do manual kernel picking though often Jupyter has a good guess which kernel is preferred for current document, and also every existing would run into workflow 2. The concrete issues reported: [AZML/Open in VS Code] on AZML website, click open in VS Code, it opens a remote window and opens the notebook document in the editor. No kernel is not picked though users already specify one in AZML website. notebook A in File Explorer, pick a kernel. Create notebook B in File Explorer, the kernel info is back to "Select Kernel" again. untitled notebook in Editor Area, pick a kernel and run. Save as a new notebook document on disk, the new document has no selected kernel. . Create a notebook in JuliaLab, specify a kernel. Open the notebook then in VS Code, preferred kernel not selected. Proposals For AZML/Julia users, they are mostly working on single language notebook (other than polyglot), meaning the notebook serializer is the ipynb extension we ship out of the core, and kernels/controllers are contributed by a single notebook extension installed from the marketplace (Julia, or .NET, or Jupyter). If this is the case, we can pick the kernel whose affinity is the only highest without prompting users to pick one.


cc
Had discussions with about this. In addition to the proposal mentioned above (optimizing the single extension contributing multiple kernels scenario), another idea came out of our discussions: Allow users to choose the default kernel. One example is users have both Jupyter and Julia extensions and both of them contribute notebook controllers for Julia execution. Users might have their preference for the default kernel, allowing them to specify which kernel should be the default can help avoid users picking the default kernel in every newly opened notebook.
I thought about filing a new feature request on this. But it seemed better to keep the discussion contained here, at least for now. In particular it relates to the last comment about selecting a default kernel as well as the Gear icon for the notebook controller. Speaking personally, the majority of my issues with kernel selection would be alleviated by the ability to select a kernel to be my default, auto-selected kernel at both the global level with the ability to override it at the workspace / resource level, just like the rest of VS Code settings. All the rest of selection could work like it currently does. But I want the ownership to be able to explicitly specify kernel selection with some type of manual affordance that always trumps any type of heuristics or metadata or forcing a manual selection. At a surface level I like it as just a setting, but the issue here is that controller IDs are not something that's exposed to the User. The Gear icon might be the right place to surface this, and might have even been what the Gear icon did before (it does nothing now for me in insiders).
Agree 100%. Even though we could save the controller id to settings when users use the gear icon, it's not great as users won't be able to read or tweak this specific setting as the controller ids are not always human readable. With that said, we could tackle this differently to archive the same thing, instead of asking controller id, we could ask users if they want to use the lastly used controller, use a controller suggested by extensions always, use a controller which matches the workspace stats the most (use Julia controller if the workspace stats are all around Julia files).
Yeah, that's the challenge here. Controller ids aren't nice to read and not guaranteed to be constant. A better concept is user state, e.g mementos, which also roam across machines.


Something already exists but it isn't utilised properly and might need further tweaking. The knows and persists what kernel was used most recently for what . Maybe it's enough to make more brave kernel selections based on that information


When I press Ctrl+Shift+P to open the command panel and type "", it shows "No matching commands". So I can't execute this command by Ctrl+Shift+P. I can only bind a shortcut key to this command and then execute it via the shortcut key. I think this is a bug that the command panel search is incomplete.
Please edit this issue title to become:
indicates it may already be there and you just need to know what the command text is.
OK, but according to my observation, there are other commands that cannot be found in the panel. For example, "".
The issue I raised is different from him. His issue is that the shortcut key does not work after binding. My issue is that I can't find the command in the command panel. In fact, some other commands cannot be found, indicating that the search of the command panel is incomplete.
Some commands never appear in the Command Palette because they define their clause as
I open the page where I set the keyboard shortcut and see that their when clause is - not false.
Sorry, I wasn't clear. This is what I am referring to.
I read your link and I probably understand. Please set the when clause of "" to "inDebugMode" instead of false. This is more in line with our needs.
Looks like that command is missing from here: is also missing.
/confirm
I will submit a PR
Thanks!


In the following dialog that appears: <img width="696" alt="image" src="https://user-"in and opening a protocol url, the 'Install VS Code Insiders' button should route to a new link for installing insiders specifically rather than just Install VS Code Insiders should not dismiss the dialog, so that the user can return and try again cc
likely a separate issue: Was not sure how this modal was arrived at, so I clicked the remote indicator and I only saw an option to download VS Code - not Insider's as I'd expect. !
I then did the flow and saw the dialogue. Clicking on the button took me to the Insider's download correctly. !


Open some See that it's in the "Open Recent..." list Close vscode Delete that code-workspace Open vscode Use Open Recent to select that deleted workspace Get a message that doesn't exist anymore See Open Recent again - the workspace is still in that list If I follow the same steps with a folder instead of a workspace, then the folder is removed from the list as I'd expect.
I cannot reproduce, tried with insiders on macOS. Here is what I did: open a workspace saved it as another workspace on my desktop closed vscode deleted that workspace opened vscode (opens empty) try to open that deleted workspace via file open recent dismiss the dialog try to find the entry again =it is gone Since this involves a menu update, could it be that you opened the menu too fast for the menu to update? I think the current delay is like 800ms?
Interesting, I am using the "File: Open Recent..." command. When I use that, it isn't removed from the list, but when I use the File Open Recent menu, it is removed.
I can reproduce and it seems to be a regression from the work to support URIs on the main side. The flow is: opening the workspace fails and we call remove from recently opened () since we pass over a URI we think this is a single folder workspace (which it is not) and fail to remove it moving to (cc
This was the change from adopting URIs for files.


I wanted to copy this command to a diff't window and see how the selection didn't work so well https://user- Since we know where the prompt ends, could we do something about this? If not, should we have a copy command action?
Double click is all driven by the links system which works pretty well generally, adding prompt knowledge in there would be a bit of a mess and need some more APIs to override specific cell double-click selection handling since links live in but shell integration is all in vscode. The way I do this is to double click and drag it to the right a bit. I'd say this is out of scope but we can talk about it more if you want.
Yeah I thought abt the complications with the existing link/selection code and decided that would be too much. I wonder if we should have a copy command action though?
Sure we could do that, it would also be good to get some more order to this: ! Proposal: Rerun Command Copy Command - Copy Output Copy Output as HTML - How does this work?
Verified. Looks like the proposal to me. <img width="277" alt="image" src="https://user-"


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- 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: Steps to Reproduce: the extension in VS Code and run the "Run Extension" task from the "Run and Debug" panel a new untitled file and change the language to "HTML" the command or start typing "example" to reveal the "example" completion items that one of the completion items has a red block and one does not Expected Behaviour: Both completion items should display a red block. Suggested Fix: When the color extractor checks the property it should account for values: For example the piece of code above could be changed to the following:


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


Issue Type: <bBug</bPerform a search In the results panel, right-click a filename Select 'Reveal in Explorer' File is highlighted in the 'Files' side panel. VS Code version: Code 1.39.2 (, 2019-10-15T15:35:18.241Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ Bookmarks10.5.0 cucumberautocomplete2.14.1 vscode-svgviewer2.0.0 vscode-markdownlint0.31.1 vscode-eslint1.9.1 vscode-scss-formatter1.4.2 perforce3.2.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
what you refer to as "the 'Files' side panel" is called Explorer. So the current behaviour of 'Reveal in Explorer' from a filename in Search results makes sense. But I can see it's confusing because when you then right-click on the filename that's been revealed in VS Code's Explorer, you get another 'Reveal in Explorer', and that one opens a Windows Explorer onto the folder containing the file and highlights the file. I guess on macOS the equivalent context menu will say 'Reveal in Finder'.
Exactly.
So maybe the option in the Search side bar's context menu should be recaptioned 'Reveal in Explorer Side Bar' (1 change): Alternatively, make the Explorer side bar context menu on Windows use the caption 'Reveal in Windows Explorer' (3 changes):
fyi
I'm still on Windows, I right-click the tab of an open file, and it offers and .
on my 1.39.2 on Windows the context menu from a file tab captions the options "Reveal in Explorer" and "Reveal in Side Bar" (not "Open in ..." as you wrote). So for consistency I think the context menu from the filename on the Search list should be changed on this line to become
Fair enough. My point, though, was obviously regarding the inconsistency in numerology across the application.
We talked about this at the time. The thing is, "Explorer" is used in a bunch of places to refer to the file explorer in vscode and it doesn't seem like a big deal to me.


However I realized that there is precedent for referring to it as "Side bar", the command "File: Reveal active file in side bar". I think that's kind of imprecise and also you are already looking at the search results in the side bar, so it doesn't make sense to "reveal in side bar" again. But anyway, I don't have a strong opinion.
We have been using the term "side bar" exactly for this reason: to have a way to distinguish between the Windows Explorer and the explorer in VSCode. We could in theory refer to it as "Explorer View", but that may cause frustration when users search for "reveal explorer" and find 2 results. I think no matter what we do, both commands should have a similar label. I don't think there is an issue calling the command in the search results "Reveal in Side Bar".
That'd be nice and clear.
are you willing to take my PR for this? It failed CI on windows and darwin but as far as I can tell that wasn't caused by anything in my PR itself.


[ ] Notebooks (.ipynb files) [X] Interactive Window and/or Cell Scripts (.py files with #%% markers) When rendering large output, I now get the option to at the bottom of the output in addition to the previous "text editor" view. However, when selecting this option, the full output is not rendered in the scrollable element. Instead, the ellipsis shown in the truncated view remain. The expected outcome would be that the content shown in the scrollable element would be the full output, not the truncated output. When changing the setting , the scrollable element is displayed immediately and shows the content as expected. To reproduce: Initial output: ! Output after clicking : ! Output when setting : ! 78.2 v2023.4. Python v3.8.13 No response No response Local


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.60.0 OS Version: MacOS 10.14.3 Steps to Reproduce: & paste into markdown file <kbd⌘</kbdand click the link .ext)
This is my first go at launching into the vscode code, but hopefully this information may be useful. Perhaps we could update the parsing of the URI schemes in general to strip out the angle brackets when editing markdown? See my findings below for why I'm suggesting this, but I'm also unsure of what problems and side effects doing that may cause. Main points of interest While the Command + Click doesn't follow the web link when you're a Markdown file, it does follow the link in the of the Markdown file. So I think markdown syntax is actually ok In debugging the project a little bit, I found that the link you try to follow that has angle brackets may be trying to or something similar (instead of open a web browser) In the function , I think the scheme of http(s) isn't recognized because of the < brackets in the link portion. See around line 18, where it tries to recognize the scheme, but doesn't recognize it when it tries calling In the file you can add a few new schemes, and then you're able to follow the link just fine. Though, this is probably not the final way the issue should be fixed


Looks like a one time fluke, given 30d statistics and 5000+ runs pass rate. <img width="1357" alt="image" src=""


to search, then click the that expands the results. :bug: does not expand. Looking into this more, it is because the call for the node isn't working.
I've also seen the same thing with not working. Unsure if this is related, but the repro is the same, but between step 2 and 3, expand the AI results.
This seems to also happen in when in tree mode.
It could be very expensive if expand all would actually expand all tree nodes in an async data tree. It's possible to have infinite deep async trees so in those cases this method would crash. My recommendation would be to create your own implementation for this in the search view. If that does not work the way you would like it to, we could consider alternatives. I think the bulk edit pane has a similar behaviour here:


This: Now results in 1/2 the minimum contrast requirements which is a soft accessibility issue. It seems like these messages are special vscode messages which use special formatting in the real terminal:


There's no separator line between the two components. !
Seeing the seperator: <img width="69" alt="image" src=""


over the last week I have seen zombie processes running at full CPU load when trying to debug them (via SIGUSR1) they die analysed a crash dump and sees that this is because the EH is already in the process of shutting down the previous point matches the observation that no window reports its EH as having crashed <img width="1290" alt="Screenshot 2023-09-29 at 13 31 34" src=""
Can you take a process sample from the OS activity monitor, I hope the native stack can give a clue to what is happening.
Just happening. This is the command line of such an EH
This the process sample
Not sure about the part. Does this mean we run the EH under development or not?
It looks like we set that for all local EH process launches. Just having inspect-port doesn't put the process in debug mode. What you can do is use the "Debug: Attach to Process" command and select that process. This will fail, since the debugger won't then know what port it's listening on (if --inspect-port isn't given in the args, it always listens on 9229, and js-debug assumes that is what happens). But, then you can . AFter doing so you could grab a performance profile using the edge/chrome devtools on edge://inspect, or by attaching to that using an attach-type launch config VS Code and using the "take performance profile" command -- if the spin sample you recorded above isn't enough for Deepak to figure out what's going on.
Does that use SIGUSR1? Asking cos I have tried that first and sending the signal kills the process. From the crash dumps we do know that the process already was shutting down
Attaching the symbolicated sample Going from the top, indicates the EH process is already in the shutdown phase and has started to destroy the . At this point, connecting via a debugger is not possible since the agent host will stop receiving connections due to the following , so we cannot get perf profile from these processes. Moving further down most of the sample time is spent in which the environment gets deleted, this flushes the pending tasks in the libuv event loop but one thing to note is that entering JS via these tasks is not allowed due to the . But there are GC tasks being executed and which can enter JS.


I think the error calls ` are from these callsites eventually leading to . At this point, I expect the process to abort and the main process should be able to reap the utility process but that is not happening. There is another data point looking back at the screenshot from , the zombie EH processes are titled and not in the process explorer. We resolve the pids to respective titles based on a map maintained in the main process, the process explorer gets it periodically via the following and the utility process related values are populated from . We default to when the pid map no longer has an entry for the process which can only happen when got invoked which inturn suggests that the main process did receive an exit or crash signal from these EH hosts. can you check the main process logs next time if it has any of the following entries for the corresponding zombie EH pid to validate this data
I attempted to setup a similar flow based on the stack with base Electron app but the utility process are cleaned up as expected. I can make a change in the destruction phase of the utility process to signal termination of isolate so that tasks which require to enter JS will not do so and I hope that resolves the long running draintask. I won't be able to make a new insiders build with this change until I am back from vacation but I can provide a custom electron build for local testing with OSS. would that help to validate incase you face similar issue with OSS as well ?
Ah, my bad, skimmed over that part. Disregard. (Yes, it sends SIGUSR1 on unix)
I am seeing this for which is currently spinning forever. Samples for this one
i think i have the same issue on my mac. It happens from time to time and my workaround is simply killing vscode and then reopen it. But sometimes i don't realize it until my Mac has run out of battery, which can be quite annoying. <img width="963" alt="CleanShot 2023-10-09 at 19 46 49 src=""!
Having the exact same issue. utility-process is running at 100% all the time on M1 Max, very annoying.
This bug might also exist in Linux build of vscode: ! (6% 16 cores = 96%) Command line of "utility-process" is: eu-stack of main thread of this process: Noticed that is also inside sampling.


Manually sampling with eu-stack running every second, for one minute. (And might related to and )
Sorry if I'm hijacking the thread but would uninstalling Node and installing Bun solve this problem? Doesn't sound like it's a VSCode bug, right?
Thanks for the logs , the stack does look related. I wouldn't be surprised if the issue is also present on Linux since the shutdown path is same for both.
Similar issue on my M1 Max, sometimes I observe even 3/4 zombie processes running in the background and have to kill them manually from process manager to stop them from draining battery. 2 more samples for such process:
Checked log and it looks weird. : However, PID still exists and is running at 100%.
Another hang process today with log: "Extension host with pid started" "Extension host with pid exiting with code 0" "Extension host with pid exited with code: 0, signal: unknown."
Is there any temp workaround? any script or bash command that we can run to identify and kill those pid? I am interested to do it manually, because i have a M2 and i am rebooting my macbook after some hours because get soooo slow
Restarting VS Code should already "fix" the problem because the extension host is a child process of the application. At least that does the job for me. Are you observing a different behavior? Note that "Reload Window" does not kill the zombie process (according to my observation).
Please help by posting the list of installed extensions. I am looking for similarities between our setups as this is possibly caused by an extension. This is my list To get this list run or . Please do the same and post your results here. Thanks
Thanks for looking into this! I am also facing this issue quite frequently. Here are my installed extensions:
Thanks everyone. Looks like the intersection is
code --list-extensions
Yep, I'm using those extensions too. Here's the full list:
is not a very good workaround: what if the process exits, but another innocent process just takes this PID?
It probably cannot do that as the pid is still taken? I agree it's not a great workaround, but until the root cause is clear it does solve the issue where a cpu is occupied.


off the hot exit and auto save settings an interactive window, run a cell vscode :bug: confirmation pop-up to save the IW


Type: <bBug</bIn previous VS Code version 1.78 when I pressed if inline suggest was visible with suggest widget it hides only inline suggest, if I press again same shortcut it then hides suggest widget. Now with 1.79 it hides both inline suggest and suggest widget. KeybindingService logs: My custom shortcuts to hide inline suggest & suggest widget: I even tried to add to clause and still it hides both. VS Code version: Code 1.79.0 (, 2023-06-07T14:31:03.317Z) OS version: Darwin arm64 22.5.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (12)</summaryExtensionVersion ------ vscode-eslint2.4.0 gitlens13.6.0 prettier-vscode9.13.0 copilot1.88.132 vscode-graphql0.8.13 vscode-graphql-syntax1.2.0 symbols0.0.11 vscode-react-native1.11.0 vscode-thunder-client2.7.6 vscode-fileutils3.10.1 vim1.25.2 quokka-vscode1.0.543 (1 theme extensions excluded) </details<!-- generated by issue reporter --
full text search doesn't reveal the context key anymore. Has that been removed/renamed?
It is
sorry I was writing that instead of copy-pasting. Already updated the issue.
Does it work when you swap the keybinding configurations? (Like literally exchange the positions in the file)
Still the same issue even if I swap places :(
So, its either the or context key. Can you investigate with the F1 Inspect Context Key Tools to see if those context keys are set. Note that it will print context keys on the console of DevTools
<details<summaryContext keys</summary</details
as you can see is and is , but even though inline suggest was visible it returned false.
Same in the monaco, if the suggest widget is visible, the inlineSuggestWidgetVisible will always be false no matter there is any ghost text or not
<!-- 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!
Now I see us hiding the suggest widget first and the inline suggest second, is that expected? This is true regardless of what order I declare the keybindings in (I do have the Vim extension installed)
It should hide first inline suggestions and second time you press it, it should hide suggest widget. Try to swap places of keybindings to see if it fixes it (order maybe matters?). Because previously this is how it worked (in 1.78, but regression was introduced in 1.79). EDIT: Oh I see you mentioned that order doesn't matter. Try to add in clause for command (I hope it works).
is it fixed for you on the latest insider builds The following does not work for me either
It works! !
Great, thanks for confirming!


VSCode freeze on mouse wheel scrolling with lot of tests: open test explorer, ! right-click on the test button scroll tests with mouse wheel at least twice VS Code version: Code - Insiders 1.64.0-insider (, 2021-12-22T05:15:27.690Z) OS version: Linux x64 5.4.0-92-generic Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (20)</summaryExtensionVersion ------ vscode-eslint2.2.2 gitlens-insiders2021.12.2804 EditorConfig0.16.4 prettier-vscode9.0.0 themeswitch1.0.5 rpm-spec0.3.2 vscode-docker1.18.0 python2022.0.-dev vscode-pylance2021.12.3-pre.1 jupyter2022.1. jupyter-keymap1.0.0 jupyter-renderers1.0.4 remote-containers0.209.6 remote-ssh0.70.0 remote-ssh-edit0.70.0 code-stats-vscode1.0.18 code-spell-checker2.0.14 code-spell-checker-russian2.0.2 cron-explained1.3.1 material-theme3.13.8 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Looks like doesn't help.
Thanks (again) for the issue!


Reminded of this by We currently have a context key (when clause) for the run menu (in the main menu). This means we don't know if the menu should be displayed on startup because it depends on extensions. The Terminal menu also has a context key but resolves very quickly so there is no delay. Should we remove both of these when clauses in favor of keeping them around with possibly disabled menu items. E.g. The "Install additional debuggers" entry should still be shown in the run menu if no current contexts are available.
Assigning to who now owns the Debug UI. Rob let me know if I can help here.
Which menu are you talking about? How is the context menu involved?
Context Menu should have been Context Key. Sorry about that, I'll edit the original post.
Looks like has decided to go this route with the Terminal menu, so I think we should align here too.
So the terminal menu will be shown all the time in web? That's what will happen with Run. I guess it will show "Install additional debuggers" And should other items be disabled or missing? They currently use so are missing. It would look like this <img width="245" alt="image" src="https://user-"I'm fine with that if it's consistent. Sort of gives false hope about what you're going to find, though
Actually, if the Run menu doesn't have a when clause, but all the subitems do and it is false, then the Run menu still doesn't show up. Would that be ok or is that still slow?
Won't install additional debuggers always be visible?
It currently has a when clause to only show up when other debuggers are present, it would only show up if I remove that. And I think "install additional debuggers" usually won't give the user what they want.
I see that entry as a way for users to discover how to get our web-based code execution extensions like Python. Maybe the text is not right? We could even have a web specific entry that filters the extension list to web-supported debuggers instead of all?
Yeah, I think that when those exist we should think about what the onramp looks like. For now I'll remove the when clause on the Run menu if you think that's the right thing to do.


sounds good, thank you
Ok, this actually isn't working the way I thought it did, and the result is that the Run menu never shows, at all. I must have tested it wrong, maybe you have to restart vscode for native menu changes to take full effect? The current state is that the Run menu has no when clause, and every command inside the menu does have a when clause. But the result seems to be: If the menu doesn't have a when clause, but initially doesn't have any enabled commands inside it, then it doesn't appear and will never appear, even if the commands inside it later get their when clauses flipped to true. The only way to get it to conditionally appear is to add a when clause to the menu itself. Does that sound like a menu bug But also I can just go back to having "Install additional debuggers" enabled all the time, I think that's fine.
that very well could be a menu bug. but thinking about it, I think having the one item always in the menu is necessary because otherwise we still result in the behavior where we don't know for some time on startup whether to show the menu or not which causes flickering.
is it expected that all of these items in the run menu are active in web? <img width="163" alt="image" src="https://user-"
You probably have some extension enabled for web which claims it can debug
Mock Debug and Python, thanks


Testing microsoft/vscode-python Following the steps, I first used the auto-generated launch configuration. This meant that it didn't exist in the I then repeated the steps by clicking the gear to create it in the the dropdown now has 2 entries with duplicate titles. I would expect that the non-file-backed configuration just disappears now that we use a Not sure if this is extension specific or the responsibility of core.
How did you trigger second time to get the dynamic one? after creating the After, , i don't see the debug welcome screen.
Using one of these methods
Thanks for the bug report. VSCode handles the auto debug configuration behavior, so I'll transfer the issue to their repository.
This still repros: ! Steps: with no file open, show all automatic: ! python -Get expected error: ! one shows up... great... now pick : ! hit the on : ! See two: !
Additionally... maybe a different issue, I noticed that if I do this: with no file open, show all automatic: ! python -Get expected error: ! one shows up... great... now pick : ! Hit to get rid of the quick pick: ! is still selected in the ! and the only way to get back to the Picker I escaped out of is to choose a different launch config in the drop down and then select again. Seems a bit odd. I would have expected the play button to give me the picker or selecting even if it's already chosen to re-trigger the picker.
I fixed a different issue... I removed the duplicate from the quick pick, but not from the debug sidebar dropdown. Same data source, I think the dropdown just needs something else to refresh it.
Handling these dynamic configs is tricky - the way they are represented, they look mostly the same as a real launch config with the same name, and there is probably another case where we fail to tell the difference
Following the steps, I now get 2 different titles but still very similar. Not sure if this is breaking any checks that you do <img width="212" alt="image" src="https://user-"
How did you get without the ? I tried again and don't see that.


Is that the name in your I have and <img width="173" alt="image" src="https://user-"and I'm not sure how to get a different name in the saved config.
That is what was generated in my launch config, yes, I did not create it manually. I am on Windows.
I can't repro it. If you want, you can show me. But, if this happens somehow, I don't think I can improve the situation anyway, because two configs with different names are just two different configs.
I still managed to repro using SteVen's original steps in this issue <img width="248" alt="image" src="https://user-"
I can't repro the issue, are you sure you didn't end up with duplicate entries in If not can you open the quick access for and share a screenshot? Or just call me sometime so I can try?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!


<!-- Do you have a question? Please ask it on For bug reports, please fill in the details below. For feature requests, please describe the desired feature. --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.23.1 OS Version: Windows 10 Enterprise Ver.1703 build .877 Im trying action. but, this action working only absolute path. is working code (absolute path) ex: - Emmet: Update Image size -not working code (root relative path) ex: - Emmet: Update Image size -its not working... <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No
Thanks for reporting PRs are welcome to fix this issue. The code behind this feature is at
Hi, I'm interested in this bug. I noticed the person filing the bug gives as a example of a working path. I believe that path means that in the current working directory there should be folder called that has another folder named which has photo in it. However, is given as an example of the command not working. It is true that this path doesn't work but I believe that is intentional. at the beginning means it starts at the root and because of that it may be looking for in a different spot in the directory. For example, if my absolute path to a image is like this: and the location to the html file being editing is in here: I can't run the command with this code: But I can run it on this: and this: Hopefully this information is useful.
Thanks for the detailed analysis I can confirm your findings. Can you share what your folder structure is? Unless folder is directly under root, we cannot expect the command to work on Also see
thx comments. I can be submitted sample folder structure. Sample folder structure is working code of path: is not working code of path but, code is Ctrl + LClick (img Preview) is working. because I think passed root path of VSCode.
Are you on Windows, Linux or Mac?
Windows
Ctrl+Click will navigate to the image file in the first 2 cases as expected in both Mac and Windows The works on all 3 cases in Mac, but only the first case in Windows. So, at the very least, we can look into if we can get the second case working to keep the experience consistent between the Ctrl+Click and the Emmet experience


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.74.2 OS Version: Ubuntu 22.04 LTS (with all updates applied) Steps to Reproduce: in using a Active Directory account (Ubuntu must be joined into an Active Directory Domain) Visual Studio Code Terminal tab, click on [ + ] sign to open a new terminal, choosing zsh. A empty terminal tab opens and no shell is launched When I look in Output tab, section 'Shared', the following log lines were found By looking at message, it seems vscode is looking at /etc/passwd for some reason. And it may be failing because when I log in with an Active Directory account, no /etc/passwd entry is created for my user, because sssd/realm does not write entries on that. I opened a terminal Window and grab the following output for helping debugging:
Looks like we need to try catch here:
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Verified by code review (but would still appreciate your
I confirmed now that it´s working as expected. Nice job from team! <img width="1009" alt="image" src="https://user-"


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- 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.7.2 OS Version: windows Steps to Reproduce: a file with error on `cue: line has an error" settings the cursor to there
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.73.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
it still occurs with 1.73.1
yeah I can reproduce this issue. is this expected?
This is not expected. Sounds should be played when cursor is navigated to the error line. worked on this initially and might have more details
I also have the same problem, but this only occurs in the insider version, I have the latest version and no sound is played Issue:
They play in OSS, but not insider's. any idea why that would be?
if that is the case then it is probably related to code bundling. Does that sound play when you F1 list audio cues?
It does play when I list audio cues in both OSS and insider's.
It also plays for terminal quick fixes - suggesting there's a bug in because I can also repro it not playing for other line feature types
This has been working for me lately, though it was definitely broken at one pt.
I have set to I navigate to a line with an error-squiggle but there is no sound being played


Issue Type: <bFeature Request</bI never used the "Contributions" tab in extensions, thinking it was for recent github contributions to the extension. I accidentially pressed it once, and found it very useful. I think the name "Contributions" is confusing and that "Details", "Internals" , "Technical Details", or something similar would make it much clearer. VS Code version: Code 1.41.1 (, 2019-12-18T15:04:31.999Z) OS version: Linux x64 5.4.14-200.fc31.x86_64 <!-- generated by issue reporter --
These are in fact contributions to VS Code. How about ?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!


It is possible with VSCode to follow a path printed in the terminal. When that path also contains the line and column number in the format ( ≙ line number; ≙ column number), VSCode currently doesn't interpret it completely and therefore doesn't also jump to the line/column in the opened file. Example: ` This path format indicates the path to the file but also the line (49) and column (46) number. Ctrl + clicking this path currently in VSCode will open the file but not jump to the line or the column. As this format is used by many linters and compilers (e.g. SASS), it would be a very useful and time-saving feature.
Code link: I think here we'd want to require the exact (num)(colon)(num) to prevent problems with (link) (number) (text)
nice feature for many front end build tools.
I PR for this.


When updating cell metadata for a cell, users call which provides a function to alter the metadata of a cell. This uses defined in . When is called, the CellEditType is marked as , resulting in the metadata of the cell only being updated with the passed in data, rather than fully replaced. This makes it difficult to determine how to remove fields from a cell's metadata, a change needed for fixing . This can be worked around in this situation by setting the field to null. However, if a user calls , it appears that the functionality is a full replacement of initial metadata. There is a slight inconsistency here between the functionality of the two functions. Couple initial ideas: better document to reflect the behavior of . Add in a line stating that this is an iterative change, only altering the fields passed into this function - revise the functionality of either updateCell or updateNotebook metadata functions to align their behavior. This seems dangerous as it could likely break features leveraging this api. deprecate these functions, and rewrite two new ones with clearer functionality and documentation, based on updated needs from the notebook and jupyter teams
Analyzed all extensions using this API and most of them are already doing the right thing: clone the existing metadata, apply the change, and then call the API to update. However there are a few extensions didn't do so: there is one place where the metadata is not updated properly: PR . cc
<!-- 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!
what is the best way to verify this?
It's a bit complex I would love either or to help verify.


<!-- 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. --The [NPM support for VS Code built-in extension][extension] (which automatically detects NPM scripts and provides a UI to run them in the sidebar) has an settting. Currently, this setting only supports the options or . This means it won't work with the [pnpm package manager][pnpm]. Adding a option would be really helpful to users who use pnpm rather than npm or yarn. Both [vscode-eslint][] and [typescript-tslint-plugin][] also already support using pnpm as the preferred Node package manager. I personally use pnpm because its reduced disk space/bandwidth footprint and its architecture both work better for me. I've experimented with just overwriting the value in with , and ignoring the warning from the linter. This seems to work (on macOS), so I'm guessing it might be as simple as adding to the array here: I just don't understand the extensions well enough to be sure that's correct / enough to properly add pnpm. [extension]: [pnpm]: [vscode-eslint]: [typescript-tslint-plugin]: [source]:


uses quick chat and has found that going between the input and the response is cumbersome because of our underlying list structure. This is in particular an issue because we now have many hyperlinked tab stops. ! We should provide a way to go between the input and the focused response. AFAICT, there is not a way to do this. Pressing seems to focus the input (unexpectedly), but there's no way to get back to the response. Thoughts?
Makes sense. Probably just need to handle the keybindings better
these probably just need logic for QC
Tyler figured out that there is a way to do this, but it's in the reverse direction from what one might expect based on tab order. Use to focus the input and to focus the last response.
Talked to JooYoung and it's fine to have these reversed, we'll want to be sure that using doesn't still focus the input box.
working afaict - and for response -input and vice versa, tab works fine as well


insiders, install remote SSH extension the Remote view container all the views via context menu menu on the title -the views are not there and they can not be brought back -the views are back -I would expect the hidden state to be preserved fyi !
Assigning to as remote viewlet has special treatment.
Original decision was that none of the views in the filter-view should be hide-able. Looks like I missed a spot!


Broken due to refactorings of the workbench CSS. Fix is simple (CSS only change).


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.44.1 OS Version: Linux 5.6.4-arch1-1 SMP PREEMPT x86_64 GNU/Linux Steps to Reproduce: a symbolic link to the VSCode starting script with a space in the name. For example: "My VSCode" from the terminal Error is printed to the terminal: All in the starting script () should be enclosed in double quotes to avoid this error. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
I can take this!
great!


<!-- 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: Latest OS Version: Browser Steps to Reproduce: 'Cancel while enumerating through children' test case up above 'Root element should return children' (or use a test runner which randomized order. the test and notice that it fails. Notice how other variables in the same test use the method to make the test cases independent of each other.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: OS Version: Steps to Reproduce: Jupyter extension all cells Ctrl+Z in a cell icon in toolbar changes to No way to recover from this. Similar to However this reverts the Notebook Metadata (instead of cell metadata). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.542 --- <!-- score: 0.483 --<!-- potentialduplicatescomment --
Validated, works now, closing this issue


Testing a file +enter to run cell in interactive window window GitHub Copilot classic installed and signed in something into the input box and ctrl+enter, this opens a third editor group with multiple synthesized Copilot solutions (feature from GitHub Copilot) close that editor :bug: now there is an empty third editor group which really shouldn't happen AFAIK, also there is screen cheese, it shouldn't really be possible for Copilot to cause this kind of layout issue <img width="1256" alt="image" src=""<img width="1245" alt="image" src=""
I assigned you for grid layout and I assigned you for editor layout, please feel free to unassign if this isn't relevant to you
empty editor groups are not a bug per-se, if you configure , groups will remain open when the last editor closes. Also, empty groups can explicitly be created, e.g. via . However, the fact that you cannot get rid of the empty group when you press the X button sounds like an issue to me. When you try to close, is there anything printed to the console?
Ohhhhhhhhhhh good bug! There is definitely splitview/gridview breakage here.
Wait. I could repro once... but not anymore. Can you still repro?
Yes I reproed twice
I cannot see anything in logs when clicking on the X unfortunately (fwiw, I do not have that setting configured) When I repro this, here's what's in the log (this happens right after closing the last editor in a group that results in the group not also being closed)
I wonder if this could possibly be a regression from the auto-sizing feature you did?
We just need to be able to repro on demand so we can attempt to repro on a version before my changes to confirm this. But I can't seem to repro no more. Can you ?
I cannot reproduce this, I never get an empty editor group. This is with fresh user data dir and extensions dir.
if you have a reliable repro that you can share, including your settings if any. Here is what I do: !
I did some more messing around and was able to repro a similar problem ! <details</details
OK, I have a trivial and consistent repro. TLDR it looks like the interactive window does not play nice with split view.


an interactive window (you can even do this with the Jupyter: Create Interactive Window command) the Settings UI the Settings UI onto the right of the interactive window :bug: the split view is very unhappy Logs <details</details
This also repros for notebooks opened in the second group Right click a .ipynb file -open to the side open another editor and drag it to the right side of the first
Oh wow. So it looks like the call to throws an exception when done in the interactive window and that means the Grid will indeed be unhappy!
for surrounding some of the calls with .
Arguably, the grid/splitview should also protect itself...
Yeah, maybe. There could be other cases.
I can't repro any of these now but it would probably help for to verify too
I still do not have a functional cursor/trackpad so cannot drag/drop maybe you can verify?
Verified it's working great


<!-- 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 (all extensions other than the reproduction extension) <!-- 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.2 OS Version: macOS 12.5.1 Over at the Tailwind CSS IntelliSense repo we are seeing multiple reports of issues with colour decorators since the release of v1.78. Some are related to the new setting which I think is a separate issue, but we are also seeing an issue where document colour requests are not being sent to the language server at all ( is in this case). I was able to create a small reproduction based on the LSP extension sample. Please see below. Steps to Reproduce: instructions from reproduction readme: When the same project is opened in v1.76.2, the count is logged repeatedly when editing the document.
Thanks a lot for the great steps to reproduce. I pushed a fix for the issue.


VS Code does not report errors in , and then silently drops the ball without telling the user. This is particularly annoying since some things might continue working, while others mysteriously stop. Errors in come in two flavours – actual syntactical errors, but also unrecognized new properties. In particular the latter is annoying, for example when TypeScript adds new features such as (see ). My suggestion would be to at least visibly and loudly report this, but preferably be more lenient about what's accepted (e.g. unrecognized properties).
FYI
+1 I had a similar issue (non existing compiler option) and I didn't get why my configured target=es6 got not accepted. Interestingly, it worked when compiling over command line but it failed when compiling over tsserver. See also the TS compiler code. Maybe one could get that error from tsserver back to VS code?
+1 I've just had a similar issue that I've spent 3 hours working through. Adding a new typescript 2 option such as "noUnusedParameters" caused vscode to reference not , making some of my code have errors in the editor, but not when built! I've worked around by having a different that I used for building with.
See


Does this issue occur when all extensions are disabled?: Yes Version: 1.77.0-insider (Universal) Commit: Date: 2023-03-17T21:00:47.582Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin arm64 20.6.0 Sandboxed: Yes Steps to Reproduce: Execute the following extension example: a text file and select a completion item , type , and select a completion item results are different https://user-
This is specific to additional edits that are after and on the same line as the suggestion. The newly typed characters (type after return the list of item and before selecting one) aren't taken into account


a notebook cell that will create a long stacktrace :bug: "Output exceeds the size limit" message is shown on a non-scrollable element


<!-- 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.73.1 OS Version: macOS 13.0.1 Steps to Reproduce: a VS Code Remote SSH session a .hbs file selected language at the bottom right is "Plain Text" and when clicking it, Handlebars is not available in the list
The extension thinks it needs to be installed on the SSH remote: ! On it's own the handlebars extension doesn't need to be installed on the SSH remote, but the HTML languages features extension appears to be pulling it in with . It seems like this is related to The problem is easily fixed by adding this to handlebars: But that might break
Nice! Thanks for figuring this out! I initially believed this was a feature request to add a builtin handlebars grammar.
The handlebars could run on the renderer, but because it defines it is deduced to run on workspace. If were an internal contribution point, we could define a , but we don't have a way for contributions to declare a contribution point (a contribution contribution) So these are the possible solutions "extensionKind": "ui", "workspace"] as suggests as it overwrites the detected extension kinds Implement a contribution contribution point include the extension also in the server build I go with the first one for now. speak up if you disagree


Testing a notebook with some content the replace widget to replace an existing string enter while focused in the replace box no effect, string should be replaced as it does in a text editor
It's a bad bug, but fixing it is not trivial. Considering it's not regression, I'll fix it next week.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.93.0-insider Commit: Date: 2024-08-29T05:04:03.909Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Linux x64 6.9.3--generic Steps to Reproduce: a few editor groups in seemingly any split configuration one for text input or otherwise run to type: no result, as no editor has focus any more. This is especially frustrating when some of your other keyboard shortcuts rely on the editorFocus context, as they become unusable after using this feature.
In case this takes a while to fix, anyone looking for a workaround can rebind their preferred shortcut to automatically refocus the editor and then "move" the cursor to ensure if another window has now covered your cursor, the editor scrolls to reveal it again (also respecting scrolloff setting).
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


I see this when starting the panel chat voice action in dev tools. An easy way to know when this reproduces is to enable the audio cue, which then plays forever.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --- 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. --- Microsoft Windows 11 Pro 10.0. N/A Build Not sure if this is intended behavior or not but I think if I use the button it should create and show the repository. If is set to , the repository is actually created but nothing is shown in VsCode I understand that this option is for auto-detect and it's kind of logical, but should it affect the action? !
thank you very much for filing this issue. Setting to disables repository detection independent whether it already exists or it has been created using VS Code. While this is the intended behaviour, I agree that we could probably make this experience better.


<!-- 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.81.0 OS Version: Windows_NT x64 10.0. Steps to Reproduce: In , set the content to then start VS Code with shell integration enabled and use Windows PowerShell. This bug will occur: The use of at: Needs to be guarded for Windows PowerShell (where it doesn't exist). /cc
Sharing from my profile:


Testing I suspect results are not in right order <img width="1198" alt="image" src="https://user-"Output result is shown first


was broken for some time and I re-enabled it today. However eslint failures were reported in and I disabled them. I also moved the file into a test folder to avoid some other hygine failures. Please have a look and decide a proper place for the file and fix the corresponding errors.


From We should add some clarifying comments to this parameter. It should be quite similar to that of , since the quickpick assumes the highlighting and fuzzy matching of the matches.
adds a description, which will probably get cleaned up once we start cleaning up the APIs more.


Issue Type: <bBug</bAfter updating to 1.43.0, when VSCode relaunched, it brought up around 80 editor windows from old projects I hadn't opened in quite some time. (spooky workspace necromancy) Perhaps obviously this made my computer behave quite poorly. I tried adding "window.restoreWindows": "none" to my with another text editor, but it didn't seem to be respected (might be my fault somehow). Note that it had been on "folders" previously, in case that helps. I also tried to muck about with file. VSCode seemed to ignore my changes to it (probably not a bug -- I was desparate and dunno how this file works), but I do have a backup of a from right after this happened. It shows all the windows it will try to open when launching, and maybe other stuff. I guess the system info probably has more PII anyway. I dunno how much this helps but: I think the main common feature of the workspaces it resurrected seemed to be that they had open files with unsaved changes -- but these are also the ones which can't be closed without additional UI confirmation, and I did try a couple things to close all windows in bulk (none seemed to work, but maybe I just didn't notice?) Relaunching without extensions also didn't help, but that doesn't mean this wasn't caused by an extension in the first place or somethign. I have more than is probably reasonable installed. That said, it happening immediately after updating to 1.43.0 makes me think it's vscode and not an extension. Anyway, ultimately I just bit the bullet and closed them manually -- VSCode would be usable for about 20 seconds after starting, during which time I could close a few before too many were restored and everything got too slow. So i just did this, quit, and repeated many times until there were no more left (this actually took a couple goes -- even when I'd get down to none left, save, and reopen, it would find some new ones to bring back... Guessing these just didn't make the cut for being restored the previous time, or something) P.S. it would be nice if there were a command line argument to launch without reopening anything. P.P.S.


In case it isn't clear: I've been using , , and somewhat interchangably here, just so you don't think I'm being precise about which I use when. VS Code version: Code 1.43.0 (, 2020-03-09T19:34:44.548Z) OS version: Darwin x64 18.7.0 <details<summarySystem Info</summary </details<details<summaryExtensions (55)</summaryExtensionVersion ------ code-gnu-global0.2.2 better-toml0.3.2 glsl-canvas0.2.8 bracket-pair-colorizer-20.0.29 dart-code3.8.1 xml2.5.0 scopes0.45.0 gitlens10.2.1 vscode-html-css0.2.3 tslint1.0.44 vsc-material-theme32.5.0 vsc-material-theme-icons1.1.4 prettier-vscode3.20.0 vscode-test-explorer2.17.0 vscode-peacock3.6.0 language-haskell2.7.0 center-editor-window2.3.0 chat0.31.0 restructuredtext120.0.0 fish-ide0.4.0 regionfolder1.0.8 Kotlin1.7.1 rust-analyzer0.1.


Lisp0.1.10 ninja-syntax1.0.0 prettify-json0.0.3 vscode-json51.0.0 vscode-docker1.0.0 csharp1.21.13 sublime-keybindings4.0.6 vscode-typescript-tslint-plugin1.2.3 vsliveshare1.0.1711 vsliveshare-audio0.1.80 vsliveshare-pack0.3.4 debugger-for-chrome4.12.6 idl0.3.1 autotrim1.0.6 proto0.0.2 material-icon-theme4.0.1 polacode0.3.4 tcl0.1.0 crates0.4.7 trailing-spaces0.3.1 vscode-scheme0.4.0 fish-vscode0.2.1 shader1.1.4 rewrap1.9.1 shellcheck0.9.0 org-mode0.5.0 cmake0.0.17 vscode-lldb1.5.0 vscode-icons10.0.0 material-theme3.2.3 vscode-open-in-github1.3.6 tslint-snippets1.1.0 (11 theme extensions excluded) </details<!-- generated by issue reporter --
FWIW this does seem to be respected now and I haven't changed anything, maybe indicating that it was being ignored for some reason during all this? Not sure if this is important, but worth noting I guess.
Hit the same issue here, VSCode opened up a few hundred projects after upgrading and my mac nearly fell over:
Yeah, I expected this to happen. Works now "correctly" after pushed This is expected hot exit behaviour to restore workspaces that have backed up files.
Hit this last night as well and it completely froze my machine up for minutes opening at least 40 windows. I get why this is an expected fix for a bug, but I it made my computer totally unresponsive and probably could have used a more progressive one-time rollout.
So it looks like this was a regression in 1.42 () and it's now fixed as it's designed. It's designed this way so that by default, backups don't go "missing" by accidentally closing window(s) and forgetting which one had your notes in it.


I can attest to the fact that it's awful when many windows unexpectedly restore as it happened to me when testing settings sync. I'm not sure what the right recovery fix is but you can workaround this in the meantime by setting in your . To go back you would need to either delete the backup files manually ( from the 's folder) or open the workspaces and close unsaved files.
Just to clarify, for anyone coming to this thread who's hosed with 40+ windows, it sounds like what you're saying is the workaround is set to so that we don't have to go through a ton of different "do you want to save this?" prompts when we try to close every window. set to (or another reasonable setting) so that VS Code doesn't try to open a ton of windows for every workspace with unsaved files. delete the unsaved buffers manually until things are bearable again. Is that the recommendation?
Is all I needed to stop the window tsunami.
if you just set you should be fine if you then open a new folder () and then close the window. This is actually how I've always used hot exit and recommend it if you haven't tried, it takes the rails off and was meant so that you can close windows arbitrarily even on macOS as well as not restoring all windows with backups whenever VS Code gets launched. If you want to go back to , deleting the buffers manually after reviewing is probably the best way to go.
I'm struggling to find a way to properly fix this for users without just changing the behavior something since this change in behavior looks to have been in . Maybe some restriction on the maximum number of windows that can be opened at once, with a dialog if it's over 5 or something? do you know what the behavior was before? seems to add folders to a the active workspace, does this mean all workspaces with folders were getting restored into a single window, or did they get dropped somehow?
I am quite sure we opened 1 window per backup directory with backups. So ended up always restoring every window that has backups. We decided with this approach to ensure we always bring back dirty files into their windows independent from any setting (other than the hot exit one at least). Btw untitled workspaces behave exactly the same for the same reasons because they may contain setting changes that are unsaved.


I think you're describing the designed behavior, I mean to ask about the behavior to 1.43 so that it's clear how having caused the backups to behave and why backups stacked up not getting restored (was this because they weren't being saved to anymore?).
I think can comment if there was some intention behind the change or just an oversight. To be clear: I would never expect a folder with backups to be to a workspace to turn it into a multi-root workspace.
One thing might be considered, as discussed with in Gitter, is to limit the number of windows/workspaces to be restored upon start, such as 10 at most, which might relieve this "correction".
We decided to fix this by reverting the change and no longer restore the folders with unsaved content. That was the behavior from 1.32 to 1.42 and as we didn't get any complaints, this seems to be practical. You can always open these folders from the recent menu, and unsaved content is restored. I created as a followup issue for the next milestone. We plan to also no longer restore workspaces (except unsaved/untitled workspaces) and we will add more information to the recent menu to show which folders/workspaces have unsaved content.
To verify: set open 2 windows, each opened on a folder. Make a unsaved change or add a untitled file with content close both windows. There should be no questions asked, exit VSCode open VSCode on an other folder (). Only one window should appear


When a user opens a file extension that does not have a specific recommendation tied to it, we show the general notification that points users to the marketplace. This has the following flaws: Most popular file types are already covered by specific extensions, so what gets left in this experience is leftovers For most of the extensions there is no good extension to handle this experience. Thus opening the Extension page does not provide value This is adding un-needed pings to the Marketplace service Also we had a bug that this feature was not available in stable and only 3 users found it is not there Would love for us to get some telemetry on this actions to see if this is actually bringing value to users. If not, we should either: Remove this flow completely Have a pre-defined set of file extensions for which we show this. Checking with tags seems to be very faulty. In my example below there is not an extension that helps with PowerPoint files. !
Only of these notifications end up with users clicking on Search Marketplace ! When it is actually clicked here are the top extensions ! Thus I suggest that we: Remove this dialog Add explicit extension recommendation for and . Since those seem to be missing. what do you think?
Sounds good to me
Great. Ok, you remove the dialog when you find time, I will add the recommendations for csv and pdf. Or if you go on vacation, I can also remove the dialog. I am working in August. Thanks
Feel free to remove it in August, otherwise I can also do it in September. Here it is
To verify: a file with some strange extension. For example -make sure no notification shows up a .py file or .go file. Make sure you get an extension recommendation for specific python / go extensions


Testing Currently the "Undo last commit" command has not effect while the commit editor is open. It should either: disabled enabled and on execution close the editor and abandon the current commit I think option 1 is better !
Part of disablement revamp effort:
It also shows up in command palette !


<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.41.1 OS Version: Windows 10 Steps to Reproduce: the "Explorer" view (e.g. with Ctrl+B) a file from the Windows Explorer to drop it in the Explorer icon in vscode. explorer does not automatically open, which would be somewhat helpful, in order to be able to drop the file in the folder of your choice directly. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
This is a fair feature request for the that on dragOver the corresponding view would get open. I think this feature reuqest makes sense in general, since in the future we might want to drag and drop views between containers, and then the corresponding container should expand. Thus also assigning to
this is a regression though. Testing I can move a file from the desktop over the (collapsed) activity bar and views expand properly and focus depending on which view is hovered. This was very useful to drag images to for writing release notes. Can we bring it back?
Re-labeled it then, and assigned to Janaury so we try to fix it this milestone. hope that makes sense.
Thanks a lot for the fix


! 'void' should not as column num Version: 1.70.0-insider (user setup) Commit: Date: 2022-07-26T05:16:55.337Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0.
Your Insiders is outdated. Please update and retest.
Version: 1.71.0-insider (user setup) Commit: Date: 2022-08-12T05:17:00.323Z Electron: 19.0.11 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes still have problem
sorry for mistake close
Tricky edge case, perhaps we should parse the col/row and remove col if invalid and col+row if they're both invalid?


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.78.1 (system setup) Commit: Date: 2023-05-04T09:48:08.683Z Electron: 22.5.1 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0. Sandboxed: No Steps to Reproduce: a workspace at a UNC path that isn't set in security.allowedUNCHosts. "Yes" when prompted to temporarily allow working from that host. changes to one or more files without_ saving them. VSCode without closing the workspace (may require specific settings to automatically re-open the previous workspace). time, click the "Learn More" button when prompted to allow working from that host. Note that any unsaved editors remain, but the rest of the workspace is not loaded as though the user clicked the "No" button. I'd argue that "Learn More" doesn't constitute a decision from the user and shouldn't proceed as though it was. Depending on the nature of the changes, this may cause a problem for safely saving those changes because if the user tries to re-open the workspace, they are asked to either save or close these orphaned editors. Perhaps a link among the text in the dialogue box would be more appropriate than a button which closes the box.
I agree that the dialog should not close and/or make a decision when you click "Learn More". Unfortunately the dialog closes when you press that button, so best I can do is to open it again asking the same question.


Markdown file on Plain Text on startup: ! Same with TS in another window: ! Reproduces by reloading the window. Not sure who the right person is for this Version: 1.93.0-insider (user setup) Commit: Date: 2024-08-08T05:03:51.428Z Electron: 30.1.2 ElectronBuildId: Chromium: 124.0.6367.243 20.14.0 V8: 12.4.254.20-electron.0 OS: Windows_NT x64 10.0.
On it


<!-- 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. --Type: Bug Missing pricing parameter in extension manifest. The attribute is not included in the and so does not show up in IntelliSense. Related docs issue: I'm working on the fix. FYI: <!-- 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. --


<!-- 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 The behavior was correct few weeks ago. <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version : 1.65.0 Validation : Date : 2022-03-02T11:12:36.248Z Electron : 13.5.2 Chromium: 91.0.4472.164 : 14.16.0 V8 : 9.1.269.39-electron.0 Système d’exploitation : Linux x64 5.16.11-100.fc34.x86_64 Steps to Reproduce: an integrated terminal and type the following command : , alt + click on the printed link browser is open with url , but it should be opened with url ! Working test on native terminal : a native linux terminal (for my DE, it is gnome-terminal with zsh) the following command : , ctrl + click on the printed link browser is open with url , as this is the correct expected behavior !
Looks like we're passing the right thing to the opener service !
I can repro this with: I can copy and paste that URL into a browser and it will work. I can run the same code in regular terminal and it will work. It doesn't work when I click on the link from w/in the vscode terminal.
This has come up before where it was closed by design, originally I don't think it was possible to open a link like this because opener service always works on uris and they always encode like this. I notice though that the editor properly retains the in a link though so it should be possible now.
Okay thanks!
Thank you


Environment Details: VSCode Version : 1.24.1 OS Version : Win10 Additional Details: MAS Violated: MAS2.4.7 Repro Steps: VS Code Keyboard Shortcuts from the Settings icon on the bottom left bar. Dark+(default dark) theme and other dark themes and check the focus visibility. Actual: Keyboard focus is not clearly visible on Sort by precedence button when default dark theme is applied. Expected: Focus should be clearly visible and should be outlined by solid or dotted line. Recommendations: Refer below link which is repository of bug fixes code snippets: User Impact: User will not be able to see the focus properly. MAS Reference Attachment for Reference: ! Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.593 --- <!-- score: 0.523 --- <!-- score: 0.457 --<!-- potentialduplicatescomment --
Sounds like colors and contrast, also assigning to
can you clarify if this also applies to our overall focus treatment? We use the same blue outline for most of our focus treatments: ! ! !
You can use any color for emphasizing the focus but it should be clearly visible to the user on all the color themes.
Please let me know when there are any changes to be done from my side.
will do, I think I'll need to play around with the offset of the outline color (and possibly opacity).
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version (in docker): building and running the following dockerfile gives the following: changing the command in the docker file to gives the following: creating a non-sudo user in the docker container and running it from that works, but that leads to a headache of problems with other parts of my docker image. ideally, the fix suggested by code in the first example would solve this but it doesnt.
related to
doesn't apply to . That's an option for electron, and doesn't run electron. Just omit that argument and run the command.
omitting just makes it complain about being unexpected. no combination of arguments fixes this as far as i can tell causes causes causes causes
What code print?
i put the output of at the top of my issue, but here it is again:
would it be possible to reopen this? it seems like there is no solution based on whats been said so far
Looks like a workaround would be setting when you call . But the better solution is just to use the CLI () instead of the full desktop install. This will be fixed when the desktop install uses the native CLI as its primary entrypoint.
Works with . The is important, otherwise it will be misinterpreted.
I still get the same error: adding CANRUNAS_ROOT=1 did not make a difference.
I cannot repro, can you share the exact command you ran?
All is good, sorry, I tested against an old version!
This issue will be closed because it appears to be verified


Type: <bBug</bCC a terminal in editor area in the terminal alt+f2 to open Accessible View alt+UpArrow and alt+DownArrow to see if it moves between executed commands. Notes: alt+DownArrow unexpectedly opens a new terminal view. VS Code version: Code - Insiders 1.83.0-insider (, 2023-09-21T05:34:38.227Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (91)</summaryExtensionVersion ------ android-dev-ext1.3.2 aiprm-lang0.0.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.118 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.23.1 gitlens14.3.0 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-google-translate1.4.13 codespaces1.15.3 copilot1.115.430 copilot-chat0.8. remotehub0.60.0 vscode-github-actions0.26.2 vscode-pull-request-github0.72.0 overleaf-workshop0.2.1 cslpreview0.2.2 easy-snippet0.6.3 path-autocomplete1.25.0 latex-workshop9.14.0 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.1 black-formatter2023.4.1 flake82023.6.0 isort2023.11.


python2023.16.0 vscode-pylance2023.9.20 jupyter2023.8. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.311.0 remote-ssh0.106.4 remote-ssh-edit0.86.0 remote-wsl0.81.4 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.15.31 cpptools1.17.5 cpptools-extension-pack1.3.0 js-debug-nightly2023.9.2017 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.18 vscode-serial-monitor0.10.0 vsliveshare1.0.5883 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.4 shinyuieditor0.4.3 quarto1.98.0 r-debugger0.5.4 java1.22.1 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.7.0 latex-utilities0.4.10 cmake0.0.17 errorlens3.13.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.54.0 vscode-java-dependency0.23.1 vscode-java-pack0.25.14 vscode-java-test0.39.1 vscode-maven0.42.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I could repro this yesterday, but it's working for me in today's insider's. Pls let me know if it's not for you.
Still does not work. Tested on Windows 11.
I had forgotten this is an issue only when the terminal is in the editor area.


<!-- 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 Does this issue occur when all extensions are disabled?: Yes/No VS Code Version: 1.77.1 OS Version: Ubuntu 22.10 Steps to Reproduce: !
The bot never kicked in, can you check that it is fixed in the latest Insiders build of VS Code?
I can confirm, it is fixed!


I don't know the codicons by heart. So I went with . Here's what I see: ! ! Can you validate if is valid? Or somehow show a better default? I'd prefer validation though. Testing


<!-- 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: MacOS 13.3.1 Steps to Reproduce: Run the following commands Trust the workspace, then start the script from the "NPM Scripts" panel. The script runs, and the name of the script appears to the right of the output panel, together with a spinner showing that it's running. Now run the script again. A popup window appears saying that it's already running, and do you want to terminate or restart it (just close it without doing either). This is all expected behavior. Now (with the task running) run Cmd-Shift-P "Developer: Reload Window". The window reloads, and the script continues to run (you can tell it's the same script because it's printing its pid, and it doesn't change). The name is still in the right hand pane, but now the spinner has gone, as if vscode no longer knows that it's running. Now run the script again, and although it's already running, it starts a second copy. This is the bug. It's especially painful for "runOnOpen" tasks, because every time you reload the window (eg because an extension needs updating) they all continue to run AND a new copy of each one starts. I thought there might be another bug in the recently (since that was supposed to fix exactly this issue - ), and took a look at that.


There does appear to be a pretty serious bug in that code: It adds to the at line 1839, then starts the task at line 1853, and then removes at line 1855 without waiting for the task to finish. So in practice the list is almost always empty, and doesn't actually do anything. I think the at line 1855 should actually be in a clause attached to the on line 1856, so that it doesn't run until the task completes. But fixing that doesn't actually fix this issue, because the set isn't preserved (or reconstructed) across reloads. In addition it breaks the above behavior where trying to run an already running task asks what you want to do with it (because now that inProgressTasks is actually working, it aborts the attempt to re-run the task before it gets to the point where that dialog is presented). It also breaks tasks that are explicitly marked as allowing more than one instance. So since it isn't currently doing anything, and fixing it breaks things, I would suggest removing all the associated code ( I'm not sure what the actual fix should be though. There seems to be code to try to reconnect tasks to terminals: but it doesn't seem to work (I've stepped through the code with my example, and it goes into but doesn't actually find any tasks to reconnect). So maybe the bug is there. Or maybe the bug is that the tasks shouldn't be preserved across reload (many are not; a terminal that isn't running anything will be killed by reload, for example). But I've reached the limits of what I can debug, unless anyone has suggestions for where to look.
thanks for looking into this. the reason it's not in a is this was meant to (and did) fix an issue that was super hard to reproduce where duplicate tasks would get started. the only tasks that get reconnected to are those with and have problem matchers. you can disable this with .
task reconnection works for me https://user-
Ok. So there's a race that happens between deciding to launch the task and actually launching it? In that case, the solution seems kind of misleading. Shouldn't it be something like rather than ? but also, instead of why not just do And why do you need the in since it was already deleted right after it launched?


But all this is incidental; I was hoping this code could prevent the bug I reported, but clearly it can't.
Ok... but the problem is that my task is left running across the reload, but it doesn't get reconnected (apparently intentionally), so attempting to start it again succeeds, even though it's supposed to only allow one instance. https://user- I'm not sure what that .mov is supposed to be showing me; I can't see anything relating to tasks being reconnected (but I'm not sure what Im looking for). But anyway, I'm not claiming it's broken; just that it doesn't reconnect my task (or similar ones). And if, as you say, thats intentional, then the bug is elsewhere. But as far as I can tell, either my task shouldn't be left running, or it should be reconnected.
Another data point. After reloading, the task is clearly running, but tells me "No running tasks"
So when I set this to false, my task is killed on window reload, which does mitigate the problem (in fact, for my use case, I think this does solve the problem - although I don't know yet whether it introduces new ones). But that still leaves us with the issue when is . The task is left running, but not (properly) reconnected - so although it's there, and its output is going to.a terminal, the abstractTaskService, and terminalTaskSystem aren't aware of it (so that "Show Running Tasks" says there are none, and attempting to start a second instance succeeds).
I won't be looking into this any time soon just fyi. So if it bothers you, feel free to keep digging. Otherwise, just keep the setting disabled.
I run into this problem all the time too, which is very frustrating. I have to reload often due to SSH reconnection etc, this reattach issue together with ssh agent forwarding on mac os breaking, are really detrimental to the work flow. Using works around some of the issue, but exposes a new one; one of my processes doesn't get killed and blocks the new one from starting. That process appears to be a nodemon process, perhaps related to
Yeah that is unrelated to this feature as you mentioned.
as noted in the pull request, this doesn't fix everything, but it makes my workflow (with several auto-run tasks) much cleaner.


Those tasks will be properly reconnected on reload, rather than an additional set being kicked off on each reload. For tasks that don't auto-run on reload, the only change is that the first attempt to run a new instance of that task will simply attach to the existing process; and subsequent attempts will fail the same way they do before the reload. Other than that, there should be no change in behavior, so I think this should be pretty safe. I spent some time trying to figure out how to actually reconnect all the running tasks, rather than just marking them for reconnection, but I kept running into issues where needed to know about the internals of ( in particular). Or I needed to extend the ITaskSystem api - which I'm reluctant to do without guidance. I also tried a completely different approach - namely, including non-background tasks in . That almost worked, but the problem was that gave a different result when the task is launched manually vs when it's run from (when run manually, its a , but when run from its a , which gets resolved to a ). As a result, the tasks did get reconnected properly, the various commands (eg ) know they're there and do the right thing; but now trying to run them manually uses a different key, and still starts a new copy...
thanks for looking into this. I commented on your PR
To verify, run a non background task. Reload the window. Verify that you can run that task again