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.77.3 OS Version: Windows 11 Steps to Reproduce: a git repository a file with brackets in the name, e.g. the file in the git tab and add it to the file Desired behavior: The filename is to the such that the file is ignored Observed behavior: The file name is to but it is not ignored. This is because the syntax of does not interpret brackets literally. To ignore a filename that includes brackets requires escaping brackets with backslashes. gitignore after step 3: for desired effect should be: Proposed fix: Pre-process file names to to escape special characters.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.79.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!

return await this.run(Operation.Ignore, async () => { const ignoreFile = `${this.repository.root}${path.sep}.gitignore`; const textToAppend = files <del> .map(uri => relativePath(this.repository.root, uri.fsPath).replace(//g, '/')) </del> <ins> .map(uri => relativePath(this.repository.root, uri.fsPath) .replace(/|[/g, match => match === '' ? '/' : `${match}`)) </ins> .join('n'); const document = await new Promise(c => fs.exists(ignoreFile, c))


Question:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -

tsx: false, decorators: true }, <del> target: 'es2020', </del> <ins> target: 'es2022', </ins> loose: false, minify: { compress: false,


Question:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -

"./vs/*" ] }, <ins> "target": "es2022", "useDefineForClassFields": false, </ins> "lib": [ <del> "ES2016", "ES2017.Object", "ES2017.String", "ES2017.Intl", "ES2017.TypedArrays", "ES2018.AsyncIterable", "ES2018.AsyncGenerator", "ES2018.Promise", "ES2018.Regexp", "ES2018.Intl", "ES2019.Array", "ES2019.Object", "ES2019.String", "ES2019.Symbol", "ES2020.BigInt", "ES2020.Promise", "ES2020.String", "ES2020.Symbol.WellKnown", "ES2020.Intl", "ES2021.Promise", "ES2021.String", "ES2021.WeakRef", </del> <ins> "ES2022", </ins> "DOM", "DOM.Iterable", "WebWorker.ImportScripts"


Question:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -

"allowJs": true, "resolveJsonModule": true, "outDir": "../out/vs", <del> "target": "es2021", </del> "types": [ "keytar", "mocha",


Question:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -

export class ExtractError extends Error { readonly type?: ExtractErrorType; <del> readonly cause: Error; </del> constructor(type: ExtractErrorType | undefined, cause: Error) { let message = cause.message;


Question:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -

export abstract class ErrorHandler { <del> static { </del> <ins> static async installEarlyHandler(accessor: ServicesAccessor): Promise<void> { </ins> // increase number of stack frames (from 10, https://github.com/v8/v8/wiki/Stack-Trace-API) Error.stackTraceLimit = 100; <del> } static async installEarlyHandler(accessor: ServicesAccessor): Promise<void> { </del> // does NOT dependent of extension information, can be installed immediately, and simply forwards // to the log service and main thread errors const logService = accessor.get(ILogService);


Question:
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.

private async initialize(): Promise<void> { await this.extensionsScannerService.initializeDefaultProfileExtensions(); <del> await this.onDidChangeProfiles(this.userDataProfilesService.profiles, []); </del> <ins> await this.onDidChangeProfiles(this.userDataProfilesService.profiles); </ins> this.registerListeners(); await this.uninstallExtensionsNotInProfiles(); } private registerListeners(): void { <del> this._register(this.userDataProfilesService.onDidChangeProfiles(e => this.onDidChangeProfiles(e.added, e.removed))); </del> <ins> this._register(this.userDataProfilesService.onDidChangeProfiles(e => this.onDidChangeProfiles(e.added))); </ins> this._register(this.extensionsProfileScannerService.onAddExtensions(e => this.onAddExtensions(e))); this._register(this.extensionsProfileScannerService.onDidAddExtensions(e => this.onDidAddExtensions(e))); this._register(this.extensionsProfileScannerService.onRemoveExtensions(e => this.onRemoveExtensions(e)));


Question:
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.

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(


Question:
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.

} } <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();


Question:
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.

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> {


Question:
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.

// 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 },


Question:
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.

} 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(


Question:
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.

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 },


Question:
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.

} 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();


Question:
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

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();


Question:
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

.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); }


Question:
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

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();


Question:
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

override hide() { super.hide(); this._findWidgetVisible.reset(); <del> this._instance.focus(); </del> <ins> this._instance.focus(true); </ins> this._instance.xterm?.clearSearchDecorations(); }


Question:
"Please do not close this bug. This bug should only be closed by TCS, C+AI Accessibility or the Divisional Driver". #A11ySev2; #A11yTCS; #A11yMAS; #DesktopApp; #Visual Studio Code Client; #WCAG1.3.1; #DesktopApp; #BM-VisualStudioCodeClient-Win32-Aug2022; #NVDA; #Win32; #Win11; #A11yeDAD; #ScreenReader; #FTP; #NVDA; #AINotInScope; #Closed; Upon using the left or right arrow key to navigate the characters in the Terminal command, NVDA announces a blank instead of correctly providing the character feedback. As the arrow keys are pressed, NVDA should announce the characters in the command being navigated. Application Name: Visual Studio Code Version: 1.80.0-insider (user setup) V8: 10.8.168.25-electron.0 Windows 11 22H2 OS build .1000 Screen Reader: NVDA (2023.1) Terminal in Visual studio Code. on NVDA. terminal, type any command. left/ right arrow key to move NVDA focus within the written command. NVDA behavior The incorrect feedback provided by NVDA/JAWS affects the accessibility and usability of the Terminal application for users who rely on screen readers. This behavior hinders their ability to navigate and interact with command-line interfaces effectively. " - Identify accessibility bugs before check-in and make bug fixing faster and easier."
not sure if we're tracking this but we're talked about the fix I had in mind for this which was to synchronize ' textarea content with the help of shell integration.
This also happened to me when I was trying to edit a recent command in the integrated terminal (weirdly, arrowing on the newly typed command doesn't seem to be an issue). This makes integrated terminal nearly unuseable with the long command (in which typo is very much possible). I have also created the issue here:
Verified the issue in insiders 1.82.0 The issue is still repro. Please tell me in which version the issue is fixed. ! #Regressed:08-21-23; #PendingInput;
This works as shown here ! That is, until the terminal loses and then regains focus. That's a separate issue IMO and thus can be handled as a different bug tracked here
I verified the issue in below version of Visual Code Insiders. Version: 1.82.0-insider (user setup) Issue is still reproing. Please tell me in which version of Visual code Insiders the issue is fixed.
when reporting insiders versions you need to go to Help About and copy out all the version details. In particular the commit and date are needed to identify the insiders version.
This was verified by on both windows and mac. is having issues with it so we're going to meet about that.
I can reproduce the issue using insider version 1.82.0-insider (system setup), commit . I'm not sure why, but it appears that the issue has been resolved when using VS code inside WSL2 with the bash shell. However, when using VS code on the Windows host with PowerShell as the shell, I still encounter problems when navigating and editing both newly inputted commands and the previous commands recalled from the recent command history.
and I met and he showed it not working on windows. I'm guessing this is a conpty issue
which version of windows are you on ?
I use windows 11 Pro Version 22H2 (OS Build .2215)
I'm also able to repro on the latest Insiders on Windows using NVDA.
This is working on Windows for me. (10.0. Build ) which version do you have?
In System About I see version .2134 Using NVDA on Windows, and with screenreader mode enabled: a pwsh integrated terminal type left and right arrow keys announced text is "empty" whenever those arrow keys are pressed.
Below are the Environment Details of the latest Visual Studio Insider installed in my system: Version: 1.82.0-insider (user setup) Commit: Date: 2023-08-30T05:33:47.972Z Electron: 25.7.0 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0.
Yeah I can reproduce now. Seems to have regressed for Windows
is undefined for Windows
it may also in the wrong position on Windows, if I remember it's typically at 0. This will get fixed eventually in conpty.
what's odd to me is that it was working for me before
I'm not sure when it would be undefined, I guess it may be inconsistent? Command executed does not ensure command started had occurred:
We need info on the command line before command execution and for windows, we don't have that currently.
As with a lot of things on Windows ptys you'll need to add some heuristics here. It might work fine to just use . You could also try add some basic prompt detection for standard
To verify, enable . Then follow the steps here.
I did as you said. But still the issue is still reproducing. Please help ! Environment details: Version: 1.82.0-insider (user setup) Commit: Date: 2023-08-31T05:33:59.698Z Electron: 25.7.0 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0. NVDA version: 2023.1
you need to update you're using an old version
Verified the issue in below environment. Version: 1.82.0-insider (user setup) Commit: Date: 2023-09-01T05:33:39.919Z Electron: 25.7.0 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0. Issue is fixed. #Closed; #Regressed:09-04-23;

this._logService.debug(`TextAreaSyncAddon#updateCommandAndCursor: no line`); return; } <del> if (!!currentCommand.commandStartX) { </del> <ins> if (currentCommand.commandStartX !== undefined) { </ins> this._currentCommand = commandLine.substring(currentCommand.commandStartX); this._cursorX = buffer.cursorX - currentCommand.commandStartX; } else {


Question:
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:

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> {


Question:
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:

}; } 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,


Question:
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:

// Revive processes if needed const serializedState = this._storageService.get(TerminalStorageKeys.TerminalBufferState, StorageScope.WORKSPACE); <del> const parsed = this._deserializeTerminalState(serializedState); if (!parsed) { return undefined; } try { // Note that remote terminals do not get their environment re-resolved unlike in local terminals mark('code/terminal/willReviveTerminalProcessesRemote'); await this._remoteTerminalChannel.reviveTerminalProcesses(parsed, Intl.DateTimeFormat().resolvedOptions().locale); mark('code/terminal/didReviveTerminalProcessesRemote'); this._storageService.remove(TerminalStorageKeys.TerminalBufferState, StorageScope.WORKSPACE); // If reviving processes, send the terminal layout info back to the pty host as it // will not have been persisted on application exit const layoutInfo = this._storageService.get(TerminalStorageKeys.TerminalLayoutInfo, StorageScope.WORKSPACE); if (layoutInfo) { mark('code/terminal/willSetTerminalLayoutInfoRemote'); await this._remoteTerminalChannel.setTerminalLayoutInfo(JSON.parse(layoutInfo)); mark('code/terminal/didSetTerminalLayoutInfoRemote'); this._storageService.remove(TerminalStorageKeys.TerminalLayoutInfo, StorageScope.WORKSPACE); </del> <ins> const reviveBufferState = this._deserializeTerminalState(serializedState); if (reviveBufferState && reviveBufferState.length > 0) { try { // Note that remote terminals do not get their environment re-resolved unlike in local terminals mark('code/terminal/willReviveTerminalProcessesRemote'); await this._remoteTerminalChannel.reviveTerminalProcesses(reviveBufferState, Intl.DateTimeFormat().resolvedOptions().locale); mark('code/terminal/didReviveTerminalProcessesRemote'); this._storageService.remove(TerminalStorageKeys.TerminalBufferState, StorageScope.WORKSPACE); // If reviving processes, send the terminal layout info back to the pty host as it // will not have been persisted on application exit const layoutInfo = this._storageService.get(TerminalStorageKeys.TerminalLayoutInfo, StorageScope.WORKSPACE); if (layoutInfo) { mark('code/terminal/willSetTerminalLayoutInfoRemote'); await this._remoteTerminalChannel.setTerminalLayoutInfo(JSON.parse(layoutInfo)); mark('code/terminal/didSetTerminalLayoutInfoRemote'); this._storageService.remove(TerminalStorageKeys.TerminalLayoutInfo, StorageScope.WORKSPACE); } } catch (e: unknown) { this._logService.warn('RemoteTerminalBackend#getTerminalLayoutInfo Error', e && typeof e === 'object' && 'message' in e ? e.message : e); </ins> } <del> } catch (e: unknown) { this._logService.warn('RemoteTerminalBackend#getTerminalLayoutInfo Error', e && typeof e === 'object' && 'message' in e ? e.message : e); </del> } return this._remoteTerminalChannel.getTerminalLayoutInfo();


Question:
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:

// Revive processes if needed const serializedState = this._storageService.get(TerminalStorageKeys.TerminalBufferState, StorageScope.WORKSPACE); <del> const parsed = this._deserializeTerminalState(serializedState); if (!parsed) { return undefined; } try { // Create variable resolver const activeWorkspaceRootUri = this._historyService.getLastActiveWorkspaceRoot(); const lastActiveWorkspace = activeWorkspaceRootUri ? withNullAsUndefined(this._workspaceContextService.getWorkspaceFolder(activeWorkspaceRootUri)) : undefined; const variableResolver = terminalEnvironment.createVariableResolver(lastActiveWorkspace, await this._terminalProfileResolverService.getEnvironment(this.remoteAuthority), this._configurationResolverService); // Re-resolve the environments and replace it on the state so local terminals use a fresh // environment mark('code/terminal/willGetReviveEnvironments'); await Promise.all(parsed.map(state => new Promise<void>(r => { this._resolveEnvironmentForRevive(variableResolver, state.shellLaunchConfig).then(freshEnv => { state.processLaunchConfig.env = freshEnv; r(); }); }))); mark('code/terminal/didGetReviveEnvironments'); mark('code/terminal/willReviveTerminalProcesses'); await this._proxy.reviveTerminalProcesses(workspaceId, parsed, Intl.DateTimeFormat().resolvedOptions().locale); mark('code/terminal/didReviveTerminalProcesses'); this._storageService.remove(TerminalStorageKeys.TerminalBufferState, StorageScope.WORKSPACE); // If reviving processes, send the terminal layout info back to the pty host as it // will not have been persisted on application exit const layoutInfo = this._storageService.get(TerminalStorageKeys.TerminalLayoutInfo, StorageScope.WORKSPACE); if (layoutInfo) { mark('code/terminal/willSetTerminalLayoutInfo'); await this._proxy.setTerminalLayoutInfo(JSON.parse(layoutInfo)); mark('code/terminal/didSetTerminalLayoutInfo'); this._storageService.remove(TerminalStorageKeys.TerminalLayoutInfo, StorageScope.WORKSPACE); </del> <ins> const reviveBufferState = this._deserializeTerminalState(serializedState); if (reviveBufferState && reviveBufferState.length > 0) { try { // Create variable resolver const activeWorkspaceRootUri = this._historyService.getLastActiveWorkspaceRoot(); const lastActiveWorkspace = activeWorkspaceRootUri ? withNullAsUndefined(this._workspaceContextService.getWorkspaceFolder(activeWorkspaceRootUri)) : undefined; const variableResolver = terminalEnvironment.createVariableResolver(lastActiveWorkspace, await this._terminalProfileResolverService.getEnvironment(this.remoteAuthority), this._configurationResolverService); // Re-resolve the environments and replace it on the state so local terminals use a fresh // environment mark('code/terminal/willGetReviveEnvironments'); await Promise.all(reviveBufferState.map(state => new Promise<void>(r => { this._resolveEnvironmentForRevive(variableResolver, state.shellLaunchConfig).then(freshEnv => { state.processLaunchConfig.env = freshEnv; r(); }); }))); mark('code/terminal/didGetReviveEnvironments'); mark('code/terminal/willReviveTerminalProcesses'); await this._proxy.reviveTerminalProcesses(workspaceId, reviveBufferState, Intl.DateTimeFormat().resolvedOptions().locale); mark('code/terminal/didReviveTerminalProcesses'); this._storageService.remove(TerminalStorageKeys.TerminalBufferState, StorageScope.WORKSPACE); // If reviving processes, send the terminal layout info back to the pty host as it // will not have been persisted on application exit const layoutInfo = this._storageService.get(TerminalStorageKeys.TerminalLayoutInfo, StorageScope.WORKSPACE); if (layoutInfo) { mark('code/terminal/willSetTerminalLayoutInfo'); await this._proxy.setTerminalLayoutInfo(JSON.parse(layoutInfo)); mark('code/terminal/didSetTerminalLayoutInfo'); this._storageService.remove(TerminalStorageKeys.TerminalLayoutInfo, StorageScope.WORKSPACE); } } catch (e: unknown) { this._logService.warn('LocalTerminalBackend#getTerminalLayoutInfo Error', e && typeof e === 'object' && 'message' in e ? e.message : e); </ins> } <del> } catch (e: unknown) { this._logService.warn('LocalTerminalBackend#getTerminalLayoutInfo Error', e && typeof e === 'object' && 'message' in e ? e.message : e); </del> } return this._proxy.getTerminalLayoutInfo(layoutArgs);


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. --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.

private viewHasSomeCollapsibleRootItem: IContextKey<boolean>; private viewVisibleContextKey: IContextKey<boolean>; <ins> private setTreeInputPromise: Promise<void> | undefined; </ins> private horizontalScrolling: boolean | undefined; private dragHandler!: DelayedDragHandler;


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. --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.

// 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> })); }


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. --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.

} } <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;


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. --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.

return Promise.resolve(undefined); } <ins> // Wait for the last execution to complete before executing if (this.setTreeInputPromise) { await this.setTreeInputPromise; } </ins> const initialInputSetup = !this.tree.getInput(); if (initialInputSetup) { perf.mark('code/willResolveExplorer');


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. --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.

} const previousInput = this.tree.getInput(); <del> const promise = this.tree.setInput(input, viewState).then(async () => { </del> <ins> const promise = this.setTreeInputPromise = this.tree.setInput(input, viewState).then(async () => { </ins> if (Array.isArray(input)) { if (!viewState || previousInput instanceof ExplorerItem) { // There is no view state for this workspace (we transitioned from a folder workspace?), expand up to five roots.


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. --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.

const treeInputArray = Array.isArray(treeInput) ? treeInput : Array.from(treeInput.children.values()); // Has collapsible root when anything is expanded this.viewHasSomeCollapsibleRootItem.set(hasExpandedNode(this.tree, treeInputArray)); <ins> // synchronize state to cache this.storeTreeViewState(); </ins> } override dispose(): void {


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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: : 1.81.0-insider : : 2023-07-12T11:13:11.418Z : Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 OS Version: Mac os 12.2.1 (21D62) Steps to Reproduce: Configuration Display Language to . devtools after page auto refresh !
eg. does not exist, but exists.
thanks for working on this. The true fix for this issue actually needs to be in 's source code. I've made that fix and this should work for you now. Let me know if you still see any trouble.

// Set up nls if the user is not using the default language (English) const nlsConfig = {}; <del> const locale = window.localStorage.getItem('vscode.nls.locale') || navigator.language; </del> <ins> // Normalize locale to lowercase because translationServiceUrl is case-sensitive. // ref: https://github.com/microsoft/vscode/issues/187795 const locale = window.localStorage.getItem('vscode.nls.locale') || navigator.language.toLowerCase(); </ins> if (!locale.startsWith('en')) { nlsConfig['vs/nls'] = { availableLanguages: {


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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: : 1.81.0-insider : : 2023-07-12T11:13:11.418Z : Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 OS Version: Mac os 12.2.1 (21D62) Steps to Reproduce: Configuration Display Language to . devtools after page auto refresh !
eg. does not exist, but exists.
thanks for working on this. The true fix for this issue actually needs to be in 's source code. I've made that fix and this should work for you now. Let me know if you still see any trouble.

async setLocale(languagePackItem: ILanguagePackItem, _skipDialog = false): Promise<void> { const locale = languagePackItem.id; <del> if (locale === Language.value() || (!locale && Language.value() === navigator.language)) { </del> <ins> if (locale === Language.value() || (!locale && Language.value() === navigator.language.toLowerCase())) { </ins> return; } if (locale) {


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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: : 1.81.0-insider : : 2023-07-12T11:13:11.418Z : Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 OS Version: Mac os 12.2.1 (21D62) Steps to Reproduce: Configuration Display Language to . devtools after page auto refresh !
eg. does not exist, but exists.
thanks for working on this. The true fix for this issue actually needs to be in 's source code. I've made that fix and this should work for you now. Let me know if you still see any trouble.

window.localStorage.removeItem(WebLocaleService._LOCAL_STORAGE_LOCALE_KEY); window.localStorage.removeItem(WebLocaleService._LOCAL_STORAGE_EXTENSION_ID_KEY); <del> if (Language.value() === navigator.language) { </del> <ins> if (Language.value() === navigator.language.toLowerCase()) { </ins> return; }


Question:
Type: <bBug</bI get nightly updates on VSCode insiders and I get the crash on whenever I restart the app for updating it. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-13T05:33:32.822Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (21)</summaryExtensionVersion ------ vscode-chromium-vector-icons1.0.2 togglehs0.1.2 gitlens2023.7.1305 copilot1.96.259 copilot-chat0.5. mojom-language0.0.1 vscode-webidl0.0.1 vscode-clangd0.1.24 cpplint0.1.3 autopep82023.7. python2023.13. vscode-pylance2023.7.21 remote-ssh0.103. remote-ssh-edit0.86.0 cpptools1.16.3 remote-explorer0.5. gnls0.1.4 java1.21. code-spell-checker2.20.5 change-case1.0.0 vscode-proto30.5.5 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Any details on the crash? Any error messages? Any logs?
I've attached the Crash Dump. Note: I used 7-zip to compress to 7z and then to zip (to make it smaller that GitHub allowed size and format).
The same thing has been happening to me.
This has been happening to me too.
Thanks guys, I've confirmed the issue!
Got a stack trace:
Caused by , namely:

[[package]] name = "inno_updater" <del> version = "0.10.0" </del> <ins> version = "0.10.1" </ins> dependencies = [ "byteorder", "crc",


Question:
Type: <bBug</bI get nightly updates on VSCode insiders and I get the crash on whenever I restart the app for updating it. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-13T05:33:32.822Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (21)</summaryExtensionVersion ------ vscode-chromium-vector-icons1.0.2 togglehs0.1.2 gitlens2023.7.1305 copilot1.96.259 copilot-chat0.5. mojom-language0.0.1 vscode-webidl0.0.1 vscode-clangd0.1.24 cpplint0.1.3 autopep82023.7. python2023.13. vscode-pylance2023.7.21 remote-ssh0.103. remote-ssh-edit0.86.0 cpptools1.16.3 remote-explorer0.5. gnls0.1.4 java1.21. code-spell-checker2.20.5 change-case1.0.0 vscode-proto30.5.5 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Any details on the crash? Any error messages? Any logs?
I've attached the Crash Dump. Note: I used 7-zip to compress to 7z and then to zip (to make it smaller that GitHub allowed size and format).
The same thing has been happening to me.
This has been happening to me too.
Thanks guys, I've confirmed the issue!
Got a stack trace:
Caused by , namely:

[package] name = "inno_updater" <del> version = "0.10.0" </del> <ins> version = "0.10.1" </ins> authors = ["Microsoft <monacotools@microsoft.com>"] build = "build.rs"


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?: No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.80.1 OS Version: Windows 10 The C++ extension would like to redirect our users to our walkthrough if they pick an option in one of our quick picks: "help me install a compiler". To achieve this, we've been trying to invoke the command with a link to the correct step in the walkthrough similar to how python does it. The problem I'm seeing is that if we run this command before the Welcome page is loaded, it does not navigate to the walkthrough at all. It just displays the Welcome page and the following error appears in the Developer Console: . If we run the command after the Welcome page loads (or just run the command twice in a row), it will work. To work around it, I was going to try to detect whether the Weclome page or my walkthrough loaded after the first command attempt, but it doesn't look like the Welcome page's tab shows up in the list of so I'm not sure how to detect it. The safest thing for now seems to be to run the command twice every time, but it would be nice if it could be fixed to work on the first attempt.
I can't get this to work, even after opening the welcome window first - it only ever opens the generic welcome page for me. I tried with the c++ walkthrough steps and one in jupyter ext Am I doing something wrong?
Fixed by
This still doesn't work properly. The welcome page opens on the correct page, but then immediately switches back to the main welcome page. !
I'm unable to repro Here are my repro steps: a sample extension a command in the sample extension to open a walkthrough coming from an extension using and installed test extension and invoked the above command. Other things to try: Invoke command before opening welcome page and after.
repro's when debugging the extension with the command at least (I didn't try packaging into a visx) a command to the helloworld-sample extension in the and registered during activation install 5 to run, run the command :bug: similar to though it also sort of tries to shift away from the main walkthrough page, then it works correctly the second time !

const rerender = () => { this.gettingStartedCategories = this.gettingStartedService.getWalkthroughs(); this.featuredExtensions = this.featuredExtensionService.getExtensions(); <del> this.buildSlideThrottle.queue(async () => await this.buildCategoriesSlide()); </del> <ins> if (this.currentWalkthrough) { const existingSteps = this.currentWalkthrough.steps.map(step => step.id); const newCategory = this.gettingStartedCategories.find(category => this.currentWalkthrough?.id === category.id); if (newCategory) { const newSteps = newCategory.steps.map(step => step.id); if (!equals(newSteps, existingSteps)) { this.buildSlideThrottle.queue(() => this.buildCategoriesSlide()); } } } else { this.buildSlideThrottle.queue(() => this.buildCategoriesSlide()); } </ins> }; this._register(this.extensionManagementService.onDidInstallExtensions(async (result) => {


Question:
From version 1.80 onwards, we've been getting CI failures when testing our vscode extension with this error message: "Error while encrypting the text provided to safeStorage.encryptString. Encryption is not available." I suspect this is related to the move off keytar described in the release notes of 1.80 and here For the purposes of testing our extension, we pass additional launchArgs to VSCode, notably . As I understand it, this instructs VSCode to use some sort of in memory keytar so that the secrets are not actually persisted to disk? This is the desired behaviour for us so that no secrets persist after the the test suite concludes. This has been working well until now, and based on a quick search for on GitHub, it seems like a popular approach when testing VSCode extensions. Notably this only seems to happen in our linux CI. Mac and Windows continue to work without a problem (as also demonstrated below) <!-- 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: , Same issue happens on 1.80.1 OS Version: Ubuntu 22.04.2 Steps to Reproduce: I've created a minimal repro here: The line that ends up resulting in the error: GitHub Actions Build showing the error: PR demonstrating no errors happened on :
When encryption isn't available, we use an in-memory store instead so I think the current behavior should give you the desired behavior, no? Or does it actually throw instead and cause the extension to not function?
Yeah exactly, it just throws right now (on linux). Same code works without issue on 1.79
I think this is because you see a dialog in the product to ask you to do something. I need to make that dialog non-blocking. In the meantime, you can do this: And configure basic text encryption which is fine because the container will be destroyed after.
Thanks! I to the launchArgs, but seem to be getting the same error:
I think maybe you want not . I just tried on my Ubuntu machine and worked.
FYI I have opened to track allowing an in memory secret storage. If we get you unblocked with I'll dupe this to that.
thanks for continuing to look into this! I applied your suggestion ( without the quotes) but looks like on GitHub Actions (ubuntu) it still results in the same issue:
it should be instead of in , without that will not be called and causes the above error to be thrown.
Setting seems to do the trick for me – thank you!
FYI, I will change it to be to align with what Electron actually accepts.

isEncryptionAvailable(): Promise<boolean>; } <ins> // The values provided to the `password-store` command line switch. // Notice that they are not the same as the values returned by // `getSelectedStorageBackend` in the `safeStorage` API. export const enum PasswordStoreCLIOption { kwallet = 'kwallet', kwallet5 = 'kwallet5', gnome = 'gnome', gnomeKeyring = 'gnome-keyring', gnomeLibsecret = 'gnome-libsecret', basic = 'basic' } // The values returned by `getSelectedStorageBackend` in the `safeStorage` API. </ins> export const enum KnownStorageProvider { unknown = 'unknown', basicText = 'basic_text',


Question:
From version 1.80 onwards, we've been getting CI failures when testing our vscode extension with this error message: "Error while encrypting the text provided to safeStorage.encryptString. Encryption is not available." I suspect this is related to the move off keytar described in the release notes of 1.80 and here For the purposes of testing our extension, we pass additional launchArgs to VSCode, notably . As I understand it, this instructs VSCode to use some sort of in memory keytar so that the secrets are not actually persisted to disk? This is the desired behaviour for us so that no secrets persist after the the test suite concludes. This has been working well until now, and based on a quick search for on GitHub, it seems like a popular approach when testing VSCode extensions. Notably this only seems to happen in our linux CI. Mac and Windows continue to work without a problem (as also demonstrated below) <!-- 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: , Same issue happens on 1.80.1 OS Version: Ubuntu 22.04.2 Steps to Reproduce: I've created a minimal repro here: The line that ends up resulting in the error: GitHub Actions Build showing the error: PR demonstrating no errors happened on :
When encryption isn't available, we use an in-memory store instead so I think the current behavior should give you the desired behavior, no? Or does it actually throw instead and cause the extension to not function?
Yeah exactly, it just throws right now (on linux). Same code works without issue on 1.79
I think this is because you see a dialog in the product to ask you to do something. I need to make that dialog non-blocking. In the meantime, you can do this: And configure basic text encryption which is fine because the container will be destroyed after.
Thanks! I to the launchArgs, but seem to be getting the same error:
I think maybe you want not . I just tried on my Ubuntu machine and worked.
FYI I have opened to track allowing an in memory secret storage. If we get you unblocked with I'll dupe this to that.
thanks for continuing to look into this! I applied your suggestion ( without the quotes) but looks like on GitHub Actions (ubuntu) it still results in the same issue:
it should be instead of in , without that will not be called and causes the above error to be thrown.
Setting seems to do the trick for me – thank you!
FYI, I will change it to be to align with what Electron actually accepts.

kwallet5 = 'kwallet5', kwallet6 = 'kwallet6', <ins> // The rest of these are not returned by `getSelectedStorageBackend` // but these were added for platform completeness. </ins> // Windows dplib = 'dpapi',


Question:
From version 1.80 onwards, we've been getting CI failures when testing our vscode extension with this error message: "Error while encrypting the text provided to safeStorage.encryptString. Encryption is not available." I suspect this is related to the move off keytar described in the release notes of 1.80 and here For the purposes of testing our extension, we pass additional launchArgs to VSCode, notably . As I understand it, this instructs VSCode to use some sort of in memory keytar so that the secrets are not actually persisted to disk? This is the desired behaviour for us so that no secrets persist after the the test suite concludes. This has been working well until now, and based on a quick search for on GitHub, it seems like a popular approach when testing VSCode extensions. Notably this only seems to happen in our linux CI. Mac and Windows continue to work without a problem (as also demonstrated below) <!-- 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: , Same issue happens on 1.80.1 OS Version: Ubuntu 22.04.2 Steps to Reproduce: I've created a minimal repro here: The line that ends up resulting in the error: GitHub Actions Build showing the error: PR demonstrating no errors happened on :
When encryption isn't available, we use an in-memory store instead so I think the current behavior should give you the desired behavior, no? Or does it actually throw instead and cause the extension to not function?
Yeah exactly, it just throws right now (on linux). Same code works without issue on 1.79
I think this is because you see a dialog in the product to ask you to do something. I need to make that dialog non-blocking. In the meantime, you can do this: And configure basic text encryption which is fine because the container will be destroyed after.
Thanks! I to the launchArgs, but seem to be getting the same error:
I think maybe you want not . I just tried on my Ubuntu machine and worked.
FYI I have opened to track allowing an in memory secret storage. If we get you unblocked with I'll dupe this to that.
thanks for continuing to look into this! I applied your suggestion ( without the quotes) but looks like on GitHub Actions (ubuntu) it still results in the same issue:
it should be instead of in , without that will not be called and causes the above error to be thrown.
Setting seems to do the trick for me – thank you!
FYI, I will change it to be to align with what Electron actually accepts.

import { safeStorage as safeStorageElectron, app } from 'electron'; import { isMacintosh, isWindows } from 'vs/base/common/platform'; <del> import { KnownStorageProvider, IEncryptionMainService } from 'vs/platform/encryption/common/encryptionService'; </del> <ins> import { KnownStorageProvider, IEncryptionMainService, PasswordStoreCLIOption } from 'vs/platform/encryption/common/encryptionService'; </ins> import { ILogService } from 'vs/platform/log/common/log'; // These APIs are currently only supported in our custom build of electron so


Question:
From version 1.80 onwards, we've been getting CI failures when testing our vscode extension with this error message: "Error while encrypting the text provided to safeStorage.encryptString. Encryption is not available." I suspect this is related to the move off keytar described in the release notes of 1.80 and here For the purposes of testing our extension, we pass additional launchArgs to VSCode, notably . As I understand it, this instructs VSCode to use some sort of in memory keytar so that the secrets are not actually persisted to disk? This is the desired behaviour for us so that no secrets persist after the the test suite concludes. This has been working well until now, and based on a quick search for on GitHub, it seems like a popular approach when testing VSCode extensions. Notably this only seems to happen in our linux CI. Mac and Windows continue to work without a problem (as also demonstrated below) <!-- 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: , Same issue happens on 1.80.1 OS Version: Ubuntu 22.04.2 Steps to Reproduce: I've created a minimal repro here: The line that ends up resulting in the error: GitHub Actions Build showing the error: PR demonstrating no errors happened on :
When encryption isn't available, we use an in-memory store instead so I think the current behavior should give you the desired behavior, no? Or does it actually throw instead and cause the extension to not function?
Yeah exactly, it just throws right now (on linux). Same code works without issue on 1.79
I think this is because you see a dialog in the product to ask you to do something. I need to make that dialog non-blocking. In the meantime, you can do this: And configure basic text encryption which is fine because the container will be destroyed after.
Thanks! I to the launchArgs, but seem to be getting the same error:
I think maybe you want not . I just tried on my Ubuntu machine and worked.
FYI I have opened to track allowing an in memory secret storage. If we get you unblocked with I'll dupe this to that.
thanks for continuing to look into this! I applied your suggestion ( without the quotes) but looks like on GitHub Actions (ubuntu) it still results in the same issue:
it should be instead of in , without that will not be called and causes the above error to be thrown.
Setting seems to do the trick for me – thank you!
FYI, I will change it to be to align with what Electron actually accepts.

@ILogService private readonly logService: ILogService ) { // if this commandLine switch is set, the user has opted in to using basic text encryption <del> if (app.commandLine.getSwitchValue('password-store') === 'basic_text') { </del> <ins> if (app.commandLine.getSwitchValue('password-store') === PasswordStoreCLIOption.basic) { </ins> safeStorage.setUsePlainTextEncryption?.(true); } }


Question:
From version 1.80 onwards, we've been getting CI failures when testing our vscode extension with this error message: "Error while encrypting the text provided to safeStorage.encryptString. Encryption is not available." I suspect this is related to the move off keytar described in the release notes of 1.80 and here For the purposes of testing our extension, we pass additional launchArgs to VSCode, notably . As I understand it, this instructs VSCode to use some sort of in memory keytar so that the secrets are not actually persisted to disk? This is the desired behaviour for us so that no secrets persist after the the test suite concludes. This has been working well until now, and based on a quick search for on GitHub, it seems like a popular approach when testing VSCode extensions. Notably this only seems to happen in our linux CI. Mac and Windows continue to work without a problem (as also demonstrated below) <!-- 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: , Same issue happens on 1.80.1 OS Version: Ubuntu 22.04.2 Steps to Reproduce: I've created a minimal repro here: The line that ends up resulting in the error: GitHub Actions Build showing the error: PR demonstrating no errors happened on :
When encryption isn't available, we use an in-memory store instead so I think the current behavior should give you the desired behavior, no? Or does it actually throw instead and cause the extension to not function?
Yeah exactly, it just throws right now (on linux). Same code works without issue on 1.79
I think this is because you see a dialog in the product to ask you to do something. I need to make that dialog non-blocking. In the meantime, you can do this: And configure basic text encryption which is fine because the container will be destroyed after.
Thanks! I to the launchArgs, but seem to be getting the same error:
I think maybe you want not . I just tried on my Ubuntu machine and worked.
FYI I have opened to track allowing an in memory secret storage. If we get you unblocked with I'll dupe this to that.
thanks for continuing to look into this! I applied your suggestion ( without the quotes) but looks like on GitHub Actions (ubuntu) it still results in the same issue:
it should be instead of in , without that will not be called and causes the above error to be thrown.
Setting seems to do the trick for me – thank you!
FYI, I will change it to be to align with what Electron actually accepts.

'install-source'?: string; 'disable-updates'?: boolean; 'disable-keytar'?: boolean; <ins> 'password-store'?: string; </ins> 'disable-workspace-trust'?: boolean; 'disable-crash-reporter'?: boolean; 'crash-reporter-directory'?: string;


Question:
From version 1.80 onwards, we've been getting CI failures when testing our vscode extension with this error message: "Error while encrypting the text provided to safeStorage.encryptString. Encryption is not available." I suspect this is related to the move off keytar described in the release notes of 1.80 and here For the purposes of testing our extension, we pass additional launchArgs to VSCode, notably . As I understand it, this instructs VSCode to use some sort of in memory keytar so that the secrets are not actually persisted to disk? This is the desired behaviour for us so that no secrets persist after the the test suite concludes. This has been working well until now, and based on a quick search for on GitHub, it seems like a popular approach when testing VSCode extensions. Notably this only seems to happen in our linux CI. Mac and Windows continue to work without a problem (as also demonstrated below) <!-- 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: , Same issue happens on 1.80.1 OS Version: Ubuntu 22.04.2 Steps to Reproduce: I've created a minimal repro here: The line that ends up resulting in the error: GitHub Actions Build showing the error: PR demonstrating no errors happened on :
When encryption isn't available, we use an in-memory store instead so I think the current behavior should give you the desired behavior, no? Or does it actually throw instead and cause the extension to not function?
Yeah exactly, it just throws right now (on linux). Same code works without issue on 1.79
I think this is because you see a dialog in the product to ask you to do something. I need to make that dialog non-blocking. In the meantime, you can do this: And configure basic text encryption which is fine because the container will be destroyed after.
Thanks! I to the launchArgs, but seem to be getting the same error:
I think maybe you want not . I just tried on my Ubuntu machine and worked.
FYI I have opened to track allowing an in memory secret storage. If we get you unblocked with I'll dupe this to that.
thanks for continuing to look into this! I applied your suggestion ( without the quotes) but looks like on GitHub Actions (ubuntu) it still results in the same issue:
it should be instead of in , without that will not be called and causes the above error to be thrown.
Setting seems to do the trick for me – thank you!
FYI, I will change it to be to align with what Electron actually accepts.

'disable-telemetry': { type: 'boolean' }, 'disable-updates': { type: 'boolean' }, 'disable-keytar': { type: 'boolean' }, <ins> 'password-store': { type: 'string' }, </ins> 'disable-workspace-trust': { type: 'boolean' }, 'disable-crash-reporter': { type: 'boolean' }, 'crash-reporter-directory': { type: 'string' },


Question:
From version 1.80 onwards, we've been getting CI failures when testing our vscode extension with this error message: "Error while encrypting the text provided to safeStorage.encryptString. Encryption is not available." I suspect this is related to the move off keytar described in the release notes of 1.80 and here For the purposes of testing our extension, we pass additional launchArgs to VSCode, notably . As I understand it, this instructs VSCode to use some sort of in memory keytar so that the secrets are not actually persisted to disk? This is the desired behaviour for us so that no secrets persist after the the test suite concludes. This has been working well until now, and based on a quick search for on GitHub, it seems like a popular approach when testing VSCode extensions. Notably this only seems to happen in our linux CI. Mac and Windows continue to work without a problem (as also demonstrated below) <!-- 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: , Same issue happens on 1.80.1 OS Version: Ubuntu 22.04.2 Steps to Reproduce: I've created a minimal repro here: The line that ends up resulting in the error: GitHub Actions Build showing the error: PR demonstrating no errors happened on :
When encryption isn't available, we use an in-memory store instead so I think the current behavior should give you the desired behavior, no? Or does it actually throw instead and cause the extension to not function?
Yeah exactly, it just throws right now (on linux). Same code works without issue on 1.79
I think this is because you see a dialog in the product to ask you to do something. I need to make that dialog non-blocking. In the meantime, you can do this: And configure basic text encryption which is fine because the container will be destroyed after.
Thanks! I to the launchArgs, but seem to be getting the same error:
I think maybe you want not . I just tried on my Ubuntu machine and worked.
FYI I have opened to track allowing an in memory secret storage. If we get you unblocked with I'll dupe this to that.
thanks for continuing to look into this! I applied your suggestion ( without the quotes) but looks like on GitHub Actions (ubuntu) it still results in the same issue:
it should be instead of in , without that will not be called and causes the above error to be thrown.
Setting seems to do the trick for me – thank you!
FYI, I will change it to be to align with what Electron actually accepts.

import Severity from 'vs/base/common/severity'; import { localize } from 'vs/nls'; import { IDialogService } from 'vs/platform/dialogs/common/dialogs'; <del> import { IEncryptionService, KnownStorageProvider, isGnome, isKwallet } from 'vs/platform/encryption/common/encryptionService'; </del> <ins> import { IEncryptionService, KnownStorageProvider, PasswordStoreCLIOption, isGnome, isKwallet } from 'vs/platform/encryption/common/encryptionService'; </ins> import { IEnvironmentService } from 'vs/platform/environment/common/environment'; import { InstantiationType, registerSingleton } from 'vs/platform/instantiation/common/extensions'; import { ILogService } from 'vs/platform/log/common/log';


Question:
From version 1.80 onwards, we've been getting CI failures when testing our vscode extension with this error message: "Error while encrypting the text provided to safeStorage.encryptString. Encryption is not available." I suspect this is related to the move off keytar described in the release notes of 1.80 and here For the purposes of testing our extension, we pass additional launchArgs to VSCode, notably . As I understand it, this instructs VSCode to use some sort of in memory keytar so that the secrets are not actually persisted to disk? This is the desired behaviour for us so that no secrets persist after the the test suite concludes. This has been working well until now, and based on a quick search for on GitHub, it seems like a popular approach when testing VSCode extensions. Notably this only seems to happen in our linux CI. Mac and Windows continue to work without a problem (as also demonstrated below) <!-- 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: , Same issue happens on 1.80.1 OS Version: Ubuntu 22.04.2 Steps to Reproduce: I've created a minimal repro here: The line that ends up resulting in the error: GitHub Actions Build showing the error: PR demonstrating no errors happened on :
When encryption isn't available, we use an in-memory store instead so I think the current behavior should give you the desired behavior, no? Or does it actually throw instead and cause the extension to not function?
Yeah exactly, it just throws right now (on linux). Same code works without issue on 1.79
I think this is because you see a dialog in the product to ask you to do something. I need to make that dialog non-blocking. In the meantime, you can do this: And configure basic text encryption which is fine because the container will be destroyed after.
Thanks! I to the launchArgs, but seem to be getting the same error:
I think maybe you want not . I just tried on my Ubuntu machine and worked.
FYI I have opened to track allowing an in memory secret storage. If we get you unblocked with I'll dupe this to that.
thanks for continuing to look into this! I applied your suggestion ( without the quotes) but looks like on GitHub Actions (ubuntu) it still results in the same issue:
it should be instead of in , without that will not be called and causes the above error to be thrown.
Setting seems to do the trick for me – thank you!
FYI, I will change it to be to align with what Electron actually accepts.

label: localize('usePlainText', "Use weaker encryption"), run: async () => { await this._encryptionService.setUsePlainTextEncryption(); <del> await this._jsonEditingService.write(this._environmentService.argvResource, [{ path: ['password-store'], value: 'basic_text' }], true); </del> <ins> await this._jsonEditingService.write(this._environmentService.argvResource, [{ path: ['password-store'], value: PasswordStoreCLIOption.basic }], true); </ins> this.reinitialize(); } };


Question:
all chat audio cues enabled, run something in the inline chat that takes more than 4 seconds to come back that the chat response received cue doesn't play - in the console, there's an error about how a user gesture is required. this is expected to a different tab, leaving the chat widget still open to the tab with the chat widget visible hear the chat response received cue going between tabs and notice the cue gets played every time
so this happens even when it doesn't take that long !
this is because is called when the editor tab changes
that happens here !
looks like we need to move this to before is deleted so we can call it like
I have a different approach that will work. Ideally we would fix this at the root - so pls feel free to do so as you're more familiar with the state code.
This still repros for me with the steps from
So switching tabs plays an audio cue for you ?
This does not repro for me with the steps in this issue or the steps in the other one

private _responsePendingAudioCue: IDisposable | undefined; private _hasReceivedRequest: boolean = false; private _runOnceScheduler: RunOnceScheduler; <ins> private _lastResponse: string | undefined; </ins> constructor(@IAudioCueService private readonly _audioCueService: IAudioCueService) { super();


Question:
all chat audio cues enabled, run something in the inline chat that takes more than 4 seconds to come back that the chat response received cue doesn't play - in the console, there's an error about how a user gesture is required. this is expected to a different tab, leaving the chat widget still open to the tab with the chat widget visible hear the chat response received cue going between tabs and notice the cue gets played every time
so this happens even when it doesn't take that long !
this is because is called when the editor tab changes
that happens here !
looks like we need to move this to before is deleted so we can call it like
I have a different approach that will work. Ideally we would fix this at the root - so pls feel free to do so as you're more familiar with the state code.
This still repros for me with the steps from
So switching tabs plays an audio cue for you ?
This does not repro for me with the steps in this issue or the steps in the other one

const isPanelChat = typeof response !== 'string'; this._responsePendingAudioCue?.dispose(); this._runOnceScheduler?.cancel(); <ins> if (this._lastResponse === response?.toString()) { return; } this._lastResponse = response?.toString(); </ins> this._audioCueService.playAudioCue(AudioCue.chatResponseReceived, true); this._hasReceivedRequest = false; if (!response) {


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

*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { ITelemetryService } from 'vs/platform/telemetry/common/telemetry'; </del> import { ExtensionRecommendations, ExtensionRecommendation } from 'vs/workbench/contrib/extensions/browser/extensionRecommendations'; <del> import { INotificationService, Severity } from 'vs/platform/notification/common/notification'; import { EnablementState, IExtensionManagementServerService } from 'vs/workbench/services/extensionManagement/common/extensionManagement'; </del> <ins> import { EnablementState } from 'vs/workbench/services/extensionManagement/common/extensionManagement'; </ins> import { ExtensionRecommendationReason, IExtensionIgnoredRecommendationsService } from 'vs/workbench/services/extensionRecommendations/common/extensionRecommendations'; <del> import { IExtensionsViewPaneContainer, IExtensionsWorkbenchService, IExtension, VIEWLET_ID as EXTENSIONS_VIEWLET_ID } from 'vs/workbench/contrib/extensions/common/extensions'; import { CancellationToken } from 'vs/base/common/cancellation'; </del> <ins> import { IExtensionsWorkbenchService, IExtension } from 'vs/workbench/contrib/extensions/common/extensions'; </ins> import { localize } from 'vs/nls'; import { StorageScope, IStorageService, StorageTarget } from 'vs/platform/storage/common/storage'; import { IProductService } from 'vs/platform/product/common/productService';


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

import { basename, extname } from 'vs/base/common/resources'; import { match } from 'vs/base/common/glob'; import { URI } from 'vs/base/common/uri'; <del> import { Mimes } from 'vs/base/common/mime'; import { getMimeTypes } from 'vs/editor/common/services/languagesAssociations'; </del> import { IModelService } from 'vs/editor/common/services/model'; import { ILanguageService } from 'vs/editor/common/languages/language'; import { IExtensionRecommendationNotificationService, RecommendationsNotificationResult, RecommendationSource } from 'vs/platform/extensionRecommendations/common/extensionRecommendations';