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

Related discussion:
text: this._register(this.fileService.onDidFilesChange(e => this.onDidFilesChange(e))); } <del> private async onDidChangeProfiles(added: readonly IUserDataProfile[], removed: readonly IUserDataProfile[]): Promise<void> { </del> <ins> private async onDidChangeProfiles(added: readonly IUserDataProfile[]): Promise<void> { </ins> try { <del> await Promise.all(removed.map(profile => { this.extensionsProfileWatchDisposables.deleteAndDispose(profile.id); return this.removeExtensionsFromProfile(profile.extensionsResource); })); </del> if (added.length) { await Promise.all(added.map(profile => { this.extensionsProfileWatchDisposables.set(profile.id, combinedDisposable(
Code change:
I had a "Testing" profile with various remote extensions installed. I deleted it (while being in it) and then recreated it empty. I still found all remote menu contributions even though the profile should have been empty. Maybe switching profiles should ask to reload the window when extensions require so? Steps to Reproduce: fresh user data dir, fresh extensions dir create an empty profile install SSH extension notice how the remote explorer view appears delete the profile notice how the remote explorer view is still there, same as the status bar entry for remote
Another case from is interesting: I do not think using a profile is a good idea for when extensions require a window reload to be disabled. So you need to then probably ask the user to reload the window or do it automatically.
AFAIK every extension requires a window reload after being disabled (except for package-json only extensions). We cannot unload code from extensions and cannot enforce them not doing anything anymore. There we always reload the window or at least the extension host
While switching profiles we restart extension host. You say this is not enough to unload extensions? Also while trusting/untrusting a workspace.
No, only those that are activate with code loaded. Here are steps: fresh user data dir, fresh extensions dir create an empty profile install SSH extension notice how the remote explorer view appears delete the profile notice how the remote explorer view is still there, same as the status bar entry for remote
I see this can be reproduced with above steps. But Remote Explorer view disappears with switching profile. So I think this is a bug (either in views or profiles) when profile is deleted. But status bar entries always appear.

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

Related discussion:
text: this.logService.error(error); } } <del> try { if (this.profiles.length === 1) { await this.fileService.del(this.profilesHome, { recursive: true }); } else { await this.fileService.del(profile.location, { recursive: true }); } } catch (error) { this.logService.error(error); } </del> } async setProfileForWorkspace(workspaceIdentifier: IAnyWorkspaceIdentifier, profileToSet: IUserDataProfile): Promise<void> {
Code change:
Testing I am currently one commit behind the remote branch and I am able to successfully create a link without seeing any dialog. The way the test plan item is written it implies that in this scenario, I should see a dialog. Is that the case or did I misunderstood the test plan item?
Testing with while being a few commits behind, I get the following dialog: <img width="264" alt="image" src=""When I Cancel, I don't get a link. When I Pull & Copy I get a link that is seemingly unaffected by the pull. Why then require the pull? (I tested with incoming commits affecting the file I copy a link from.)
The link that is copied might point to a range that is invalidated by incoming commits, so we notify in order to avoid you copying a link that points to a different area in the file. But perhaps we should also offer a Copy Anyway option here.

Related discussion:
text: // If HEAD is not published, make sure it is && !repository?.state.HEAD?.upstream ) { <del> const publishBranch = vscode.l10n.t('Publish Branch'); </del> <ins> const publishBranch = vscode.l10n.t('Publish Branch & Copy Link'); </ins> const selection = await vscode.window.showInformationMessage( vscode.l10n.t('The current branch is not published to the remote. Would you like to publish your branch before copying a link?'), { modal: true },
Code change:
Testing I am currently one commit behind the remote branch and I am able to successfully create a link without seeing any dialog. The way the test plan item is written it implies that in this scenario, I should see a dialog. Is that the case or did I misunderstood the test plan item?
Testing with while being a few commits behind, I get the following dialog: <img width="264" alt="image" src=""When I Cancel, I don't get a link. When I Pull & Copy I get a link that is seemingly unaffected by the pull. Why then require the pull? (I tested with incoming commits affecting the file I copy a link from.)
The link that is copied might point to a range that is invalidated by incoming commits, so we notify in order to avoid you copying a link that points to a different area in the file. But perhaps we should also offer a Copy Anyway option here.

Related discussion:
text: } const uncommittedChanges = [...repository.state.workingTreeChanges, ...repository.state.indexChanges]; <del> if (uncommittedChanges.find((c) => c.uri.toString() === file.toString())) { </del> <ins> if (uncommittedChanges.find((c) => c.uri.toString() === file.toString()) && !repository.state.HEAD?.ahead && !repository.state.HEAD?.behind) { </ins> const commitChanges = vscode.l10n.t('Commit Changes'); const copyAnyway = vscode.l10n.t('Copy Anyway'); const selection = await vscode.window.showWarningMessage(
Code change:
Testing I am currently one commit behind the remote branch and I am able to successfully create a link without seeing any dialog. The way the test plan item is written it implies that in this scenario, I should see a dialog. Is that the case or did I misunderstood the test plan item?
Testing with while being a few commits behind, I get the following dialog: <img width="264" alt="image" src=""When I Cancel, I don't get a link. When I Pull & Copy I get a link that is seemingly unaffected by the pull. Why then require the pull? (I tested with incoming commits affecting the file I copy a link from.)
The link that is copied might point to a range that is invalidated by incoming commits, so we notify in order to avoid you copying a link that points to a different area in the file. But perhaps we should also offer a Copy Anyway option here.

Related discussion:
text: throw new vscode.CancellationError(); } } else if (repository.state.HEAD?.ahead) { <del> const pushCommits = vscode.l10n.t('Push Commits'); </del> <ins> const pushCommits = vscode.l10n.t('Push Commits & Copy Link'); </ins> const selection = await vscode.window.showInformationMessage( vscode.l10n.t('The current branch has unpublished commits. Would you like to push your commits before copying a link?'), { modal: true },
Code change:
Testing I am currently one commit behind the remote branch and I am able to successfully create a link without seeing any dialog. The way the test plan item is written it implies that in this scenario, I should see a dialog. Is that the case or did I misunderstood the test plan item?
Testing with while being a few commits behind, I get the following dialog: <img width="264" alt="image" src=""When I Cancel, I don't get a link. When I Pull & Copy I get a link that is seemingly unaffected by the pull. Why then require the pull? (I tested with incoming commits affecting the file I copy a link from.)
The link that is copied might point to a range that is invalidated by incoming commits, so we notify in order to avoid you copying a link that points to a different area in the file. But perhaps we should also offer a Copy Anyway option here.

Related discussion:
text: } await repository.push(); <ins> } else if (repository.state.HEAD?.behind) { const pull = vscode.l10n.t('Pull Changes & Copy Link'); const selection = await vscode.window.showInformationMessage( vscode.l10n.t('The current branch is not up to date. Would you like to pull before copying a link?'), { modal: true }, pull ); if (selection !== pull) { throw new vscode.CancellationError(); } await repository.pull(); </ins> } await repository.status();
Code change:
Repro: OSS trace logs window ! I don't have copilot installs in OSS so I wouldn't expect anything to happen here. Not sure what the 2 chars are.
Probably

Related discussion:
text: if (sessionData) { this._persistedSessions = this.deserializeChats(sessionData); const countsForLog = Object.keys(this._persistedSessions).length; <del> this.trace('constructor', `Restored ${countsForLog} persisted sessions`); </del> <ins> if (countsForLog > 0) { this.trace('constructor', `Restored ${countsForLog} persisted sessions`); } </ins> } else { this._persistedSessions = {}; <del> this.trace('constructor', 'No persisted sessions'); </del> } this._transferred = this.getTransferredSession();
Code change:
Repro: OSS trace logs window ! I don't have copilot installs in OSS so I wouldn't expect anything to happen here. Not sure what the 2 chars are.
Probably

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

Related discussion:
text: await this.configurationEditing.writeConfiguration(editableConfigurationTarget, { key, value }, { scopes: overrides, ...options }); switch (editableConfigurationTarget) { case EditableConfigurationTarget.USER_LOCAL: <del> if (this.applicationConfiguration && this.configurationRegistry.getConfigurationProperties()[key].scope === ConfigurationScope.APPLICATION) { </del> <ins> if (this.applicationConfiguration && this.configurationRegistry.getConfigurationProperties()[key]?.scope === ConfigurationScope.APPLICATION) { </ins> await this.reloadApplicationConfiguration(); } else { await this.reloadLocalUserConfiguration();
Code change:
cmd+F to open find widget Close it with escape cmd+up to navigate to previous command Nothing happens, I have to click or run a command to reset focus in the terminal
I can't reproduce this, if you still can are there any more details on the repro case? The keyboard troubleshooting command output would be helpful if only you can repro.
Sorry it's working now, agreed that it was probably a context key thing so I'll check that next time
I can repro this when the serch input have has text selected, PR

Related discussion:
text: override hide() { super.hide(); this._findWidgetVisible.reset(); <del> this._instance.focus(); </del> <ins> this._instance.focus(true); </ins> this._instance.xterm?.clearSearchDecorations(); }
Code change:
some terminals and type in them the window or restart VS Code they don't persist Started happening in OSS on Wednesday July 5th
is undefined !
it gets set to !
that's the return value (see )
yes, true. but the call returns so it's getting reset somewhere. not via !
I'm on to the cause... The process is getting killed after detaching on reload, so reconnect breaks: Revive after restart is working for me.
Ah found it: Investigating...
Parsed state is null so reconnect stops here:

Related discussion:
text: return this._proxy.setTerminalLayoutInfo(args); } async getTerminalLayoutInfo(args: IGetTerminalLayoutInfoArgs): Promise<ITerminalsLayoutInfo | undefined> { <del> return await this._proxy.getTerminalLayoutInfo(args); </del> <ins> // This is optional as we want reconnect requests to go through only if the pty host exists. // Revive is handled specially as reviveTerminalProcesses is guaranteed to be called before // the request for layout info. return this._optionalProxy?.getTerminalLayoutInfo(args); </ins> } async requestDetachInstance(workspaceId: string, instanceId: number): Promise<IProcessDetails | undefined> {
Code change:
some terminals and type in them the window or restart VS Code they don't persist Started happening in OSS on Wednesday July 5th
is undefined !
it gets set to !
that's the return value (see )
yes, true. but the call returns so it's getting reset somewhere. not via !
I'm on to the cause... The process is getting killed after detaching on reload, so reconnect breaks: Revive after restart is working for me.
Ah found it: Investigating...
Parsed state is null so reconnect stops here:

Related discussion:
text: }; } catch (e) { this._logService.warn(`Couldn't get layout info, a terminal was probably disconnected`, e.message); <del> this._logService.info('Reattach to wrong terminal debug info - layout info by id', t); this._logService.info('Reattach to wrong terminal debug info - _revivePtyIdMap', Array.from(this._revivedPtyIdMap.values())); </del> <ins> this._logService.debug('Reattach to wrong terminal debug info - layout info by id', t); this._logService.debug('Reattach to wrong terminal debug info - _revivePtyIdMap', Array.from(this._revivedPtyIdMap.values())); this._logService.debug('Reattach to wrong terminal debug info - _ptys ids', Array.from(this._ptys.keys())); </ins> // this will be filtered out and not reconnected return { terminal: null,
Code change:
<!-- 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. --For example when I open a project in v, I expand the folder on the file tree. When I refresh the whole page, the default behavior now is that the folders are collapsed, which means that I need to expand the folders one by one again the last time I opened them. !
If the expansion state of the file tree folder can remember the last expansion like tabs, similar to the gif below, I think this is a better effect. !
I have fixed this problem and will mention a pr later.
The reason for this problem is that there are multiple calls to the function during the rendering of the file tree. The state will be read from the cache for the first time, but before the execution is completed for the first time, the will be executed again. At this time, the tree already has a value. However, because the file tree data is not ready (because the data on the Web side is asynchronous), the state returned by the function is empty, resulting in the final file tree returning to the default collapsed state.

Related discussion:
text: private viewHasSomeCollapsibleRootItem: IContextKey<boolean>; private viewVisibleContextKey: IContextKey<boolean>; <ins> private setTreeInputPromise: Promise<void> | undefined; </ins> private horizontalScrolling: boolean | undefined; private dragHandler!: DelayedDragHandler;
Code change:
<!-- 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. --For example when I open a project in v, I expand the folder on the file tree. When I refresh the whole page, the default behavior now is that the folders are collapsed, which means that I need to expand the folders one by one again the last time I opened them. !
If the expansion state of the file tree folder can remember the last expansion like tabs, similar to the gif below, I think this is a better effect. !
I have fixed this problem and will mention a pr later.
The reason for this problem is that there are multiple calls to the function during the rendering of the file tree. The state will be read from the cache for the first time, but before the execution is completed for the first time, the will be executed again. At this time, the tree already has a value. However, because the file tree data is not ready (because the data on the Web side is asynchronous), the state returned by the function is empty, resulting in the final file tree returning to the default collapsed state.

Related discussion:
text: // save view state this._register(this.storageService.onWillSaveState(() => { <del> this.storageService.store(ExplorerView.TREE_VIEW_STATE_STORAGE_KEY, JSON.stringify(this.tree.getViewState()), StorageScope.WORKSPACE, StorageTarget.MACHINE); </del> <ins> this.storeTreeViewState(); </ins> })); }
Code change:
<!-- 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. --For example when I open a project in v, I expand the folder on the file tree. When I refresh the whole page, the default behavior now is that the folders are collapsed, which means that I need to expand the folders one by one again the last time I opened them. !
If the expansion state of the file tree folder can remember the last expansion like tabs, similar to the gif below, I think this is a better effect. !
I have fixed this problem and will mention a pr later.
The reason for this problem is that there are multiple calls to the function during the rendering of the file tree. The state will be read from the cache for the first time, but before the execution is completed for the first time, the will be executed again. At this time, the tree already has a value. However, because the file tree data is not ready (because the data on the Web side is asynchronous), the state returned by the function is empty, resulting in the final file tree returning to the default collapsed state.

Related discussion:
text: } } <ins> private storeTreeViewState() { this.storageService.store(ExplorerView.TREE_VIEW_STATE_STORAGE_KEY, JSON.stringify(this.tree.getViewState()), StorageScope.WORKSPACE, StorageTarget.MACHINE); } </ins> private setContextKeys(stat: ExplorerItem | null | undefined): void { const folders = this.contextService.getWorkspace().folders; const resource = stat ? stat.resource : folders[folders.length - 1].uri;