jiebi/CodeConvo huggingface dataset:
Code change:
Update: reproduces in web + desktop Steps to Reproduce: a Codespace until it is loaded various activity bar items that open menus (gear menu, accounts, main menu, home indicator) = somehow the accounts menu only opens for me after a delay, as if something was resolved when clicking? !
This still reproduces
does this still repro? maybe its imperceptible to me?
Yeah still seems slightly delayed to me, can we not check the code and see if a longer running promise prevents the menu from showing?
looks like we fetch session info every time, so this probably adds some delay. maybe this can be cached and updated separately
Yeah that seems like a reasonable ask since it goes to the extension host and back, today.
This issue has existed since 2 years! But only recently have I encountered this.

Related discussion:
text: import { ICredentialsService } from 'vs/platform/credentials/common/credentials'; import { IUserDataProfileService } from 'vs/workbench/services/userDataProfile/common/userDataProfile'; import { StandardMouseEvent } from 'vs/base/browser/mouseEvent'; <ins> import { ILogService } from 'vs/platform/log/common/log'; </ins> export class ViewContainerActivityAction extends ActivityAction {
Code change:
Update: reproduces in web + desktop Steps to Reproduce: a Codespace until it is loaded various activity bar items that open menus (gear menu, accounts, main menu, home indicator) = somehow the accounts menu only opens for me after a delay, as if something was resolved when clicking? !
This still reproduces
does this still repro? maybe its imperceptible to me?
Yeah still seems slightly delayed to me, can we not check the code and see if a longer running promise prevents the menu from showing?
looks like we fetch session info every time, so this probably adds some delay. maybe this can be cached and updated separately
Yeah that seems like a reasonable ask since it goes to the extension host and back, today.
This issue has existed since 2 years! But only recently have I encountered this.

Related discussion:
text: static readonly ACCOUNTS_VISIBILITY_PREFERENCE_KEY = 'workbench.activity.showAccounts'; <ins> private readonly groupedAccounts: Map<string, (AuthenticationSessionAccount & { canSignOut: boolean })[]> = new Map(); private readonly problematicProviders: Set<string> = new Set(); private initialized = false; private sessionFromEmbedder = getCurrentAuthenticationSessionInfo(this.credentialsService, this.productService); </ins> constructor( action: ActivityAction, contextMenuActionsProvider: () => IAction[],
Code change:
Update: reproduces in web + desktop Steps to Reproduce: a Codespace until it is loaded various activity bar items that open menus (gear menu, accounts, main menu, home indicator) = somehow the accounts menu only opens for me after a delay, as if something was resolved when clicking? !
This still reproduces
does this still repro? maybe its imperceptible to me?
Yeah still seems slightly delayed to me, can we not check the code and see if a longer running promise prevents the menu from showing?
looks like we fetch session info every time, so this probably adds some delay. maybe this can be cached and updated separately
Yeah that seems like a reasonable ask since it goes to the extension host and back, today.
This issue has existed since 2 years! But only recently have I encountered this.

Related discussion:
text: return actions; } <ins> //#endregion //#region groupedAccounts helpers private async addOrUpdateAccount(providerId: string, account: AuthenticationSessionAccount): Promise<void> { const accounts = this.groupedAccounts.get(providerId); const existingAccount = accounts?.find(a => a.id === account.id); if (existingAccount) { if (existingAccount.label !== account.label) { existingAccount.label = account.label; } return; } const sessionFromEmbedder = await this.sessionFromEmbedder; // If the session stored from the embedder allows sign out, then we can treat it and all others as sign out-able let canSignOut = !!sessionFromEmbedder?.canSignOut; if (!canSignOut) { if (sessionFromEmbedder?.id) { const sessions = (await this.authenticationService.getSessions(providerId)).filter(s => s.account.id === account.id); canSignOut = !sessions.some(s => s.id === sessionFromEmbedder.id); } else { // The default if we don't have a session from the embedder is to allow sign out canSignOut = true; } } if (!accounts) { this.groupedAccounts.set(providerId, [{ ...account, canSignOut }]); return; } accounts.push({ ...account, canSignOut }); } private removeAccount(providerId: string, account: AuthenticationSessionAccount): void { const accounts = this.groupedAccounts.get(providerId); if (!accounts) { return; } const index = accounts.findIndex(a => a.id === account.id); if (index === -1) { return; } accounts.splice(index, 1); if (accounts.length === 0) { this.groupedAccounts.delete(providerId); } } private async addAccountsFromProvider(providerId: string): Promise<void> { try { const sessions = await this.authenticationService.getSessions(providerId); this.problematicProviders.delete(providerId); const result = await Promise.allSettled(sessions.map(s => this.addOrUpdateAccount(providerId, s.account))); for (const r of result) { if (r.status === 'rejected') { this.logService.error(r.reason); } } } catch (e) { this.logService.error(e); this.problematicProviders.add(providerId); } } //#endregion </ins> } export interface IProfileActivity extends IActivity {
Code change:
Update: reproduces in web + desktop Steps to Reproduce: a Codespace until it is loaded various activity bar items that open menus (gear menu, accounts, main menu, home indicator) = somehow the accounts menu only opens for me after a delay, as if something was resolved when clicking? !
This still reproduces
does this still repro? maybe its imperceptible to me?
Yeah still seems slightly delayed to me, can we not check the code and see if a longer running promise prevents the menu from showing?
looks like we fetch session info every time, so this probably adds some delay. maybe this can be cached and updated separately
Yeah that seems like a reasonable ask since it goes to the extension host and back, today.
This issue has existed since 2 years! But only recently have I encountered this.

Related discussion:
text: import { Event } from 'vs/base/common/event'; import { createDecorator } from 'vs/platform/instantiation/common/instantiation'; <ins> export interface AuthenticationSessionAccount { label: string; id: string; } </ins> export interface AuthenticationSession { id: string; accessToken: string; <del> account: { label: string; id: string; }; </del> <ins> account: AuthenticationSessionAccount; </ins> scopes: ReadonlyArray<string>; idToken?: string; }
Code change:
The find widget's update history is wrapped in a delayer promise which can cause an unhandled promise rejection when the widget is getting disposed of if the delayer's completion promise hasn't been cleanup up. This can happen if the editor is closed before the find widget has time to finish closing. This change addressed the issue by handling the rejected promise returned by . <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.51.1 OS Version: macOS Steps to Reproduce: new editor. -F to open the find widget. to close the find widget and quickly close the editor before the widget has time to close.

Related discussion:
text: } private _delayedUpdateHistory() { <del> this._updateHistoryDelayer.trigger(this._updateHistory.bind(this)); </del> <ins> this._updateHistoryDelayer.trigger(this._updateHistory.bind(this)).then(undefined, onUnexpectedError); </ins> } private _updateHistory() {
Code change:
We have been seeing a bunch of remote issues where the remote extension host burns a lot of CPU. I think it is caused by our port scanning code, which executes even if the setting is false. See Possible issues: / Other: ? ? ? *
Looks like we need to work on our indentation and ensuring that we break lines once they go past the edge of the screen for the sake of readability
I could reproduce some increased CPU usage of the remote extension host using the project linked to i.e.
In insiders, you can now temporarily disable the port scanning code by adding this line to your .bashrc file, then restarting the VS Code server on your remote:
Once we have an insiders build I'll start commenting in each of the issues asking folks to try out the workaround in insiders.
Keeping open for now so that the issue can be found more easily.
Closing since the fix is available in insiders.
Verified that cpu usage was reasonable when running the petclinic app

Related discussion:
text: import { exec } from 'child_process'; import * as resources from 'vs/base/common/resources'; import * as fs from 'fs'; <ins> import * as pfs from 'vs/base/node/pfs'; </ins> import { isLinux } from 'vs/base/common/platform'; import { IExtHostTunnelService, TunnelDto } from 'vs/workbench/api/common/extHostTunnelService'; import { asPromise } from 'vs/base/common/async'; import { Event, Emitter } from 'vs/base/common/event'; import { TunnelOptions, TunnelCreationOptions } from 'vs/platform/remote/common/tunnel'; import { IExtensionDescription } from 'vs/platform/extensions/common/extensions'; <ins> import { promisify } from 'util'; import { MovingAverage } from 'vs/base/common/numbers'; </ins> class ExtensionTunnel implements vscode.Tunnel { private _onDispose: Emitter<void> = new Emitter();
Code change:
We have been seeing a bunch of remote issues where the remote extension host burns a lot of CPU. I think it is caused by our port scanning code, which executes even if the setting is false. See Possible issues: / Other: ? ? ? *
Looks like we need to work on our indentation and ensuring that we break lines once they go past the edge of the screen for the sake of readability
I could reproduce some increased CPU usage of the remote extension host using the project linked to i.e.
In insiders, you can now temporarily disable the port scanning code by adding this line to your .bashrc file, then restarting the VS Code server on your remote:
Once we have an insiders build I'll start commenting in each of the issues asking folks to try out the workaround in insiders.
Keeping open for now so that the issue can be found more easily.
Closing since the fix is available in insiders.
Verified that cpu usage was reasonable when running the petclinic app

Related discussion:
text: ) { super(); this._proxy = extHostRpc.getProxy(MainContext.MainThreadTunnelService); <del> if (initData.remote.isRemote && initData.remote.authority && !process.env['VSCODE_DISABLE_PROC_READING']) { </del> <ins> if (initData.remote.isRemote && initData.remote.authority) { </ins> this.registerCandidateFinder(); } }
Code change:
We have been seeing a bunch of remote issues where the remote extension host burns a lot of CPU. I think it is caused by our port scanning code, which executes even if the setting is false. See Possible issues: / Other: ? ? ? *
Looks like we need to work on our indentation and ensuring that we break lines once they go past the edge of the screen for the sake of readability
I could reproduce some increased CPU usage of the remote extension host using the project linked to i.e.
In insiders, you can now temporarily disable the port scanning code by adding this line to your .bashrc file, then restarting the VS Code server on your remote:
Once we have an insiders build I'll start commenting in each of the issues asking folks to try out the workaround in insiders.
Keeping open for now so that the issue can be found more easily.
Closing since the fix is available in insiders.
Verified that cpu usage was reasonable when running the petclinic app

Related discussion:
text: return this._proxy.$getTunnels(); } <del> registerCandidateFinder(): void { // Every two seconds, scan to see if the candidate ports have changed; if (isLinux) { let oldPorts: { host: string, port: number, detail: string }[] | undefined = undefined; setInterval(async () => { const newPorts = await this.findCandidatePorts(); if (!oldPorts || (JSON.stringify(oldPorts) !== JSON.stringify(newPorts))) { oldPorts = newPorts; this._proxy.$onFoundNewCandidates(oldPorts.filter(async (candidate) => await this._showCandidatePort(candidate.host, candidate.port, candidate.detail))); return; } }, 2000); </del> <ins> private calculateDelay(movingAverage: number) { // Some local testing indicated that the moving average might be between 50-100 ms. return Math.max(movingAverage * 20, 2000); } async registerCandidateFinder(): Promise<void> { // Regularly scan to see if the candidate ports have changed. if (!isLinux) { return; } let movingAverage = new MovingAverage(); let oldPorts: { host: string, port: number, detail: string }[] | undefined = undefined; while (1) { const startTime = new Date().getTime(); const newPorts = await this.findCandidatePorts(); const timeTaken = new Date().getTime() - startTime; movingAverage.update(timeTaken); if (!oldPorts || (JSON.stringify(oldPorts) !== JSON.stringify(newPorts))) { oldPorts = newPorts; await this._proxy.$onFoundNewCandidates(oldPorts.filter(async (candidate) => await this._showCandidatePort(candidate.host, candidate.port, candidate.detail))); } await (new Promise<void>(resolve => setTimeout(() => resolve(), this.calculateDelay(movingAverage.value)))); </ins> } }
Code change:
We have been seeing a bunch of remote issues where the remote extension host burns a lot of CPU. I think it is caused by our port scanning code, which executes even if the setting is false. See Possible issues: / Other: ? ? ? *
Looks like we need to work on our indentation and ensuring that we break lines once they go past the edge of the screen for the sake of readability
I could reproduce some increased CPU usage of the remote extension host using the project linked to i.e.
In insiders, you can now temporarily disable the port scanning code by adding this line to your .bashrc file, then restarting the VS Code server on your remote:
Once we have an insiders build I'll start commenting in each of the issues asking folks to try out the workaround in insiders.
Keeping open for now so that the issue can be found more easily.
Closing since the fix is available in insiders.
Verified that cpu usage was reasonable when running the petclinic app

Related discussion:
text: let tcp: string = ''; let tcp6: string = ''; try { <del> tcp = fs.readFileSync('/proc/net/tcp', 'utf8'); tcp6 = fs.readFileSync('/proc/net/tcp6', 'utf8'); </del> <ins> tcp = await pfs.readFile('/proc/net/tcp', 'utf8'); tcp6 = await pfs.readFile('/proc/net/tcp6', 'utf8'); </ins> } catch (e) { // File reading error. No additional handling needed. }
Code change:
We have been seeing a bunch of remote issues where the remote extension host burns a lot of CPU. I think it is caused by our port scanning code, which executes even if the setting is false. See Possible issues: / Other: ? ? ? *
Looks like we need to work on our indentation and ensuring that we break lines once they go past the edge of the screen for the sake of readability
I could reproduce some increased CPU usage of the remote extension host using the project linked to i.e.
In insiders, you can now temporarily disable the port scanning code by adding this line to your .bashrc file, then restarting the VS Code server on your remote:
Once we have an insiders build I'll start commenting in each of the issues asking folks to try out the workaround in insiders.
Keeping open for now so that the issue can be found more easily.
Closing since the fix is available in insiders.
Verified that cpu usage was reasonable when running the petclinic app

Related discussion:
text: }); })); <del> const procChildren = fs.readdirSync('/proc'); const processes: { pid: number, cwd: string, cmd: string }[] = []; </del> <ins> const procChildren = await pfs.readdir('/proc'); const processes: { pid: number, cwd: string, cmd: string }[] = []; </ins> for (let childName of procChildren) { try { const pid: number = Number(childName); const childUri = resources.joinPath(URI.file('/proc'), childName); <del> const childStat = fs.statSync(childUri.fsPath); </del> <ins> const childStat = await pfs.stat(childUri.fsPath); </ins> if (childStat.isDirectory() && !isNaN(pid)) { <del> const cwd = fs.readlinkSync(resources.joinPath(childUri, 'cwd').fsPath); const cmd = fs.readFileSync(resources.joinPath(childUri, 'cmdline').fsPath, 'utf8'); </del> <ins> const cwd = await promisify(fs.readlink)(resources.joinPath(childUri, 'cwd').fsPath); const cmd = await pfs.readFile(resources.joinPath(childUri, 'cmdline').fsPath, 'utf8'); </ins> processes.push({ pid, cwd, cmd }); } } catch (e) {
Code change:
VSCode Version: 1.52.1 OS Version: Windows 10 Steps to Reproduce: a WebView tab, such as the Markdown preview. click on it in the Open Editors Section, and select "Select for Compare". click on any other item and select "Compare with Selected". ! Does this issue occur when all extensions are disabled?: Yes
//cc not sure we have a context key to use here already
Code pointer We would need to use that context key for all the compare context menu actions in the Open Editors view
isn't this just a matter of using for this command? We seem to be using this also to limit commands such as "Copy"?
you are correct, I checked and this is indeed the context key we needed here.
Will have to revert this due to
PR:
/verified

Related discussion:
text: // Menu registration - open editors <ins> const isFileOrUntitledResourceContextKey = ContextKeyExpr.or(ResourceContextKey.IsFileSystemResource, ResourceContextKey.Scheme.isEqualTo(Schemas.untitled)); </ins> const openToSideCommand = { id: OPEN_TO_SIDE_COMMAND_ID, title: nls.localize('openToSide', "Open to the Side")
Code change:
VSCode Version: 1.52.1 OS Version: Windows 10 Steps to Reproduce: a WebView tab, such as the Markdown preview. click on it in the Open Editors Section, and select "Select for Compare". click on any other item and select "Compare with Selected". ! Does this issue occur when all extensions are disabled?: Yes
//cc not sure we have a context key to use here already
Code pointer We would need to use that context key for all the compare context menu actions in the Open Editors view
isn't this just a matter of using for this command? We seem to be using this also to limit commands such as "Copy"?
you are correct, I checked and this is indeed the context key we needed here.
Will have to revert this due to
PR:
/verified

Related discussion:
text: group: 'navigation', order: 10, command: openToSideCommand, <del> when: ContextKeyExpr.or(ResourceContextKey.IsFileSystemResource, ResourceContextKey.Scheme.isEqualTo(Schemas.untitled)) </del> <ins> when: isFileOrUntitledResourceContextKey </ins> }); MenuRegistry.appendMenuItem(MenuId.OpenEditorsContext, {
Code change:
VSCode Version: 1.52.1 OS Version: Windows 10 Steps to Reproduce: a WebView tab, such as the Markdown preview. click on it in the Open Editors Section, and select "Select for Compare". click on any other item and select "Compare with Selected". ! Does this issue occur when all extensions are disabled?: Yes
//cc not sure we have a context key to use here already
Code pointer We would need to use that context key for all the compare context menu actions in the Open Editors view
isn't this just a matter of using for this command? We seem to be using this also to limit commands such as "Copy"?
you are correct, I checked and this is indeed the context key we needed here.
Will have to revert this due to
PR:
/verified

Related discussion:
text: group: '3_compare', order: 20, command: compareResourceCommand, <del> when: ContextKeyExpr.and(ResourceContextKey.HasResource, ResourceSelectedForCompareContext, WorkbenchListDoubleSelection.toNegated()) </del> <ins> when: ContextKeyExpr.and(ResourceContextKey.HasResource, ResourceSelectedForCompareContext, isFileOrUntitledResourceContextKey, WorkbenchListDoubleSelection.toNegated()) </ins> }); const selectForCompareCommand = {
Code change:
VSCode Version: 1.52.1 OS Version: Windows 10 Steps to Reproduce: a WebView tab, such as the Markdown preview. click on it in the Open Editors Section, and select "Select for Compare". click on any other item and select "Compare with Selected". ! Does this issue occur when all extensions are disabled?: Yes
//cc not sure we have a context key to use here already
Code pointer We would need to use that context key for all the compare context menu actions in the Open Editors view
isn't this just a matter of using for this command? We seem to be using this also to limit commands such as "Copy"?
you are correct, I checked and this is indeed the context key we needed here.
Will have to revert this due to
PR:
/verified

Related discussion:
text: group: '3_compare', order: 30, command: selectForCompareCommand, <del> when: ContextKeyExpr.and(ResourceContextKey.HasResource, WorkbenchListDoubleSelection.toNegated()) </del> <ins> when: ContextKeyExpr.and(ResourceContextKey.HasResource, isFileOrUntitledResourceContextKey, WorkbenchListDoubleSelection.toNegated()) </ins> }); const compareSelectedCommand = {
Code change:
VSCode Version: 1.52.1 OS Version: Windows 10 Steps to Reproduce: a WebView tab, such as the Markdown preview. click on it in the Open Editors Section, and select "Select for Compare". click on any other item and select "Compare with Selected". ! Does this issue occur when all extensions are disabled?: Yes
//cc not sure we have a context key to use here already
Code pointer We would need to use that context key for all the compare context menu actions in the Open Editors view
isn't this just a matter of using for this command? We seem to be using this also to limit commands such as "Copy"?
you are correct, I checked and this is indeed the context key we needed here.
Will have to revert this due to
PR:
/verified

Related discussion:
text: group: '3_compare', order: 30, command: compareSelectedCommand, <del> when: ContextKeyExpr.and(ResourceContextKey.HasResource, WorkbenchListDoubleSelection) </del> <ins> when: ContextKeyExpr.and(ResourceContextKey.HasResource, WorkbenchListDoubleSelection, isFileOrUntitledResourceContextKey) </ins> }); MenuRegistry.appendMenuItem(MenuId.OpenEditorsContext, {