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

this.cell.editorHeight = contentHeight; } <ins> private _editorLayoutInProgress = false; </ins> layout(state: IDiffElementLayoutState) { DOM.scheduleAtNextAnimationFrame(() => { <ins> this._editorLayoutInProgress = true; </ins> if (state.editorHeight) { this._editorContainer.style.height = `${this.cell.layoutInfo.editorHeight}px`; this._editor!.layout({


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

} <ins> this._editorLayoutInProgress = false; </ins> this.layoutNotebookCell(); }); }


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

const workbenchRegistry = Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench); workbenchRegistry.registerWorkbenchContribution(ExtensionsContributions, LifecyclePhase.Restored); <del> workbenchRegistry.registerWorkbenchContribution(StatusUpdater, LifecyclePhase.Restored); </del> <ins> workbenchRegistry.registerWorkbenchContribution(StatusUpdater, LifecyclePhase.Eventually); </ins> workbenchRegistry.registerWorkbenchContribution(MaliciousExtensionChecker, LifecyclePhase.Eventually); workbenchRegistry.registerWorkbenchContribution(KeymapExtensions, LifecyclePhase.Restored); workbenchRegistry.registerWorkbenchContribution(ExtensionsViewletViewsContribution, LifecyclePhase.Restored);


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

@IWorkbenchExtensionEnablementService private readonly extensionEnablementService: IWorkbenchExtensionEnablementService ) { super(); <ins> this.onServiceChange(); </ins> this._register(Event.debounce(extensionsWorkbenchService.onChange, () => undefined, 100, undefined, undefined, this._store)(this.onServiceChange, this)); }


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

this._register(this.storageService.onDidChangeValue(e => this.onDidChangeStorage(e))); } private _reportTelemetry() { const extensionIds = this.installed.filter(extension => !extension.isBuiltin &&


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

return nls.localize('postUpdateTooltip', "Please reload Visual Studio Code to enable the updated extension."); } <del> const extensionInOtherServer = this.installed.filter(e => areSameExtensions(e.identifier, extension!.identifier) && e.server !== extension!.server)[0]; if (extensionInOtherServer) { // This extension prefers to run on UI/Local side but is running in remote if (runningExtensionServer === this.extensionManagementServerService.remoteExtensionManagementServer && this.extensionManifestPropertiesService.prefersExecuteOnUI(extension.local!.manifest) && extensionInOtherServer.server === this.extensionManagementServerService.localExtensionManagementServer) { return nls.localize('enable locally', "Please reload Visual Studio Code to enable this extension locally."); } </del> <ins> if (this.extensionsServers.length > 1) { const extensionInOtherServer = this.installed.filter(e => areSameExtensions(e.identifier, extension!.identifier) && e.server !== extension!.server)[0]; if (extensionInOtherServer) { // This extension prefers to run on UI/Local side but is running in remote if (runningExtensionServer === this.extensionManagementServerService.remoteExtensionManagementServer && this.extensionManifestPropertiesService.prefersExecuteOnUI(extension.local!.manifest) && extensionInOtherServer.server === this.extensionManagementServerService.localExtensionManagementServer) { return nls.localize('enable locally', "Please reload Visual Studio Code to enable this extension locally."); } </ins> <del> // This extension prefers to run on Workspace/Remote side but is running in local if (runningExtensionServer === this.extensionManagementServerService.localExtensionManagementServer && this.extensionManifestPropertiesService.prefersExecuteOnWorkspace(extension.local!.manifest) && extensionInOtherServer.server === this.extensionManagementServerService.remoteExtensionManagementServer) { return nls.localize('enable remote', "Please reload Visual Studio Code to enable this extension in {0}.", this.extensionManagementServerService.remoteExtensionManagementServer?.label); </del> <ins> // This extension prefers to run on Workspace/Remote side but is running in local if (runningExtensionServer === this.extensionManagementServerService.localExtensionManagementServer && this.extensionManifestPropertiesService.prefersExecuteOnWorkspace(extension.local!.manifest) && extensionInOtherServer.server === this.extensionManagementServerService.remoteExtensionManagementServer) { return nls.localize('enable remote', "Please reload Visual Studio Code to enable this extension in {0}.", this.extensionManagementServerService.remoteExtensionManagementServer?.label); } </ins> } }


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

*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> .codicon.codicon-symbol-array { color: var(--vscode-symbolIcon-arrayForeground); } .codicon.codicon-symbol-boolean { color: var(--vscode-symbolIcon-booleanForeground); } .codicon.codicon-symbol-class { color: var(--vscode-symbolIcon-classForeground); } .codicon.codicon-symbol-method { color: var(--vscode-symbolIcon-methodForeground); } .codicon.codicon-symbol-color { color: var(--vscode-symbolIcon-colorForeground); } .codicon.codicon-symbol-constant { color: var(--vscode-symbolIcon-constantForeground); } .codicon.codicon-symbol-constructor { color: var(--vscode-symbolIcon-constructorForeground); } .codicon.codicon-symbol-value, .codicon.codicon-symbol-enum { color: var(--vscode-symbolIcon-enumeratorForeground); } .codicon.codicon-symbol-enum-member { color: var(--vscode-symbolIcon-enumeratorMemberForeground); } .codicon.codicon-symbol-event { color: var(--vscode-symbolIcon-eventForeground); } .codicon.codicon-symbol-field { color: var(--vscode-symbolIcon-fieldForeground); } .codicon.codicon-symbol-file { color: var(--vscode-symbolIcon-fileForeground); } .codicon.codicon-symbol-folder { color: var(--vscode-symbolIcon-folderForeground); } .codicon.codicon-symbol-function { color: var(--vscode-symbolIcon-functionForeground); } .codicon.codicon-symbol-interface { color: var(--vscode-symbolIcon-interfaceForeground); } .codicon.codicon-symbol-key { color: var(--vscode-symbolIcon-keyForeground); } .codicon.codicon-symbol-keyword { color: var(--vscode-symbolIcon-keywordForeground); } .codicon.codicon-symbol-module { color: var(--vscode-symbolIcon-moduleForeground); } .codicon.codicon-symbol-namespace { color: var(--vscode-symbolIcon-namespaceForeground); } .codicon.codicon-symbol-null { color: var(--vscode-symbolIcon-nullForeground); } .codicon.codicon-symbol-number { color: var(--vscode-symbolIcon-numberForeground); } .codicon.codicon-symbol-object { color: var(--vscode-symbolIcon-objectForeground); } .codicon.codicon-symbol-operator { color: var(--vscode-symbolIcon-operatorForeground); } .codicon.codicon-symbol-package { color: var(--vscode-symbolIcon-packageForeground); } .codicon.codicon-symbol-property { color: var(--vscode-symbolIcon-propertyForeground); } .codicon.codicon-symbol-reference { color: var(--vscode-symbolIcon-referenceForeground); } .codicon.codicon-symbol-snippet { color: var(--vscode-symbolIcon-snippetForeground); } .codicon.codicon-symbol-string { color: var(--vscode-symbolIcon-stringForeground); } .codicon.codicon-symbol-struct { color: var(--vscode-symbolIcon-structForeground); } .codicon.codicon-symbol-text { color: var(--vscode-symbolIcon-textForeground); } .codicon.codicon-symbol-type-parameter { color: var(--vscode-typeParameterForeground); } .codicon.codicon-symbol-unit { color: var(--vscode-symbolIcon-unitForeground); } .codicon.codicon-symbol-variable { color: var(--vscode-symbolIcon-variableForeground); } </del> <ins> .monaco-editor .codicon.codicon-symbol-array, .monaco-workbench .codicon.codicon-symbol-array { color: var(--vscode-symbolIcon-arrayForeground); } .monaco-editor .codicon.codicon-symbol-boolean, .monaco-workbench .codicon.codicon-symbol-boolean { color: var(--vscode-symbolIcon-booleanForeground); } .monaco-editor .codicon.codicon-symbol-class, .monaco-workbench .codicon.codicon-symbol-class { color: var(--vscode-symbolIcon-classForeground); } .monaco-editor .codicon.codicon-symbol-method, .monaco-workbench .codicon.codicon-symbol-method { color: var(--vscode-symbolIcon-methodForeground); } .monaco-editor .codicon.codicon-symbol-color, .monaco-workbench .codicon.codicon-symbol-color { color: var(--vscode-symbolIcon-colorForeground); } .monaco-editor .codicon.codicon-symbol-constant, .monaco-workbench .codicon.codicon-symbol-constant { color: var(--vscode-symbolIcon-constantForeground); } .monaco-editor .codicon.codicon-symbol-constructor, .monaco-workbench .codicon.codicon-symbol-constructor { color: var(--vscode-symbolIcon-constructorForeground); } .monaco-editor .codicon.codicon-symbol-value, .monaco-workbench .codicon.codicon-symbol-value, .monaco-editor .codicon.codicon-symbol-enum, .monaco-workbench .codicon.codicon-symbol-enum { color: var(--vscode-symbolIcon-enumeratorForeground); } .monaco-editor .codicon.codicon-symbol-enum-member, .monaco-workbench .codicon.codicon-symbol-enum-member { color: var(--vscode-symbolIcon-enumeratorMemberForeground); } .monaco-editor .codicon.codicon-symbol-event, .monaco-workbench .codicon.codicon-symbol-event { color: var(--vscode-symbolIcon-eventForeground); } .monaco-editor .codicon.codicon-symbol-field, .monaco-workbench .codicon.codicon-symbol-field { color: var(--vscode-symbolIcon-fieldForeground); } .monaco-editor .codicon.codicon-symbol-file, .monaco-workbench .codicon.codicon-symbol-file { color: var(--vscode-symbolIcon-fileForeground); } .monaco-editor .codicon.codicon-symbol-folder, .monaco-workbench .codicon.codicon-symbol-folder { color: var(--vscode-symbolIcon-folderForeground); } .monaco-editor .codicon.codicon-symbol-function, .monaco-workbench .codicon.codicon-symbol-function { color: var(--vscode-symbolIcon-functionForeground); } .monaco-editor .codicon.codicon-symbol-interface, .monaco-workbench .codicon.codicon-symbol-interface { color: var(--vscode-symbolIcon-interfaceForeground); } .monaco-editor .codicon.codicon-symbol-key, .monaco-workbench .codicon.codicon-symbol-key { color: var(--vscode-symbolIcon-keyForeground); } .monaco-editor .codicon.codicon-symbol-keyword, .monaco-workbench .codicon.codicon-symbol-keyword { color: var(--vscode-symbolIcon-keywordForeground); } .monaco-editor .codicon.codicon-symbol-module, .monaco-workbench .codicon.codicon-symbol-module { color: var(--vscode-symbolIcon-moduleForeground); } .monaco-editor .codicon.codicon-symbol-namespace, .monaco-workbench .codicon.codicon-symbol-namespace { color: var(--vscode-symbolIcon-namespaceForeground); } .monaco-editor .codicon.codicon-symbol-null, .monaco-workbench .codicon.codicon-symbol-null { color: var(--vscode-symbolIcon-nullForeground); } .monaco-editor .codicon.codicon-symbol-number, .monaco-workbench .codicon.codicon-symbol-number { color: var(--vscode-symbolIcon-numberForeground); } .monaco-editor .codicon.codicon-symbol-object, .monaco-workbench .codicon.codicon-symbol-object { color: var(--vscode-symbolIcon-objectForeground); } .monaco-editor .codicon.codicon-symbol-operator, .monaco-workbench .codicon.codicon-symbol-operator { color: var(--vscode-symbolIcon-operatorForeground); } .monaco-editor .codicon.codicon-symbol-package, .monaco-workbench .codicon.codicon-symbol-package { color: var(--vscode-symbolIcon-packageForeground); } .monaco-editor .codicon.codicon-symbol-property, .monaco-workbench .codicon.codicon-symbol-property { color: var(--vscode-symbolIcon-propertyForeground); } .monaco-editor .codicon.codicon-symbol-reference, .monaco-workbench .codicon.codicon-symbol-reference { color: var(--vscode-symbolIcon-referenceForeground); } .monaco-editor .codicon.codicon-symbol-snippet, .monaco-workbench .codicon.codicon-symbol-snippet { color: var(--vscode-symbolIcon-snippetForeground); } .monaco-editor .codicon.codicon-symbol-string, .monaco-workbench .codicon.codicon-symbol-string { color: var(--vscode-symbolIcon-stringForeground); } .monaco-editor .codicon.codicon-symbol-struct, .monaco-workbench .codicon.codicon-symbol-struct { color: var(--vscode-symbolIcon-structForeground); } .monaco-editor .codicon.codicon-symbol-text, .monaco-workbench .codicon.codicon-symbol-text { color: var(--vscode-symbolIcon-textForeground); } .monaco-editor .codicon.codicon-symbol-type-parameter, .monaco-workbench .codicon.codicon-symbol-type-parameter { color: var(--vscode-typeParameterForeground); } .monaco-editor .codicon.codicon-symbol-unit, .monaco-workbench .codicon.codicon-symbol-unit { color: var(--vscode-symbolIcon-unitForeground); } .monaco-editor .codicon.codicon-symbol-variable, .monaco-workbench .codicon.codicon-symbol-variable { color: var(--vscode-symbolIcon-variableForeground); } </ins>


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

const viewsService = serviceAccessor.get(IViewsService); const viewContainerLocation = viewDescriptorService.getViewContainerLocation(viewContainer); switch (viewContainerLocation) { <del> case ViewContainerLocation.Sidebar: if (!viewsService.isViewContainerVisible(viewContainer.id) || !layoutService.hasFocus(Parts.SIDEBAR_PART)) { </del> <ins> case ViewContainerLocation.AuxiliaryBar: case ViewContainerLocation.Sidebar: { const part = viewContainerLocation === ViewContainerLocation.Sidebar ? Parts.SIDEBAR_PART : Parts.AUXILIARYBAR_PART; if (!viewsService.isViewContainerVisible(viewContainer.id) || !layoutService.hasFocus(part)) { </ins> await viewsService.openViewContainer(viewContainer.id, true); } else { editorGroupService.activeGroup.focus(); } break; <ins> } </ins> case ViewContainerLocation.Panel: if (!viewsService.isViewContainerVisible(viewContainer.id) || !layoutService.hasFocus(Parts.PANEL_PART)) { await viewsService.openViewContainer(viewContainer.id, true);


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

throw new Error(`Call not found: ${command}`); } <del> if (arg) { const uri = URI.revive(arg); </del> <ins> if (Array.isArray(arg) && arg.length > 0) { const uri = URI.revive(arg[0]); </ins> this.logService.trace('URLHandlerRouter#routeCall() with URI argument', uri.toString(true));


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

return value.content; } } catch (parseError) { <ins> // We may not be able to parse it, but we keep the secret in the keychain anyway just in case // it decrypts correctly in the future. </ins> this.logService.error(parseError); <del> // If we can't parse the decrypted value, then it's not a valid secret so we should try to delete it try { await this.credentialsService.deletePassword(fullKey, key); } catch (e) { this.logService.error(e); } </del> throw new Error('Unable to parse decrypted password'); } }


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.74.2 OS Version: macOS 12.6.2 Steps to Reproduce: an extension and specify a relative path to an in the in png format, and specify repository as . (Our repository is private) get a warning , despite the icon showing correctly in the marketplace and the VS Code extension manager (We also have images in our that we hosted externally. Our repository is private after all). Extension:
I get the same warning ! despite my fields being defined as Source: Interestingly the icon shows up in the marketplace just fine. !
I see the icon is served from the CDN now and we can remove the warning about the relative icon path. What about badges in the and images in the README markdown, are these also served from CDN?
Those are all served from the raw GitHub routes, this is why vsce needs to know what repository hosts the sources.
But the icon isn't, not anymore at least... Our repo is private, the icon works just fine and is uploaded along with the vsix and hosted in some CDN. Images in the readme are indeed served directly so will require this check or an absolute URLs.
Ah! This is just the workbench linter. I also forgot that we actually show the icons served directly from the MP, not GH. Sorry about the confusion, thanks for following up This warning is unnecessary by now, let's remove it.

const embeddedSvgsNotValid = l10n.t("Embedded SVGs are not a valid image source."); const dataUrlsNotValid = l10n.t("Data URLs are not a valid image source."); const relativeUrlRequiresHttpsRepository = l10n.t("Relative image URLs require a repository with HTTPS protocol to be specified in the package.json."); <del> const relativeIconUrlRequiresHttpsRepository = l10n.t("An icon requires a repository with HTTPS protocol to be specified in this package.json."); </del> const relativeBadgeUrlRequiresHttpsRepository = l10n.t("Relative badge URLs require a repository with HTTPS protocol to be specified in this package.json."); const apiProposalNotListed = l10n.t("This proposal cannot be used because for this extension the product defines a fixed set of API proposals. You can test your extension but before publishing you MUST reach out to the VS Code team."); const implicitActivationEvent = l10n.t("This activation event cannot be explicitly listed by your extension.");


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.74.2 OS Version: macOS 12.6.2 Steps to Reproduce: an extension and specify a relative path to an in the in png format, and specify repository as . (Our repository is private) get a warning , despite the icon showing correctly in the marketplace and the VS Code extension manager (We also have images in our that we hosted externally. Our repository is private after all). Extension:
I get the same warning ! despite my fields being defined as Source: Interestingly the icon shows up in the marketplace just fine. !
I see the icon is served from the CDN now and we can remove the warning about the relative icon path. What about badges in the and images in the README markdown, are these also served from CDN?
Those are all served from the raw GitHub routes, this is why vsce needs to know what repository hosts the sources.
But the icon isn't, not anymore at least... Our repo is private, the icon works just fine and is uploaded along with the vsix and hosted in some CDN. Images in the readme are indeed served directly so will require this check or an absolute URLs.
Ah! This is just the workbench linter. I also forgot that we actually show the icons served directly from the MP, not GH. Sorry about the confusion, thanks for following up This warning is unnecessary by now, let's remove it.

diagnostics.push(new Diagnostic(range, dataUrlsNotValid, DiagnosticSeverity.Warning)); } <del> if (!hasScheme && !info.hasHttpsRepository) { </del> <ins> if (!hasScheme && !info.hasHttpsRepository && context !== Context.ICON) { </ins> const range = new Range(document.positionAt(begin), document.positionAt(end)); const message = (() => { switch (context) { <del> case Context.ICON: return relativeIconUrlRequiresHttpsRepository; </del> case Context.BADGE: return relativeBadgeUrlRequiresHttpsRepository; default: return relativeUrlRequiresHttpsRepository; }


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

import { ExtHostUriOpeners } from 'vs/workbench/api/common/extHostUriOpener'; import { IExtHostSecretState } from 'vs/workbench/api/common/extHostSecretState'; import { IExtHostEditorTabs } from 'vs/workbench/api/common/extHostEditorTabs'; <del> import { IExtHostTelemetry, isNewAppInstall } from 'vs/workbench/api/common/extHostTelemetry'; </del> <ins> import { ExtHostTelemetryLogger, IExtHostTelemetry, isNewAppInstall } from 'vs/workbench/api/common/extHostTelemetry'; </ins> import { ExtHostNotebookKernels } from 'vs/workbench/api/common/extHostNotebookKernels'; import { TextSearchCompleteMessageType } from 'vs/workbench/services/search/common/searchExtTypes'; import { ExtHostNotebookRenderers } from 'vs/workbench/api/common/extHostNotebookRenderers';


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

get isNewAppInstall() { return isNewAppInstall(initData.telemetryInfo.firstSessionDate); }, <del> createTelemetryLogger(appender: vscode.TelemetrySender): vscode.TelemetryLogger { </del> <ins> createTelemetryLogger(sender: vscode.TelemetrySender): vscode.TelemetryLogger { </ins> checkProposedApiEnabled(extension, 'telemetryLogger'); <del> return extHostTelemetry.instantiateLogger(extension, appender); </del> <ins> ExtHostTelemetryLogger.validateSender(sender); return extHostTelemetry.instantiateLogger(extension, sender); </ins> }, openExternal(uri: URI, options?: { allowContributedOpeners?: boolean | string }) { return extHostWindow.openUri(uri, {


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

} export class ExtHostTelemetryLogger { <del> private _appender: vscode.TelemetrySender; </del> <ins> static validateSender(sender: vscode.TelemetrySender): void { if (typeof sender !== 'object') { throw new TypeError('TelemetrySender argument is invalid'); } if (typeof sender.sendEventData !== 'function') { throw new TypeError('TelemetrySender.sendEventData must be a function'); } if (typeof sender.sendErrorData !== 'function') { throw new TypeError('TelemetrySender.sendErrorData must be a function'); } if (typeof sender.flush !== 'undefined' && typeof sender.flush !== 'function') { throw new TypeError('TelemetrySender.flush must be a function or undefined'); } } private readonly _sender: vscode.TelemetrySender; </ins> private readonly _onDidChangeEnableStates = new Emitter<vscode.TelemetryLogger>(); <del> private _telemetryEnablements: { isUsageEnabled: boolean; isErrorsEnabled: boolean }; private _apiObject: vscode.TelemetryLogger | undefined; </del> private readonly _ignoreBuiltinCommonProperties: boolean; private readonly _additionalCommonProperties: Record<string, any> | undefined; public readonly ignoreUnhandledExtHostErrors: boolean; <ins> private _telemetryEnablements: { isUsageEnabled: boolean; isErrorsEnabled: boolean }; private _apiObject: vscode.TelemetryLogger | undefined; </ins> constructor( sender: vscode.TelemetrySender, options: vscode.TelemetryLoggerOptions | undefined,


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

this.ignoreUnhandledExtHostErrors = options?.ignoreUnhandledErrors ?? false; this._ignoreBuiltinCommonProperties = options?.ignoreBuiltInCommonProperties ?? false; this._additionalCommonProperties = options?.additionalCommonProperties; <del> this._appender = sender; </del> <ins> this._sender = sender; </ins> this._telemetryEnablements = { isUsageEnabled: telemetryEnablements.isUsageEnabled, isErrorsEnabled: telemetryEnablements.isErrorsEnabled }; }


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

} data = this.mixInCommonPropsAndCleanData(data || {}); if (!this._inLoggingOnlyMode) { <del> this._appender.sendEventData(eventName, data); </del> <ins> this._sender.sendEventData(eventName, data); </ins> } this._logger.trace(eventName, data); }


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

this.logEvent(eventNameOrException, data); } else { // TODO @lramos15, implement cleaning for and logging for this case <del> this._appender.sendErrorData(eventNameOrException, data); </del> <ins> this._sender.sendErrorData(eventNameOrException, data); </ins> } }


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

} dispose(): void { <del> if (this._appender?.flush) { this._appender.flush(); </del> <ins> if (this._sender?.flush) { this._sender.flush(); </ins> } } }


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

import { ITelemetryInfo, TelemetryLevel } from 'vs/platform/telemetry/common/telemetry'; import { TestTelemetryLoggerService } from 'vs/platform/telemetry/test/common/telemetryLogAppender.test'; import { IExtHostInitDataService } from 'vs/workbench/api/common/extHostInitDataService'; <del> import { ExtHostTelemetry } from 'vs/workbench/api/common/extHostTelemetry'; </del> <ins> import { ExtHostTelemetry, ExtHostTelemetryLogger } from 'vs/workbench/api/common/extHostTelemetry'; </ins> import { IEnvironment } from 'vs/workbench/services/extensions/common/extensionHostProtocol'; import { mock } from 'vs/workbench/test/common/workbenchTestServices'; import type { TelemetrySender } from 'vscode';


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

return logger; }; <ins> test('Validate sender instances', function () { assert.throws(() => ExtHostTelemetryLogger.validateSender(<any>null)); assert.throws(() => ExtHostTelemetryLogger.validateSender(<any>1)); assert.throws(() => ExtHostTelemetryLogger.validateSender(<any>{})); assert.throws(() => { ExtHostTelemetryLogger.validateSender(<any>{ sendErrorData: () => { }, sendEventData: true }); }); assert.throws(() => { ExtHostTelemetryLogger.validateSender(<any>{ sendErrorData: 123, sendEventData: () => { }, }); }); assert.throws(() => { ExtHostTelemetryLogger.validateSender(<any>{ sendErrorData: () => { }, sendEventData: () => { }, flush: true }); }); }); </ins> test('Ensure logger gets proper telemetry level during initialization', function () { const extensionTelemetry = createExtHostTelemetry(); let config = extensionTelemetry.getTelemetryDetails();


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

'no-cached-data': { type: 'boolean' }, 'prof-startup-prefix': { type: 'string' }, 'prof-v8-extensions': { type: 'boolean' }, <del> 'disable-extensions': { type: 'boolean', deprecates: ['disableExtensions'], cat: 't', description: localize('disableExtensions', "Disable all installed extensions.") }, 'disable-extension': { type: 'string[]', cat: 't', args: 'ext-id', description: localize('disableExtension', "Disable an extension.") }, </del> <ins> 'disable-extensions': { type: 'boolean', deprecates: ['disableExtensions'], cat: 't', description: localize('disableExtensions', "Disable all installed extensions. This option is not persisted and is effective only when the command opens a new window.") }, 'disable-extension': { type: 'string[]', cat: 't', args: 'ext-id', description: localize('disableExtension', "Disable the provided extension. This option is not persisted and is effective only when the command opens a new window.") }, </ins> 'sync': { type: 'string', cat: 't', description: localize('turn sync', "Turn sync on or off."), args: ['on | off'] }, 'inspect-extensions': { type: 'string', allowEmptyValue: true, deprecates: ['debugPluginHost'], args: 'port', cat: 't', description: localize('inspect-extensions', "Allow debugging and profiling of extensions. Check the developer tools for the connection URI.") },


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

} } <del> this.layout({ metadataHeight: metadataLayoutChange, outputTotalHeight: outputLayoutChange }); </del> <ins> if (metadataLayoutChange || outputLayoutChange) { this.layout({ metadataHeight: metadataLayoutChange, outputTotalHeight: outputLayoutChange }); } </ins> })); }


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

/** Don't spam warnings */ private hasWarnedMissingSettings = false; <ins> private tocTreeDisposed = false; </ins> /** Persist the search query upon reloads */ private editorMemento: IEditorMemento<ISettingsEditor2State>;


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

'aria-label': localize('settings', "Settings"), })), this.viewState)); <ins> this.tocTreeDisposed = false; </ins> this._register(this.tocTree.onDidFocus(() => { this._currentFocusContext = SettingsFocusContext.TableOfContents;


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

this._register(this.tocTree.onDidBlur(() => { this.tocRowFocused.set(false); })); <ins> this._register(this.tocTree.onDidDispose(() => { this.tocTreeDisposed = true; })); </ins> } private applyFilter(filter: string) {


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

this.refreshTOCTree(); this.renderResultCountMessages(); this.refreshTree(); <del> } else { </del> <ins> } else if (!this.tocTreeDisposed) { </ins> // Leaving search mode this.tocTree.collapseAll(); this.refreshTOCTree();


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

import * as nls from 'vs/nls'; import { ContextKeyExpr, IContextKeyService, RawContextKey } from 'vs/platform/contextkey/common/contextkey'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; <del> import { KeybindingsRegistry } from 'vs/platform/keybinding/common/keybindingsRegistry'; </del> export class GhostTextController extends Disposable { public static readonly inlineSuggestionVisible = new RawContextKey<boolean>('inlineSuggestionVisible', false, nls.localize('inlineSuggestionVisible', "Whether an inline suggestion is visible")); public static readonly inlineSuggestionHasIndentation = new RawContextKey<boolean>('inlineSuggestionHasIndentation', false, nls.localize('inlineSuggestionHasIndentation', "Whether the inline suggestion starts with whitespace")); public static readonly inlineSuggestionHasIndentationLessThanTabSize = new RawContextKey<boolean>('inlineSuggestionHasIndentationLessThanTabSize', true, nls.localize('inlineSuggestionHasIndentationLessThanTabSize', "Whether the inline suggestion starts with whitespace that is less than what would be inserted by tab")); <del> /** * Enables to use Ctrl+Left to undo fully (partially) accepted inline completions (the completion is no longer visible then). */ public static readonly inlineSuggestionJustCommitted = new RawContextKey<boolean>('inlineSuggestionJustCommitted', false, nls.localize('inlineSuggestionJustCommitted', "Whether an inline suggestion just got committed")); </del> static ID = 'editor.contrib.ghostTextController';


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

public commitPartially(): void { this.activeModel?.commitInlineCompletionPartially(); <del> this.activeController?.value?.contextKeys.inlineSuggestionJustCommitted.set(true); </del> } public commit(): void { this.activeModel?.commitInlineCompletion(); <del> this.activeController?.value?.contextKeys.inlineSuggestionJustCommitted.set(true); </del> } public hide(): void {


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

public readonly inlineCompletionVisible = GhostTextController.inlineSuggestionVisible.bindTo(this.contextKeyService); public readonly inlineCompletionSuggestsIndentation = GhostTextController.inlineSuggestionHasIndentation.bindTo(this.contextKeyService); public readonly inlineCompletionSuggestsIndentationLessThanTabSize = GhostTextController.inlineSuggestionHasIndentationLessThanTabSize.bindTo(this.contextKeyService); <del> public readonly inlineSuggestionJustCommitted = GhostTextController.inlineSuggestionJustCommitted.bindTo(this.contextKeyService); </del> constructor(private readonly contextKeyService: IContextKeyService) { }


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

* Must be disposed as soon as the model detaches from the editor. */ export class ActiveGhostTextController extends Disposable { <del> public readonly contextKeys = new GhostTextContextKeys(this.contextKeyService); </del> <ins> private readonly contextKeys = new GhostTextContextKeys(this.contextKeyService); </ins> public readonly model = this._register(this.instantiationService.createInstance(GhostTextModel, this.editor)); public readonly widget = this._register(this.instantiationService.createInstance(GhostTextWidget, this.editor, this.model));


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

this._register(this.model.onDidChange(() => { this.updateContextKeys(); })); <del> this._register(this.editor.onDidChangeModelContent(() => { this.contextKeys.inlineSuggestionJustCommitted.reset(); })); this._register(this.editor.onDidChangeCursorPosition(() => { this.contextKeys.inlineSuggestionJustCommitted.reset(); })); </del> this.updateContextKeys(); }


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

id: 'editor.action.inlineSuggest.acceptNextWord', label: nls.localize('action.inlineSuggest.acceptNextWord', "Accept Next Word Of Inline Suggestion"), alias: 'Accept Next Word Of Inline Suggestion', <del> precondition: ContextKeyExpr.and(EditorContextKeys.writable, GhostTextController.inlineSuggestionVisible), kbOpts: { weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.RightArrow, } </del> <ins> precondition: EditorContextKeys.writable </ins> }); }


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

} } } <del> KeybindingsRegistry.registerKeybindingRule({ id: 'undo', weight: 1000, primary: KeyMod.CtrlCmd | KeyCode.LeftArrow, when: ContextKeyExpr.and(EditorContextKeys.writable, ContextKeyExpr.or(GhostTextController.inlineSuggestionVisible, GhostTextController.inlineSuggestionJustCommitted)), }); </del>


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

container.classList.add(this._className); } } <ins> protected override updateTooltip(): void { // NOOP, disable tooltip } </ins> } class StatusBarViewItem extends MenuEntryActionViewItem {


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

this.label.classList.add('inlineSuggestionStatusBarItemLabel'); } } <ins> protected override updateTooltip(): void { // NOOP, disable tooltip } </ins> } export class CustomizedMenuWorkbenchToolBar extends WorkbenchToolBar {


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

let debugKeybindingLabel = ''; viewsRegistry.registerViewWelcomeContent(WelcomeView.ID, { <del> content: localize( { key: 'runAndDebugAction', comment: [ '{0} will be replaced with a keybinding', 'Please do not translate the word "command", it is part of our internal syntax which must not change', '{Locked="](command:{1})"}' ] }, "[Run and Debug{0}](command:{1})", debugKeybindingLabel, DEBUG_START_COMMAND_ID), </del> <ins> content: `[${localize('runAndDebugAction', "Run and Debug")}${debugKeybindingLabel}](command:${DEBUG_START_COMMAND_ID})`, </ins> when: CONTEXT_DEBUGGERS_AVAILABLE, group: ViewContentGroups.Debug, // Allow inserting more buttons directly after this one (by setting order to 1).


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

}); viewsRegistry.registerViewWelcomeContent(WelcomeView.ID, { <del> content: localize( { key: 'detectThenRunAndDebug', comment: [ 'Please do not translate the word "command", it is part of our internal syntax which must not change', '{Locked="](command:{0})"}', ] }, "[Show all automatic debug configurations](command:{0}).", SELECT_AND_START_ID), </del> <ins> content: `[${localize('detectThenRunAndDebug', "Show all automatic debug configurations")}](command:${SELECT_AND_START_ID}).`, </ins> when: CONTEXT_DEBUGGERS_AVAILABLE, group: ViewContentGroups.Debug, order: 10


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

export const file = 'file'; export const untitled = 'untitled'; export const git = 'git'; <ins> export const github = 'github'; </ins> /** Live share scheme */ export const vsls = 'vsls'; export const walkThroughSnippet = 'walkThroughSnippet';


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

*/ export const disabledSchemes = new Set([ git, <del> vsls </del> <ins> vsls, github, </ins> ]);


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

"license": "MIT", "description": "Dependencies shared by all extensions", "dependencies": { <del> "typescript": "4.9.4" </del> <ins> "typescript": "4.9.5" </ins> }, "scripts": { "postinstall": "node ./postinstall.mjs"


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

dependencies: is-number "^7.0.0" <del> typescript@4.9.4: version "4.9.4" resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.9.4.tgz#a2a3d2756c079abda241d75f149df9d561091e78" integrity sha512-Uz+dTXYzxXXbsFpM86Wh3dKCxrQqUcVMxwU54orwlJjOpO3ao8L7j5lH+dWfTwgCwIuM9GQ2kvVotzYJMXTBZg== </del> <ins> typescript@4.9.5: version "4.9.5" resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.9.5.tgz#095979f9bcc0d09da324d58d03ce8f8374cbe65a" integrity sha512-1FXk9E2Hm+QzZQ7z+McJiHL4NW1F2EzMu9Nq9i3zAaGqibafqYwCVU6WyWAuyQRRzOlxou8xZSyXLEN8oKj24g== </ins> vscode-grammar-updater@^1.1.0: version "1.1.0"


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

this.searchWidget.setReplaceAllActionState(false); this.tree.setSelection([]); <ins> this.tree.setFocus([]); </ins> return this.viewModel.search(query) .then(onComplete, onError); }


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

this._register(this.actionBar.actionRunner.onDidRun((e: IRunEvent) => { // check for error if (e.error && !errors.isCancellationError(e.error)) { <del> this.notificationService.error(e.error); </del> <ins> this.notificationService.warn(e.error); </ins> } // log in telemetry


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

`script-src 'self' 'unsafe-eval' ${this._getScriptCspHashes(data).join(' ')} 'sha256-fh3TwPMflhsEIpR8g1OYTIMVWhXTLcjQ9kh2tIpmv54=' http://${remoteAuthority};`, // the sha is the same as in src/vs/workbench/services/extensions/worker/webWorkerExtensionHostIframe.html 'child-src 'self';', `frame-src 'self' https://*.vscode-cdn.net data:;`, <del> 'worker-src 'self' data:;', </del> <ins> 'worker-src 'self' data: blob:;', </ins> 'style-src 'self' 'unsafe-inline';', 'connect-src 'self' ws: wss: https:;', 'font-src 'self' blob:;',


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

<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ // https://github.com/microsoft/vscode/blob/6cb34eb22385bc93ab25aa2e5113f59c7a2299ac/src/vs/platform/extensions/common/extensionValidator.ts export interface IParsedVersion { hasCaret: boolean; hasGreaterEquals: boolean; majorBase: number; majorMustEqual: boolean; minorBase: number; minorMustEqual: boolean; patchBase: number; patchMustEqual: boolean; preRelease: string | null; } export interface INormalizedVersion { majorBase: number; majorMustEqual: boolean; minorBase: number; minorMustEqual: boolean; patchBase: number; patchMustEqual: boolean; notBefore: number; /* milliseconds timestamp, or 0 */ isMinimum: boolean; } const VERSION_REGEXP = /^(^|>=)?((d+)|x).((d+)|x).((d+)|x)(-.*)?$/; const NOT_BEFORE_REGEXP = /^-(d{4})(d{2})(d{2})$/; export function isValidVersionStr(version: string): boolean { version = version.trim(); return (version === '*' || VERSION_REGEXP.test(version)); } export function parseVersion(version: string): IParsedVersion | null { if (!isValidVersionStr(version)) { return null; } version = version.trim(); if (version === '*') { return { hasCaret: false, hasGreaterEquals: false, majorBase: 0, majorMustEqual: false, minorBase: 0, minorMustEqual: false, patchBase: 0, patchMustEqual: false, preRelease: null }; } const m = version.match(VERSION_REGEXP); if (!m) { return null; } return { hasCaret: m[1] === '^', hasGreaterEquals: m[1] === '>=', majorBase: m[2] === 'x' ? 0 : parseInt(m[2], 10), majorMustEqual: (m[2] === 'x' ? false : true), minorBase: m[4] === 'x' ? 0 : parseInt(m[4], 10), minorMustEqual: (m[4] === 'x' ? false : true), patchBase: m[6] === 'x' ? 0 : parseInt(m[6], 10), patchMustEqual: (m[6] === 'x' ? false : true), preRelease: m[8] || null }; } export function normalizeVersion(version: IParsedVersion | null): INormalizedVersion | null { if (!version) { return null; } const majorBase = version.majorBase; const majorMustEqual = version.majorMustEqual; const minorBase = version.minorBase; let minorMustEqual = version.minorMustEqual; const patchBase = version.patchBase; let patchMustEqual = version.patchMustEqual; if (version.hasCaret) { if (majorBase === 0) { patchMustEqual = false; } else { minorMustEqual = false; patchMustEqual = false; } } let notBefore = 0; if (version.preRelease) { const match = NOT_BEFORE_REGEXP.exec(version.preRelease); if (match) { const [, year, month, day] = match; notBefore = Date.UTC(Number(year), Number(month) - 1, Number(day)); } } return { majorBase: majorBase, majorMustEqual: majorMustEqual, minorBase: minorBase, minorMustEqual: minorMustEqual, patchBase: patchBase, patchMustEqual: patchMustEqual, isMinimum: version.hasGreaterEquals, notBefore, }; } </ins>


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

import * as MarkdownItType from 'markdown-it'; import { languages, workspace, Disposable, TextDocument, Uri, Diagnostic, Range, DiagnosticSeverity, Position, env, l10n } from 'vscode'; <ins> import { INormalizedVersion, normalizeVersion, parseVersion } from './extensionEngineValidation'; </ins> const product = JSON.parse(fs.readFileSync(path.join(env.appRoot, 'product.json'), { encoding: 'utf-8' })); const allowedBadgeProviders: string[] = (product.extensionAllowedBadgeProviders || []).map((s: string) => s.toLowerCase());


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

const apiProposalNotListed = l10n.t("This proposal cannot be used because for this extension the product defines a fixed set of API proposals. You can test your extension but before publishing you MUST reach out to the VS Code team."); const implicitActivationEvent = l10n.t("This activation event cannot be explicitly listed by your extension."); const redundantImplicitActivationEvent = l10n.t("This activation event can be removed as VS Code generates these automatically from your package.json contribution declarations."); <ins> const bumpEngineForImplicitActivationEvents = l10n.t("This activation event can be removed for extensions targeting engine version ^1.75 as VS Code will generate these automatically from your package.json contribution declarations."); </ins> const starActivation = l10n.t("Using '*' activation is usually a bad idea as it impacts performance."); enum Context {


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

hasHttpsRepository: boolean; repository: Uri; implicitActivationEvents: Set<string> | undefined; <ins> engineVersion: INormalizedVersion | null; </ins> } export class ExtensionLinter {


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

if (activationEventsNode?.type === 'array' && activationEventsNode.children) { for (const activationEventNode of activationEventsNode.children) { const activationEvent = getNodeValue(activationEventNode); <ins> const isImplicitActivationSupported = info.engineVersion && info.engineVersion?.majorBase >= 1 && info.engineVersion?.minorBase >= 75; </ins> // Redundant Implicit Activation if (info.implicitActivationEvents?.has(activationEvent) && redundantImplicitActivationEventPrefixes.some((prefix) => activationEvent.startsWith(prefix))) { const start = document.positionAt(activationEventNode.offset); const end = document.positionAt(activationEventNode.offset + activationEventNode.length); <del> diagnostics.push(new Diagnostic(new Range(start, end), redundantImplicitActivationEvent, DiagnosticSeverity.Warning)); </del> <ins> const message = isImplicitActivationSupported ? redundantImplicitActivationEvent : bumpEngineForImplicitActivationEvents; diagnostics.push(new Diagnostic(new Range(start, end), message, isImplicitActivationSupported ? DiagnosticSeverity.Warning : DiagnosticSeverity.Information)); </ins> } // Reserved Implicit Activation for (const implicitActivationEventPrefix of reservedImplicitActivationEventPrefixes) { <del> if (activationEvent.startsWith(implicitActivationEventPrefix)) { </del> <ins> if (isImplicitActivationSupported && activationEvent.startsWith(implicitActivationEventPrefix)) { </ins> const start = document.positionAt(activationEventNode.offset); const end = document.positionAt(activationEventNode.offset + activationEventNode.length); diagnostics.push(new Diagnostic(new Range(start, end), implicitActivationEvent, DiagnosticSeverity.Error));


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

private readPackageJsonInfo(folder: Uri, tree: JsonNode | undefined) { const engine = tree && findNodeAtLocation(tree, ['engines', 'vscode']); <ins> const parsedEngineVersion = engine?.type === 'string' ? normalizeVersion(parseVersion(engine.value)) : null; </ins> const repo = tree && findNodeAtLocation(tree, ['repository', 'url']); const uri = repo && parseUri(repo.value); const activationEvents = tree && parseImplicitActivationEvents(tree);


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

isExtension: !!(engine && engine.type === 'string'), hasHttpsRepository: !!(repo && repo.type === 'string' && repo.value && uri && uri.scheme.toLowerCase() === 'https'), repository: uri!, <del> implicitActivationEvents: activationEvents </del> <ins> implicitActivationEvents: activationEvents, engineVersion: parsedEngineVersion </ins> }; const str = folder.toString(); const oldInfo = this.folderToPackageJsonInfo[str];


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

} foundAnyProviders = true; counter++; <del> provider.provideTasks(validTypes).then((taskSet: ITaskSet) => { </del> <ins> raceTimeout(provider.provideTasks(validTypes).then((taskSet: ITaskSet) => { </ins> // Check that the tasks provided are of the correct type for (const task of taskSet.tasks) { if (task.type !== this._providerTypes.get(handle)) {


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

} } return done(taskSet); <del> }, error); </del> <ins> }, error), 5000, () => { // onTimeout console.error('Timed out getting tasks from ', providerType); done(undefined); }); </ins> } } if (!foundAnyProviders) {


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

return new Map(); } await this._waitForSupportedExecutions; <del> if (this._workspaceTasksPromise) { </del> <ins> // The build task might be run before folder open. On folder open, we need to update the tasks so that // all tasks are parsed. #173384 if (runSource !== TaskRunSource.FolderOpen && this._workspaceTasksPromise) { </ins> return this._workspaceTasksPromise; } return this._updateWorkspaceTasks(runSource);


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

protected _taskSystemInfos: Map<string, ITaskSystemInfo[]>; protected _workspaceTasksPromise?: Promise<Map<string, IWorkspaceFolderTaskResult>>; <ins> protected readonly _whenTaskSystemReady: Promise<void>; </ins> protected _taskSystem?: ITaskSystem; protected _taskSystemListeners?: IDisposable[] = [];


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

@IInstantiationService private readonly _instantiationService: IInstantiationService ) { super(); <ins> this._whenTaskSystemReady = Event.toPromise(this.onDidChangeTaskSystemInfo); </ins> this._workspaceTasksPromise = undefined; this._taskSystem = undefined; this._taskSystemListeners = undefined;