jiebi/CodeConvo huggingface dataset:
Code change:
import { WorkbenchStateContext } from 'vs/workbench/common/contextkeys'; import { OpenFolderAction, OpenFileAction, OpenFileFolderAction } from 'vs/workbench/browser/actions/workspaceActions'; import { isMacintosh, isWeb } from 'vs/base/common/platform'; <del> import { isCodeEditor } from 'vs/editor/browser/editorBrowser'; </del> <ins> import { isCodeEditor, isDiffEditor } from 'vs/editor/browser/editorBrowser'; </ins> import { IStorageService, StorageScope, StorageTarget } from 'vs/platform/storage/common/storage'; import { ITelemetryService } from 'vs/platform/telemetry/common/telemetry'; import { DisposableStore } from 'vs/base/common/lifecycle';

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.85.1 OS Version: macOS Sonoma 14.2.1 Steps to Reproduce: a python file or other file with a debugging extension installed Debug view and see the welcome view showing Run and Debug Actions. a diff Editor for the same file debug view now shows an Expected: Debug view shows the same welcome state as when not in diff view as this language has debug extension installed. <img width="694" alt="image" src=""Actual: !
Code change:
} if (node.collapsible) { <del> // Do not set this before calling a handler on the super class, because it will reject it as handled e.browserEvent.isHandledByList = true; </del> const location = this.tree.getNodeLocation(node); const recursive = e.browserEvent.altKey; this.tree.setFocus([location]); this.tree.toggleCollapsed(location, recursive); if (expandOnlyOnTwistieClick && onTwistie) { <ins> // Do not set this before calling a handler on the super class, because it will reject it as handled e.browserEvent.isHandledByList = true; </ins> return; } }

Related discussion:
text: see gif open GH notebook with a few cell that reference a variable run peek references and select entries notice how notebook cells are being highlighted, like "Milestone Work" get selected !
I can repro in Insiders but not master, I'll check again tomorrow
This happens because of this listener: Tho, not yet sure why the selection keeps changing... Maybe some inner list event (from the references list) bubbles up to the outer list
That listener is fine, it's the nested lists
Hey do you have any thoughts on handling this? We have a list inside another list. The inner list handles the touch event properly. The outer list then handles the event and picks up the wrong index because it finds the data attribute inside the inner list in We can Make sure the event is fired on the outer list with the correct element, by fixing to check whether it's in the right list Not fire the event on the outer list at all, when we see that it originates in a different list Add some property to the list event that says it originated in a different list so the consumer can decide In this particular case, I think any of these are fine
Thinking more, I don't think that the event should ever be handled by two lists at all. Meaning we either mark the browserEvent as handled, like with preventDefault/isDefaultPrevented, or we make the list check every event to be sure that it originated in this list.
This sounds good to me. This also sounds good to me.
related when I do peek references, I see markdown cells being selected? ! Notice I'm looking for under-discussion but "Configure" is being highlighted as one of the references
From Good catch, I didn't notice that
Thanks for the quick handling!
Code change:
case MarkdownPreviewSecurityLevel.AllowInsecureContent: return `<meta http-equiv="Content-Security-Policy" content="default-src 'none'; img-src vscode-resource: http: https: data:; media-src vscode-resource: http: https: data:; script-src 'nonce-${nonce}'; style-src vscode-resource: 'unsafe-inline' http: https: data:; font-src vscode-resource: http: https: data:;">`; <ins> case MarkdownPreviewSecurityLevel.AllowInsecureLocalContent: return `<meta http-equiv="Content-Security-Policy" content="default-src 'none'; img-src vscode-resource: https: data: http://localhost:* http://127.0.0.1:*; media-src vscode-resource: https: data: http://localhost:* http://127.0.0.1:*; script-src 'nonce-${nonce}'; style-src vscode-resource: 'unsafe-inline' https: data: http://localhost:* http://127.0.0.1:*; font-src vscode-resource: https: data: http://localhost:* http://127.0.0.1:*;">`; </ins> case MarkdownPreviewSecurityLevel.AllowScriptsAndAllContent: return '';

Related discussion:
text: <!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.21.1 OS Version: MacOS High Sierra 10.13.3 (17D102) Steps to Reproduce: markdown preview in combination with local plantuml server code to use local server for rendering a markdown with embedded plantUML content error about unsafe content ! The current only allow to enable/disable unsafe (HTTP without the S) entirely. Would it make sense to add an option that allows unsafe content from localhost but not from remote sources?
This may be ok (at least for images): If someone wants to take a look at this, you would just need to update the content security policy to allow :
Looking into it, thanks for the pointer.
Code change:
// Listen to editor closing (if we run with --wait) const filesToWait = this.environmentService.configuration.filesToWait; if (filesToWait) { <del> const resourcesToWaitFor = coalesce(filesToWait.paths.map(p => p.fileUri)); </del> const waitMarkerFile = filesToWait.waitMarkerFileUri; <del> const listenerDispose = this.editorService.onDidCloseEditor(() => this.onEditorClosed(listenerDispose, resourcesToWaitFor, waitMarkerFile)); </del> <ins> const resourcesToWaitFor = coalesce(filesToWait.paths.map(p => p.fileUri)); </ins> <del> this._register(listenerDispose); </del> <ins> this._register(this.trackClosedWaitFiles(waitMarkerFile, resourcesToWaitFor)); </ins> } }

Related discussion:
text: VSCode Version: 1.33.1 OS Version: 10.14.4 When editing and closing a git commit message file very quickly, the contents are not provided to git. Currently I manually save before closing any git commit file but it seems clear this should work properly - autosave should happen, then Code should inform Git that the commit file is ready. Currently it appears the two events are happening in reverse order, causing a bug. Steps to Reproduce: VS Code as editor () a git commit the commit message in Code close the commit message in Code, before autosave occurs Result: git complains about an empty commit message Expected: Autosave should happen before Code releases control back to git, resulting in a properly saved commit message Does this issue occur when all extensions are disabled?: Yes
Good catch. Extra points for using auto save in VSCode :+1:
via
Code change:
// service worker already loaded & ready to receive messages postVersionMessage(currentController); } else { <del> console.log(`Found unexpected service worker controller. Found: ${currentController?.scriptURL}. Expected: ${swPath}`); </del> <ins> if (currentController) { console.log(`Found unexpected service worker controller. Found: ${currentController.scriptURL}. Expected: ${swPath}. Waiting for controllerchange.`); } else { console.log(`No service worker controller found. Waiting for controllerchange.`); } </ins> <del> // either there's no controlling service worker, or it's an old one: // wait for it to change before posting the message </del> <ins> // Either there's no controlling service worker, or it's an old one. // Wait for it to change before posting the message </ins> const onControllerChange = () => { navigator.serviceWorker.removeEventListener('controllerchange', onControllerChange); <del> postVersionMessage(navigator.serviceWorker.controller); </del> <ins> if (navigator.serviceWorker.controller) { postVersionMessage(navigator.serviceWorker.controller); } else { return reject(new Error('No controller found.')); } </ins> }; navigator.serviceWorker.addEventListener('controllerchange', onControllerChange); }

Related discussion:
text: My extension is this one: Find attached a sample project: These are the steps: Install the extension Unzip in its own folder Open the folder with VSCode With selected, issue the command Toggle Design/Code This will open up the webview, and with the changes, you could see in the console the issues Find here a video with the steps on how to open the webview, and the behavior when its working: ! Thanks!
Needless to say that if I should perform any changes on the extension to make it work, it's not a problem at all. That is, if I can get an idea on what the changes are, have no problem on that. :-) Thanks!
Thanks for the repo steps I have a potential Please try the next VS Code insiders build that comes out and let me know if you still see the problem. With the fix, things seem to be loading correctly: <img width="1129" alt="Screenshot 2023-04-12 at 4 06 24 PM" src="https://user-"
Checked insiders, but not sure if the fix got through, as I see some checks failed: ! Also tried update from the repository, and it seems still is not merged. In any case, what I see in your shot is that the Tool Palette is missing content. The content is provided by loading an external file called "" and it seems the webview is not able to load it: ! Will keep checking, THANKS!
ignore my last message, I have merged your changes locally and works perfect! So once this is merged, consider the issue fixed, thanks a lot!! !
<!-- 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
Code change:
} const controller = editor.getContribution<TroubleshootController>(TroubleshootController.id); <del> controller?.toggleLogging(); </del> <ins> controller?.toggle(); </ins> } });

Related discussion:
text: Open Select the top cell and page down a few times Focus hits a cell that is longer than the viewport, which is maybe important, then the next page down moves to a higher cell
When a list item is larger than the viewport, and it's also the only element in the viewport, pressing page down will reveal to the previous element, this is because we did a here (the catch is, the last page element is also the first page element)
Code change:
'force'?: boolean; 'force-user-env'?: boolean; <del> // node flags </del> <ins> // chromium command line args: https://electronjs.org/docs/all#supported-chrome-command-line-switches 'no-proxy-server'?: boolean; 'proxy-server'?: string; 'proxy-bypass-list'?: string; 'proxy-pac-url'?: string; 'inspect'?: string; 'inspect-brk'?: string; </ins> 'js-flags'?: string; 'disable-gpu'?: boolean; 'nolazy'?: boolean;

Related discussion:
text: <!-- 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.39.0 OS Version: Linux RHEL 7 Steps to Reproduce: code with --no-proxy-server flag "Option 'proxy-server' is unknown. Ignoring." error appears. I think the proxy is still disabled, the error message is simply wrong? If I run without the flag, I get prompted to log into the proxy, if I run with the flag, the proxy appears disabled (no log in prompting) but the error appears on the command line.
I suggest to include that fix in the recovery builds to avoid any confusion due to the message printed by the cli. The cli says for all chromium options, but in fact, they are used. My understanding is that most of the chromium options are not for the end-user except and the proxy settings, so I these to the list of the valid (supported) args. Please speak up if I missed one of the options. PR is
This is not fixed in the latest stable release candidate. The reason is that the PR was actually not merged and this issue was closed erroneously
The discussion in yesterday's standup was to take this, so we've now merged the PR...
Code change:
stickiness: TrackedRangeStickiness.AlwaysGrowsWhenTypingAtEdges, afterContentClassName: 'inline-folded', className: 'folded-background', <ins> minimap: foldedBackgroundMinimap, </ins> isWholeLine: true });

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When folded, folding ranges are displayed in the editor as a single line with darkened background. Hovever (as of ), on the minimap, the background of this line is not darkened. This makes it harder to navigate using the minimap. !
Either this isn't working or steps are non trivial
Ok, see this working unless I have render characters enabled
Code change:
} } <del> export class ExtensionsTree extends WorkbenchAsyncDataTree<IExtensionData, any> { </del> <ins> export class ExtensionsTree extends WorkbenchAsyncDataTree<IExtensionData, IExtensionData> { </ins> constructor( input: IExtensionData,

Related discussion:
text: Steps to Repro: Search for an extension pack in extensions view (Say PHP Extension Pack) Open PHP Extension Pack in the editor Go to Extensions Pack tab Click on any extension Fails to open Close to open the editor Does not close Not sure how it happened but I had the extension pack open (as extension editor) and after a while (being on twitter) I wanted to close the editor and I saw error notifications. These are the minified stacktraces from the log the build was
Not able to repro it. Also followed the code and I do not see a path that has no extension in the input. Do you remember any steps you followed during this? Is it possible to guess what could be happening in editor land from the above stack trace?
are you using editors with preview mode, e.g. do they appear italic? Hard to say what the execution flow here is to be honest. Looks like a normal editor opening but failing to get the resource for the editor, which is used to associate the editor in the editor tabs model.
But this is happening while is trying to close the currently opened extension editor.
I don't use tabs, so I am not sure what the model then is... Yes, closing it was. I had the extension editor open, also installed the extension, then waited, and then tried to close the editor. So maybe some cleanup logic hit me or installing the extension made a different...
The preview feature works with tabs enabled or disabled. The fact that an editor is opened can be explained if you closed an editor and the next one below that editor was the extension editor. Closing an editor always means we open the previous editor unless it is the last editor. I suggest you try to figure out how it is possible that is even though it is not typed as such.
Ok
What are the verification steps for this?
Steps to repro are in the description
Code change:
import * as aria from 'vs/base/browser/ui/aria/aria'; import { Action, IAction } from 'vs/base/common/actions'; import { distinct } from 'vs/base/common/arrays'; <del> import { Queue, raceTimeout, RunOnceScheduler } from 'vs/base/common/async'; </del> <ins> import { raceTimeout, RunOnceScheduler } from 'vs/base/common/async'; </ins> import { CancellationTokenSource } from 'vs/base/common/cancellation'; import { isErrorWithActions } from 'vs/base/common/errorMessage'; import * as errors from 'vs/base/common/errors';

Related discussion:
text: <!-- 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.63.2 OS Version: macOS 12.1 (ARM64) I can't get more than two launch configurations to run at the same time. I can run the rest of the configurations afterwards and everything works (debugging, etc.). StopAll will also only close the two configs that were successfully launched. I haven't found any mention in the documentation that this is limited to two launch configurations. I've only seen that two are used in every explanation or tutorial about this feature. Steps to Reproduce: multiple launch configurations in multi-root workspace inside of project roots. launch configurations to compounds in .code-workspace file debugging two of the many compound configurations will run Examples:
VS Code imposes no limit on number of launch configurations in compound config. I've verified this with this simple example project (which only relies on built-in VS Code features and not third-party extensions): unpack zip file in VS Code use "Open Workspace from file" to open workspace file inside folder switch to debug viewlet in debug config dropdown select and run "4 Debug Session" Observe: 4 debug sessions: <img width="1384" alt="CleanShot 2022-01-26 at 11 45 23 src="https://user-"Maybe there is a limit on dotnet/coreclr?
Thank you for taking a look at this After inspecting your configuration and some research in my own project I was able to isolate the culprit. The problem arises when you try to make use of inputs in the launch configuration.
Code change:
import * as aria from 'vs/base/browser/ui/aria/aria'; import { Action, IAction } from 'vs/base/common/actions'; import { distinct } from 'vs/base/common/arrays'; <del> import { Queue, raceTimeout, RunOnceScheduler } from 'vs/base/common/async'; </del> <ins> import { raceTimeout, RunOnceScheduler } from 'vs/base/common/async'; </ins> import { CancellationTokenSource } from 'vs/base/common/cancellation'; import { isErrorWithActions } from 'vs/base/common/errorMessage'; import * as errors from 'vs/base/common/errors';

Related discussion:
text: I created a demo for download, the process is the same as you described above.
thanks for the additional info. I was able to create an even smaller repro without a multi-folder workspace: unpack zip file in VS Code open the "compound" folder switch to debug viewlet in debug config dropdown select and run "Compound" Observe: only one debug session starts
Is it possible to implement the input that allows blocking another input request until the first input has completed? Latter quick pick also cancels former ones so it needs to be fixed as well.
Do you own the configuration resolver Is my solution correct or should the service guarantee correct behavior when calling into it multiple times simultaneously?
your solution looks good. The configuration resolver service doesn't currently make any guarantees about what will happen if it's called into multiple time simultaneously. I would also be fine with the change being in the configuration resolver service though. We can change it's behavior so that it does make that guarantee.
Yes, making the fix in the configuration resolver service sounds better.
This fix doesn't fully cover our scenario (tested in latest insiders). This fixes case, and yet we also prompt for input or quick pick in , which is not covered in this PR. Is it appropriate to wait for as well?
Good point. Yeah, I think that makes sense.
I guess we'll need Queue's for and Would you like to make the changes, or should I work on this?
I can take care of it
This gets a bit weird. Since one launch config can be calling into the variable resolver (the first fix) while the second is calling the extension config provider, we also need a queue that orchestrates those two things. Easiest fix is to start launch configs one at a time instead of kicking them off in parallel: and I'm not sure what other impacts that could have. Perf to some extent, probably. So I wonder whether we would ever consider queueing calls into the quick pick control so that invoking the quick pick while it is already visible would wait instead of cancelling the first one as it does currently. Example of what I'm talking about (but in my real situation it's an extension competing with code in core): This extension code only shows one input box, while we could have the second wait for the first to complete. This could possibly be a breaking change for some extensions though, so it could be enabled with a flag.
Code change:
import * as aria from 'vs/base/browser/ui/aria/aria'; import { Action, IAction } from 'vs/base/common/actions'; import { distinct } from 'vs/base/common/arrays'; <del> import { Queue, raceTimeout, RunOnceScheduler } from 'vs/base/common/async'; </del> <ins> import { raceTimeout, RunOnceScheduler } from 'vs/base/common/async'; </ins> import { CancellationTokenSource } from 'vs/base/common/cancellation'; import { isErrorWithActions } from 'vs/base/common/errorMessage'; import * as errors from 'vs/base/common/errors';

Related discussion:
text: As an easy workaround, I can put a queue around calling into the vscode variable resolver and calling an extension debug config provider. But, putting a queue around two unrelated pieces of code seems to say that I'm solving the problem at the wrong level.
Or maybe make them the same level by moving the resolve queue to
Just to be clear. The two callers of the are in two different places right (core and extension)?
Right
Ok I've not heard of any feature request like this but feel free to open one... I wonder if maybe instead Core could have concept of "important" quick picks that can't be stomped over by extensions and instead the extension calls wait until Core is done. Then we don't need any more API
It can also go the other way. The problem is just that there are two async processes that have to run and show a quick input, and we need both of them to complete and not to get canceled by the other. Filed I'll go with a workaround for now, so I'm not blocked, just figured I'd start the discussion
Sorry for the late reply. I tested this today and it works for our scenario. Thanks for the quick fixes!