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.64.2 OS Version: Windows 10 Steps to Reproduce: a git repo in root of a drive (network share in my case) a change of a file to Source control a see file diff version is shown as empty command line shows diffs properly when git repo is located in some subfolder git diff works in VSCode properly
VS Code Version: 1.67.2 OS Version: Windows 10 () I am also receiving this error, and I have pinpointed it in the Git Output, hopefully, it helps the path is missing the first character in the path for a specific file on the 'git show --textconv' lines 'ub-folder' vs 'sub-folder' If the command is run manually, with the correct path there are no issues Working (Non-root folder) [2022-06-01T06:49:42.910Z] git ls-tree -l HEAD -- fserverc$gitsharesub-folderMapper [229ms] [2022-06-01T06:49:42.991Z] git show --textconv HEAD:sub- [318ms] Not Working (Root folder) [2022-06-01T06:51:54.868Z] git ls-tree -l HEAD -- fservergitsharesub-folderMapper [226ms] [2022-06-01T06:51:54.897Z] git show --textconv HEAD:ub- [262ms]
The issue is in the file The following Line needs to be changed to As the current process is removing a specific length, when sometimes the variable for 'to' can contain a single slash or double slash (which the + 1 would handle the double slash) I recommend using the regex to effectively trim any leading slashes rather than a calculated length. I have a working file here I can provide further details if required as well.
thank you very much for looking into this. I have looked at this today and while adopting a regex to remove the characters from the resulting path will work, I think that there is something else happening here that I would like to understand before making a fix. Debugging the issue I have noticed that when you open a folder from the root as described in this issue, the value of the parameter contains a trailing . This is why adding +1 to it, will actually remove an unwanted character. I will investigate this further and will get a fix in this week.
Quick update on this issue. While the method can be improved, the root cause of the problem here is that returns a path that has a trailing character. This then results in the repository root being incorrect which can result in unexpected behaviour, diff editor not working being one example. This method already has code to handle mapped drives but it does not seem to handle this particular scenario. As we are in the process of shutting down for the next Stable release, I will be looking at fixing this issue sometimes next week. I will update the issue when the fix will be released in Insiders. Thanks for your patience.
I believe I have tracked down the root cause of the issue to the call: Running the following tests clearly illustrate the problem. Notice that the second call contains a trailing . This particular behavior seems to be by design based on an old issue that I have found - One option that I have considered was to remove the trailing slash from the repository root but that does not seem to be a good option as there are Windows path that are only valid if they contain a trailing slash (ex: ). I am more inclined to tweak the implementation of to always use as that seems to be able to correctly handle directory paths with the trailing . what are your thoughts? Thanks!
Hi, I'm also having this issue, even on the insiders build. I disabled all installed extensions. Expected Git Output: Actual Git Output: The drive in question is a mapped network drive. Whenever I try to view the file diff, the previous file is blank. This problem applies to all files on the network drive, even ones in subdirectories. Let me know if there's any other information I should provide.
I have file to track the problem that you have reported.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Yes
I'll mark this issue as verified as part of . Please file a new issue if the bug continues to occur on the latest Stable and/or Insiders versions of VS Code.

return path.normalize(pathUri.fsPath); } <ins> // On Windows, there are cases in which the normalized path for a mapped folder contains a trailing `` // character (ex: serverfolder) due to the implementation of `path.normalize()`. This behaviour is // by design as documented in https://github.com/nodejs/node/issues/1765. if (repoUri.authority.length !== 0) { return repoPath.replace(/$/, ''); } </ins> } return repoPath;


return false; } <del> const match = /^(?:https://github.com/|git@github.com:)([^/]+)/([^/.]+)(?:.git)?$/i.exec(remoteUrl); </del> <ins> const match = /^(?:https://github.com/|git@github.com:)([^/]+)/([^/.]+)/i.exec(remoteUrl); </ins> if (!match) { return false; }


Question:
Issue Type: <bBug</bmicrosoft/vscode-extension-samples the helloworld-sample folder , build, verift that its contributed "Hello World" command activates the extension and shows a notification. the vscode version references in in two places to use 1.43 minimum. code to activate function in , for example: , run, use "Hello World" command to activate. breakpoint on return line above. a folder. Explorer button or context menu to create a new file. Confirm that the event fires and your breakpoint is hit. from breakpoint. Explorer context menu to copy/paste or use drag/drop with modifier to drip as a copy. :bug: The event callback does not run, despite the API doc stating: Issue also exists in 1.64.2 VS Code version: Code - Insiders 1.65.0-insider (, 2022-02-21T05:15:17.930Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
cc
the extension host's event is only emitting from 's event, but the explorer is using the 's , which doesn't seem to talk to the working copy service. What do you think the fix here should be? (cc
the bulk edit service is using the for its operations. If you look at , there is a bunch of usages for that service. The working copy file service is a wrapper around the file service that ensures the relevant events are emitted and can be participated on. I suspect that for the copy/paste operation or drag/drop we are possibly not using the bulk edit service but the file service directly? I suggest to make a pass over all explorer code and look for raw usages of to replace with bulk edit service. I think that would even enable undo/redo properly.
My bad, the real bug is that this block: doesn't handle events. cc
Pragmatic fix would probably to treat the same as .

this._onDidDeleteFile.fire(Object.freeze({ files: files.map(f => URI.revive(f.target)) })); break; case FileOperation.CREATE: <ins> case FileOperation.COPY: </ins> this._onDidCreateFile.fire(Object.freeze({ files: files.map(f => URI.revive(f.target)) })); break; default:


Question:
Issue Type: <bBug</bmicrosoft/vscode-extension-samples the helloworld-sample folder , build, verift that its contributed "Hello World" command activates the extension and shows a notification. the vscode version references in in two places to use 1.43 minimum. code to activate function in , for example: , run, use "Hello World" command to activate. breakpoint on return line above. a folder. Explorer button or context menu to create a new file. Confirm that the event fires and your breakpoint is hit. from breakpoint. Explorer context menu to copy/paste or use drag/drop with modifier to drip as a copy. :bug: The event callback does not run, despite the API doc stating: Issue also exists in 1.64.2 VS Code version: Code - Insiders 1.65.0-insider (, 2022-02-21T05:15:17.930Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
cc
the extension host's event is only emitting from 's event, but the explorer is using the 's , which doesn't seem to talk to the working copy service. What do you think the fix here should be? (cc
the bulk edit service is using the for its operations. If you look at , there is a bunch of usages for that service. The working copy file service is a wrapper around the file service that ensures the relevant events are emitted and can be participated on. I suspect that for the copy/paste operation or drag/drop we are possibly not using the bulk edit service but the file service directly? I suggest to make a pass over all explorer code and look for raw usages of to replace with bulk edit service. I think that would even enable undo/redo properly.
My bad, the real bug is that this block: doesn't handle events. cc
Pragmatic fix would probably to treat the same as .

case FileOperation.DELETE: return await this._fireWillEvent(this._onWillDeleteFile, { files: files.map(f => URI.revive(f.target)) }, timeout, token); case FileOperation.CREATE: <ins> case FileOperation.COPY: </ins> return await this._fireWillEvent(this._onWillCreateFile, { files: files.map(f => URI.revive(f.target)) }, timeout, token); } return undefined;


Question:
It seems something odd is appearing in our builds, specifically for our "video" svgs that has a link. The SVG doesn't contain anything crazy: Which throws the following error in the console: The strangest thing is in OSS everything looks fine but in the builds, the image is small and not centered. <img width="1089" alt="CleanShot 2022-02-23 at 09 01 27 src="https://user-"<img width="1024" alt="CleanShot 2022-02-23 at 09 01 14 src="https://user-"cc
Is this new? cc any recent changes to CSP?
I see this in Stable as well, so we likely never caught it
This is happening because the is being stripped out of this svg at some point during build.

<del> <svg width="351" height="225" viewBox="0 0 351 225" fill="none" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> </del> <ins> <svg viewBox="0 0 351 225" fill="none" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> </ins> <g clip-path="url(#clip0_1103_9950)"> <rect width="350.625" height="225" fill="#1E1E1E" /> <rect width="350.625" height="225" fill="url(#paint0_radial_1103_9950)" />


Question:
Just broke again:
Added a timeout to the initialize request which will tell me if that's the part that's timing out, but it's probably not. Any guess
Duplicates

return new Promise((resolve, reject) => { debugAdapter.sendRequest('initialize', { adapterID: 'test' }, (result) => { resolve(result); <del> }); </del> <ins> }, 3000); </ins> }); }


Question:
This video shows text in another cell being undone even though focus is in a different cell. Doesn't seem to matter whether "Notebook: Undo Redo Per Cell" is enabled or not ! This video shows that after a cell as been and text has been to it, Ctrl-Z can be used to remove it, but it cannot be redone. You've lost anything typed in that cell permanently. !
Marking as important and a regression as I can't seem to figure out whether the "per-cell" setting is working the way it's intended or not.
Actually it appears that I may have disabled the "per-cell" setting a long time ago and didn't realize it. This may explain both behaviors above. I didn't realize that after changing that setting VS Code must be reloaded for the setting to take effect.
So removing "important" and "regression" for now. Let's just review what the behavior is that we want. It does seem problematic that if you have the setting off, that it doesn't seem possible to restore a cell you may have accidentally deleted. When the setting is on, Ctrl+z seems to work as expected.
After internal discussion, re-marking as important. It's a data loss scenario if you have cell-level undo off.
Possibly related to
With Cell Undo / Redo on (this is the default): Undoing and redoing text per cell works as expected Yes, with my testing Undoing and redoing add / remove of cell works as expected No, see bug 3 Undoing remove of cell via delete button No, see bug 4 With Cell Undo / Redo off: Undoing and redoing text per document works as expected No, see bug 1 Undoing and redoing add / remove of cell works as expected No, see bug 2 Undoing remove of cell via delete button No, see bug 4 Bugs: 1 Two cells in document. Changed from per cell to document mode. Typed in Cell A. Moved to the second cell, hit Undo. Instead of undoing the text, it blew away the second cell. Typing Redo did bring it back. I expected the typing in Cell A to be undone. Note, this bug I don't see after reloading the window. Might be that the setting change mid flow got the stack into a funny state? 2 Two cells in document. Shift-enter to run and add a new cell. Type in new cell. Ctrl-Z makes the typing go away and eventually the cell. When the cell is fully removed, redo will not restore it, so the typing is lost. Note, I can only replicate this will per cell turned off. With per cell turned on I first need to not be on the current cell to make it go away via Undo. But in that case I can make it go away with Undo and the text is restored with Redo. 3 However with per Cell on the cell + text does come back, but when it comes back it comes back without the per cell undo redo stack with per cell turned on: 4 When removing cell with the delete button, it cannot be restored with undo. This is true with either setting on. This is what I saw in my first pass. My personal ranking in importance would be like so 4 - Clear data loss. In both modes a cell is deleted and I can't get it back and the info in it. Easy to do and damaging. Effects both modes. 2 - Also clear data loss. I find this as a bit less important as I can only repro it with perCell off and I need to Ctrl-Z through the cell to get to the cell loss case so I've already removed what I typed in to the cell to get here. 3 () - Data loss here, but the data loss is not the actual code just the undo redo stack. So I'd vote for less important. 1 - I only reproed this when changing the perCell setting without a reload so an issue, but lesser importance.
Some related issues:
Note I'm going to use this issue specifically to resolve the issue where with perCell mode turned off you cannot restore a cell that was deleted with undo. The only specific scenarios in this fix are as follows: a notebook document a new cell (type something in it if you want) the cell using the delete button in the toolbar +Z (Run Undo) from a previous cell in the file the cell would not be restored, now it will be Scenario 2: the last cell in a notebook document shift-enter to run the cell and create a new cell some word in the new cell using Undo in that cell, it should walk back the words typed and eventually delete the cell start pressing Redo, it should restore the cell to the document then restore the words typed the cell would not be restored.
thanks for the detailed investigation, they are insightful! For bug 1, you are correct that flipping the setting messed up with the undo/redo state. We register based on the setting which is not updated when we flip the setting. We might want to dispose it and register a new one when the setting changes. For bug 2, with your fix in, I can't reproduce it with the per cell setting off. Not sure if it's similar to bug 1. For bug 3, your comment is accurate. It's like a document and we don't persist them usually when a resource is gone. I wonder if we should fetch and "save" the undo/redo stack for the cell on the cell deletion element in the undo stack.
Reopening to cover the issues with flipping the setting. I'll close after that fix and will cover the bigger issue on persisting undo / redo per cell after delete.
/verified? Still not sure this is working. Is per cell undo supposed to allow undo to affect other cells? Repro: to per cell undo in first cell in second cell +Z Expected it to only affect the current cell with focus. Actually it removes the typing in the first cell.
Otherwise seems to behave more like I'd expect.

super.dispose(); dispose(this._editorListeners); <del> this._undoRedoService.removeElements(this.uri); </del> <ins> // Only remove the undo redo stack if we map this cell uri to itself // If we are not in perCell mode, it will map to the full NotebookDocument and // we don't want to remove that entire document undo / redo stack when a cell is deleted if (this._undoRedoService.getUriComparisonKey(this.uri) === this.uri.toString()) { this._undoRedoService.removeElements(this.uri); } </ins> if (this._textModelRef) { this._textModelRef.dispose();


Question:
Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.

readonly executingCommandObject: ITerminalCommand | undefined; /** The current cwd at the cursor's position. */ readonly cwd: string | undefined; <ins> /** * Whether a command is currently being input. If the a command is current not being input or * the state cannot reliably be detected the fallback of undefined will be used. */ readonly hasInput: boolean | undefined; </ins> readonly onCommandStarted: Event<ITerminalCommand>; readonly onCommandFinished: Event<ITerminalCommand>; readonly onCommandInvalidated: Event<ITerminalCommand[]>;


Question:
Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.

return undefined; } get cwd(): string | undefined { return this._cwd; } <ins> private get _isInputting(): boolean { return !!(this._currentCommand.commandStartMarker && !this._currentCommand.commandExecutedMarker); } get hasInput(): boolean | undefined { if (!this._isInputting || !this._currentCommand?.commandStartMarker) { return undefined; } if (this._terminal.buffer.active.baseY + this._terminal.buffer.active.cursorY === this._currentCommand.commandStartMarker?.line) { const line = this._terminal.buffer.active.getLine(this._terminal.buffer.active.cursorY)?.translateToString(true, this._currentCommand.commandStartX); if (line === undefined) { return undefined; } return line.length > 0; } return true; } </ins> private readonly _onCommandStarted = new Emitter<ITerminalCommand>(); readonly onCommandStarted = this._onCommandStarted.event;


Question:
Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.

} this._currentCommand.commandStartX = this._terminal.buffer.active.cursorX; this._currentCommand.commandStartMarker = options?.marker || this._terminal.registerMarker(0); <ins> // Clear executed as it must happen after command start this._currentCommand.commandExecutedMarker?.dispose(); this._currentCommand.commandExecutedMarker = undefined; this._currentCommand.commandExecutedX = undefined; for (const m of this._commandMarkers) { m.dispose(); } this._commandMarkers.length = 0; </ins> this._onCommandStarted.fire({ marker: options?.marker || this._currentCommand.commandStartMarker, markProperties: options?.markProperties } as ITerminalCommand); this._logService.debug('CommandDetectionCapability#handleCommandStart', this._currentCommand.commandStartX, this._currentCommand.commandStartMarker?.line); }


Question:
Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.

import { showWithPinnedItems } from 'vs/platform/quickinput/browser/quickPickPin'; import { IStorageService } from 'vs/platform/storage/common/storage'; import { IContextKey } from 'vs/platform/contextkey/common/contextkey'; <ins> import { timeout } from 'vs/base/common/async'; </ins> export async function showRunRecentQuickPick( accessor: ServicesAccessor,


Question:
Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.

} else { // command text = result.rawLabel; } <del> instance.sendText(text, !quickPick.keyMods.alt, true); </del> quickPick.hide(); <ins> runCommand(instance, text, !quickPick.keyMods.alt); </ins> if (quickPick.keyMods.alt) { instance.focus(); }


Question:
Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.

}); } <ins> async function runCommand(instance: ITerminalInstance, commandLine: string, addNewLine: boolean): Promise<void> { // Determine whether to send ETX (ctrl+c) before running the command. This should always // happen unless command detection can reliably say that a command is being entered and // there is no content in the prompt if (instance.capabilities.get(TerminalCapability.CommandDetection)?.hasInput !== false) { await instance.sendText('x03', false); // Wait a little before running the command to avoid the sequences being echoed while the ^C // is being evaluated await timeout(100); } // Use bracketed paste mode only when not running the command await instance.sendText(commandLine, addNewLine, !addNewLine); } </ins> class TerminalOutputProvider implements ITextModelContentProvider { static scheme = 'TERMINAL_OUTPUT';


Question: Open following url Install dialog is shown asking user to install and open extension <img width="275" alt="image" src="https://user-"- After clicking on install, following prompt is shown <img width="454" alt="image" src="https://user-"Second prompt seems to be unnecessary. It is expected to open the URL after installing

import { IWorkbenchExtensionEnablementService, EnablementState } from 'vs/workbench/services/extensionManagement/common/extensionManagement'; import { areSameExtensions } from 'vs/platform/extensionManagement/common/extensionManagementUtil'; import { createDecorator, ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; <del> import { INotificationService, Severity } from 'vs/platform/notification/common/notification'; </del> <ins> import { INotificationService } from 'vs/platform/notification/common/notification'; </ins> import { IStorageService, StorageScope, StorageTarget } from 'vs/platform/storage/common/storage'; import { IURLHandler, IURLService, IOpenURLOptions } from 'vs/platform/url/common/url'; import { IHostService } from 'vs/workbench/services/host/browser/host'; <del> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; </del> <ins> import { IExtensionService, toExtensionDescription } from 'vs/workbench/services/extensions/common/extensions'; </ins> import { ExtensionIdentifier } from 'vs/platform/extensions/common/extensions'; import { registerSingleton } from 'vs/platform/instantiation/common/extensions'; import { Registry } from 'vs/platform/registry/common/platform';


Question: Open following url Install dialog is shown asking user to install and open extension <img width="275" alt="image" src="https://user-"- After clicking on install, following prompt is shown <img width="454" alt="image" src="https://user-"Second prompt seems to be unnecessary. It is expected to open the URL after installing

const extension = await this.extensionService.getExtension(extensionId); if (!extension) { <del> await this.handleUnhandledURL(uri, { id: extensionId }); </del> <ins> await this.handleUnhandledURL(uri, { id: extensionId }, options); </ins> return true; }


Question: Open following url Install dialog is shown asking user to install and open extension <img width="275" alt="image" src="https://user-"- After clicking on install, following prompt is shown <img width="454" alt="image" src="https://user-"Second prompt seems to be unnecessary. It is expected to open the URL after installing

return await handler.handleURL(uri, options); } <del> private async handleUnhandledURL(uri: URI, extensionIdentifier: IExtensionIdentifier): Promise<void> { </del> <ins> private async handleUnhandledURL(uri: URI, extensionIdentifier: IExtensionIdentifier, options?: IOpenURLOptions): Promise<void> { </ins> const installedExtensions = await this.extensionManagementService.getInstalled(); <del> const extension = installedExtensions.filter(e => areSameExtensions(e.identifier, extensionIdentifier))[0]; // Extension is installed if (extension) { const enabled = this.extensionEnablementService.isEnabled(extension); // Extension is not running. Reload the window to handle. if (enabled) { this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/activate_extension/start', { extensionId: extensionIdentifier.id }); const result = await this.dialogService.confirm({ message: localize('reloadAndHandle', "Extension '{0}' is not loaded. Would you like to reload the window to load the extension and open the URL?", extension.manifest.displayName || extension.manifest.name), detail: `${extension.manifest.displayName || extension.manifest.name} (${extensionIdentifier.id}) wants to open a URL:nn${uri.toString()}`, primaryButton: localize('reloadAndOpen', "&&Reload Window and Open"), type: 'question' }); if (!result.confirmed) { this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/activate_extension/cancel', { extensionId: extensionIdentifier.id }); return; } this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/activate_extension/accept', { extensionId: extensionIdentifier.id }); await this.reloadAndHandle(uri); } // Extension is disabled. Enable the extension and reload the window to handle. else if (this.extensionEnablementService.canChangeEnablement(extension)) { this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/enable_extension/start', { extensionId: extensionIdentifier.id }); const result = await this.dialogService.confirm({ message: localize('enableAndHandle', "Extension '{0}' is disabled. Would you like to enable the extension and reload the window to open the URL?", extension.manifest.displayName || extension.manifest.name), detail: `${extension.manifest.displayName || extension.manifest.name} (${extensionIdentifier.id}) wants to open a URL:nn${uri.toString()}`, primaryButton: localize('enableAndReload', "&&Enable and Open"), type: 'question' }); if (!result.confirmed) { this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/enable_extension/cancel', { extensionId: extensionIdentifier.id }); return; } this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/enable_extension/accept', { extensionId: extensionIdentifier.id }); await this.extensionEnablementService.setEnablement([extension], EnablementState.EnabledGlobally); await this.reloadAndHandle(uri); } } </del> <ins> let extension = installedExtensions.find(e => areSameExtensions(e.identifier, extensionIdentifier)); </ins> // Extension is not installed <del> else { </del> <ins> if (!extension) { </ins> let galleryExtension: IGalleryExtension | undefined; try {


Question: Open following url Install dialog is shown asking user to install and open extension <img width="275" alt="image" src="https://user-"- After clicking on install, following prompt is shown <img width="454" alt="image" src="https://user-"Second prompt seems to be unnecessary. It is expected to open the URL after installing

// Install the Extension and reload the window to handle. const result = await this.dialogService.confirm({ <del> message: localize('installAndHandle', "Extension '{0}' is not installed. Would you like to install the extension and reload the window to open this URL?", galleryExtension.displayName || galleryExtension.name), </del> <ins> message: localize('installAndHandle', "Extension '{0}' is not installed. Would you like to install the extension and open this URL?", galleryExtension.displayName || galleryExtension.name), </ins> detail: `${galleryExtension.displayName || galleryExtension.name} (${extensionIdentifier.id}) wants to open a URL:nn${uri.toString()}`, <del> primaryButton: localize('install', "&&Install"), </del> <ins> primaryButton: localize('install and open', "&&Install and Open"), </ins> type: 'question' });


Question: Open following url Install dialog is shown asking user to install and open extension <img width="275" alt="image" src="https://user-"- After clicking on install, following prompt is shown <img width="454" alt="image" src="https://user-"Second prompt seems to be unnecessary. It is expected to open the URL after installing

this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/install_extension/accept', { extensionId: extensionIdentifier.id }); try { <del> await this.progressService.withProgress({ </del> <ins> extension = await this.progressService.withProgress({ </ins> location: ProgressLocation.Notification, title: localize('Installing', "Installing Extension '{0}'...", galleryExtension.displayName || galleryExtension.name) }, () => this.extensionManagementService.installFromGallery(galleryExtension!)); <del> this.notificationService.prompt( Severity.Info, localize('reload', "Would you like to reload the window and open the URL '{0}'?", uri.toString()), [{ label: localize('Reload', "Reload Window and Open"), run: async () => { this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/install_extension/reload', { extensionId: extensionIdentifier.id }); await this.reloadAndHandle(uri); } }], { sticky: true } ); </del> } catch (error) { this.notificationService.error(error); <ins> return; } } // Extension is installed but not enabled if (!this.extensionEnablementService.isEnabled(extension)) { this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/enable_extension/start', { extensionId: extensionIdentifier.id }); const result = await this.dialogService.confirm({ message: localize('enableAndHandle', "Extension '{0}' is disabled. Would you like to enable the extension and open the URL?", extension.manifest.displayName || extension.manifest.name), detail: `${extension.manifest.displayName || extension.manifest.name} (${extensionIdentifier.id}) wants to open a URL:nn${uri.toString()}`, primaryButton: localize('enableAndReload', "&&Enable and Open"), type: 'question' }); if (!result.confirmed) { this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/enable_extension/cancel', { extensionId: extensionIdentifier.id }); return; </ins> } <ins> this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/enable_extension/accept', { extensionId: extensionIdentifier.id }); await this.extensionEnablementService.setEnablement([extension], EnablementState.EnabledGlobally); } if (this.extensionService.canAddExtension(toExtensionDescription(extension))) { await this.waitUntilExtensionIsAdded(extensionIdentifier); await this.handleURL(uri, { ...options, trusted: true }); } /* Extension cannot be added and require window reload */ else { this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/activate_extension/start', { extensionId: extensionIdentifier.id }); const result = await this.dialogService.confirm({ message: localize('reloadAndHandle', "Extension '{0}' is not loaded. Would you like to reload the window to load the extension and open the URL?", extension.manifest.displayName || extension.manifest.name), detail: `${extension.manifest.displayName || extension.manifest.name} (${extensionIdentifier.id}) wants to open a URL:nn${uri.toString()}`, primaryButton: localize('reloadAndOpen', "&&Reload Window and Open"), type: 'question' }); if (!result.confirmed) { this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/activate_extension/cancel', { extensionId: extensionIdentifier.id }); return; } this.telemetryService.publicLog2<ExtensionUrlHandlerEvent, ExtensionUrlHandlerClassification>('uri_invoked/activate_extension/accept', { extensionId: extensionIdentifier.id }); this.storageService.store(URL_TO_HANDLE, JSON.stringify(uri.toJSON()), StorageScope.WORKSPACE, StorageTarget.MACHINE); await this.hostService.reload(); </ins> } } <del> private async reloadAndHandle(url: URI): Promise<void> { this.storageService.store(URL_TO_HANDLE, JSON.stringify(url.toJSON()), StorageScope.WORKSPACE, StorageTarget.MACHINE); await this.hostService.reload(); </del> <ins> private async waitUntilExtensionIsAdded(extensionId: IExtensionIdentifier): Promise<void> { if (!(await this.extensionService.getExtension(extensionId.id))) { await new Promise<void>((c, e) => { const disposable = this.extensionService.onDidChangeExtensions(async () => { try { if (await this.extensionService.getExtension(extensionId.id)) { disposable.dispose(); c(); } } catch (error) { e(error); } }); }); } </ins> } // forget about all uris buffered more than 5 minutes ago


Question:
System info: macOs, Zsh, shell integration on. to vscode folder and hit tab it autocompletes to Hit tab again to autocomplete the names, it instead creates a big space and adds again. !
Not sure if we're tracking this one yet but I've seen it too in pwsh/Windows.
Works fine in pwsh.
It only occurs for me when shell integration is on. I've had to disable it in the meantime
Maybe I didn't see it on Windows actually. Happens on zsh/mac when pasting followed by enter/left: <img width="418" alt="Screen Shot 2022-03-17 at 10 57 44 am" src="https://user-"
Oh I bet I know what's causing this, we need to wrap "invisible" parts of the prompt in and
Simpler repro: tab <img width="242" alt="Screen Shot 2022-03-17 at 11 08 21 am" src="https://user-"l

update_prompt() { PRIOR_PROMPT="$PS1" IN_COMMAND_EXECUTION="" <del> PS1="$(prompt_start)$PREFIX$PS1$(prompt_end)" PS2="$(continuation_start)$PS2$(continuation_end)" </del> <ins> PS1="[$(prompt_start)]$PREFIX$PS1[$(prompt_end)]" PS2="[$(continuation_start)]$PS2[$(continuation_end)]" </ins> } precmd() {


Question:
System info: macOs, Zsh, shell integration on. to vscode folder and hit tab it autocompletes to Hit tab again to autocomplete the names, it instead creates a big space and adds again. !
Not sure if we're tracking this one yet but I've seen it too in pwsh/Windows.
Works fine in pwsh.
It only occurs for me when shell integration is on. I've had to disable it in the meantime
Maybe I didn't see it on Windows actually. Happens on zsh/mac when pasting followed by enter/left: <img width="418" alt="Screen Shot 2022-03-17 at 10 57 44 am" src="https://user-"
Oh I bet I know what's causing this, we need to wrap "invisible" parts of the prompt in and
Simpler repro: tab <img width="242" alt="Screen Shot 2022-03-17 at 11 08 21 am" src="https://user-"l

update_prompt() { PRIOR_PROMPT="$PS1" IN_COMMAND_EXECUTION="" <del> PS1="$(prompt_start)$PREFIX$PS1$(prompt_end)" PS2="$(continuation_start)$PS2$(continuation_end)" </del> <ins> PS1="%{$(prompt_start)%}$PREFIX$PS1%{$(prompt_end)%}" PS2="%{$(continuation_start)%}$PS2%{$(continuation_end)%}" </ins> } precmd() {


Question:
The original issue comes from Comment from Looks like there is some problem with the editor focus when the test message view is peeked out?
I found a way to view test results and work with tests. When the tests are executed, I need to press CTRL+m for tab key to move between elements, then tab until the close button and after that panel with buttons to go to previous and next failure results there will be a tree with test results. That's accessible with NVDA, I am sure it's also accessible with Orca. Thank you for help all!
Thanks for the issue! at the moment we reveal the failed position and then focus the editor. Instead is it preferable to focus within the peek view like the references peeks do?
yeah, it would be better if you focus inside the peek automatically for accessibility reasons. If you want, you can also differentiate if the command is triggered via keybinding, if yes then move focus, otherwise do not. This is what the editor hover does. Though I think it might be a bit confusing in this case, so I suggest to just pass focus inside the peek.
Thank you for such an active feedback! I also think that it would be more convenient if the focus moves directly to the peek instead of moving it to the editor with the selected line that can be easily deleted by accedent. Thank you!
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
how about some verification steps unless resurfaces?
Steps in the original post should still be accurate. Opening test peek output (for a failed test) via should focus and screen-read the peek view, rather than staying in the editor.

this.show(dto.revealLocation.range, TestingOutputPeek.lastHeightInLines || hintMessagePeekHeight(message)); this.editor.revealPositionNearTop(dto.revealLocation.range.getStartPosition(), ScrollType.Smooth); <del> this.editor.focus(); </del> return this.showInPlace(dto); }


Question:
The original issue comes from Comment from Looks like there is some problem with the editor focus when the test message view is peeked out?
I found a way to view test results and work with tests. When the tests are executed, I need to press CTRL+m for tab key to move between elements, then tab until the close button and after that panel with buttons to go to previous and next failure results there will be a tree with test results. That's accessible with NVDA, I am sure it's also accessible with Orca. Thank you for help all!
Thanks for the issue! at the moment we reveal the failed position and then focus the editor. Instead is it preferable to focus within the peek view like the references peeks do?
yeah, it would be better if you focus inside the peek automatically for accessibility reasons. If you want, you can also differentiate if the command is triggered via keybinding, if yes then move focus, otherwise do not. This is what the editor hover does. Though I think it might be a bit confusing in this case, so I suggest to just pass focus inside the peek.
Thank you for such an active feedback! I also think that it would be more convenient if the focus moves directly to the peek instead of moving it to the editor with the selected line that can be easily deleted by accedent. Thank you!
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
how about some verification steps unless resurfaces?
Steps in the original post should still be accurate. Opening test peek output (for a failed test) via should focus and screen-read the peek view, rather than staying in the editor.

this.tree.setFocus([messageNode]); this.tree.setSelection([messageNode]); <ins> this.tree.domFocus(); </ins> })); this._register(this.tree.onDidOpen(async e => {


Question:
The fix for at only replaces the first instance of in the string, not all of them. I suspect the regex needs on the end. <img width="1028" alt="Screenshot 2022-03-17 at 14 46 58" src="https://user-" FYI :)
heh, I found that and was going to change it, but GitHub fell over. I can easily add the , but it's not clear to me where/how to write a test against this class (which is actually the part that I get stuck on any time I want to contribute something). I can't find any similar tests in this area to use as a template.
/verified

} } <del> const lineBreakRe = /r?ns*/; </del> <ins> const lineBreakRe = /r?ns*/g; </ins> class TestMessageDecoration implements ITestDecoration { public static readonly inlineClassName = 'test-message-inline-content';


Question: Steps to Reproduce: command a language Settings file is opened. Settings Editor with language filter shall be opened given that the editor supports it.

if (pick) { const languageId = this.languageService.getLanguageIdByLanguageName(pick.label); if (typeof languageId === 'string') { <del> return this.preferencesService.openUserSettings({ jsonEditor: true, revealSetting: { key: `[${languageId}]`, edit: true } }); </del> <ins> return this.preferencesService.openLanguageSpecificSettings(languageId); </ins> } } return undefined;


Question: Steps to Reproduce: command a language Settings file is opened. Settings Editor with language filter shall be opened given that the editor supports it.

return this.open(this.userSettingsResource, options); } <ins> openLanguageSpecificSettings(languageId: string, options: IOpenSettingsOptions = {}): Promise<IEditorPane | undefined> { if (this.shouldOpenJsonByDefault()) { options.query = undefined; options.revealSetting = { key: `[${languageId}]`, edit: true }; } else { options.query = `@lang:${languageId}${options.query ? ` ${options.query}` : ''}`; } options.target = options.target ?? ConfigurationTarget.USER_LOCAL; return this.open(this.userSettingsResource, options); } </ins> private open(settingsResource: URI, options: IOpenSettingsOptions): Promise<IEditorPane | undefined> { options = { ...options,


Question: Steps to Reproduce: command a language Settings file is opened. Settings Editor with language filter shall be opened given that the editor supports it.

openFolderSettings(options: IOpenSettingsOptions & { folderUri: IOpenSettingsOptions['folderUri'] }): Promise<IEditorPane | undefined>; openGlobalKeybindingSettings(textual: boolean, options?: IKeybindingsEditorOptions): Promise<void>; openDefaultKeybindingsFile(): Promise<IEditorPane | undefined>; <ins> openLanguageSpecificSettings(language: string, options?: IOpenSettingsOptions): Promise<IEditorPane | undefined>; </ins> getEditableSettingsURI(configurationTarget: ConfigurationTarget, resource?: URI): Promise<URI | null>; createSplitJsonEditorInput(configurationTarget: ConfigurationTarget, resource: URI): EditorInput;


Question:
Forgot to respond and got closed due to inactivity. - We don't necessarily need them to read each item, but at the minimum screen reader users need to know that these buttons exist. Even a small announcement along the lines of "tree items actions available on tab" would suffice. Repost of:
Does this issue occur when all extensions are disabled?: Yes/No VS Code Version: 1.63.2 OS Version: Win11 Steps to Reproduce: a debug session in VSCode on Narrator keyboard and navigate focus to the debug target ! Expected Result: Narrator should announce all context, including action items associated with the treeitem Actual Result: Narrator announces just the tree item text and associated action buttons
I am not convinced this should be announced. As Rob already mentioned on that issue the user can just press tab and focus onto the toolbar. We do not do this in other places that the parent element mentions all the children element inside it. Or the element that is about to get navigated to next. Let's leave this open for now to see if there is some feedback from users regarding this. For now I suggest no action.
Not announcing anything does violate accessibility standard guidelines as visually impaired users who rely on screen readers wouldn't know that there are buttons associated with each tree item. I am filing this issue on behalf of the project where our products are required to meet accessibility standards and this component has been flagged as an accessibility violation. I understand that the prioritization might differ, but I wanted to give some context behind the issue.
Agreed that "they could just hit tab and find them" is neither valid to fulfil our accessibility needs nor is it something we can expect from users who rely on navigating without seeing. As a quick fix, is there a chance to add an aria label to elements like these that announces "more functionality available" to explain to people that hitting tab will get them there?
- Instead of adding extra announcements, we could also change the type of the component to be a tree grid/tree grid item. Screen reader users should expect more content on tab if they are on a tree grid item. Any thoughts on this solution?
thanks for your creative suggestion, but a is something that is like a table and might not fit here. Check out the example here does it make sense that VS Code trees start using a role because each element might have extra content inside. How do Screen Readers treat vs ?
The suggestion came from the Edge Accessibility team. The core idea is that the existence of interactive buttons/content should be inherent based on the role of the element which is true for a tree grid item but not a tree item. As for screen reader behavior, treegrids are announced like tables, but they also state item position and level similar to a tree item. For instance, when you enter the grid, it will say: "Entering table, 5x2... etc {contents of the row} expanded 1 of 3 level 1" From this, the user will understand that there are additional cells with content to the right (maybe just one extra cell containing the toolbar with buttons) and also that they are in a tree structure.
Thanks for clarifying. Also are you suggesting that all trees in vscode have the role? Since every tree could have additional actions inside. What's the downside of using the role? Let's see what thinks when she finds time to reply. She is the author of Orca screen reader.
tl;dr I think Tree Grid might be appropriate here. Long form: I definitely wouldn't expect interactive elements inside a normal tree view item. The two interaction models I've seen on those are: a) Put these items in the context menu. b) Have the user press Enter on the item to enter into a secondary layer where one would then tab through interactive elements. I first saw this in the old FireBug developer tools extension for Firefox, and later, while I was working at Mozilla, we also took this approach in the built-in developer tools in the HTML tree inspector. A tool bar with buttons etc. inside a tree item is certainly not Windows-Standard, and Windows standard is what most ARIA specs and authoring guidelines primarily derive from. Tree grids come more from the Linux side, where this is at least I saw them first in GNOME Nautilus. So yeah, I would lean towards a tree grid model where one would right arrow into the buttons for an item, if available, or tab to the toolbar, etc. We'd have to play with the aria-readonly property on this tree table, since some screen readers sometimes think they're editable when they're actually not, or vice versa.
thanks for chiming in, I really appreciate your expertise. In VS Code it is pressing to get into the toolbar that is inside the tree element. Some follow up questions for everybody on this thread so we decide how to proceed further: about the Breakpoints view? This has the role and also has interactive elements inside each ? there some unintended consequences of going with the instead of the in all our trees? Or should we use the only if there are interactive elements inside? Example: Explorer does not have interactive elements, but Search does. We need to have a consistent experience across VS Code, thus these questions. fyi
is a good question. I'll consult with our Accessibility team, but my initial thoughts are that we would need to change the role from a listitem. I'm not entirely sure if the best fit is a tree grid element or another role. wouldn't change all trees to treegrids as each role has its own set of implications and ignoring that would confuse screen reader users. If all these trees are derived from the same base class, I would add a constructor argument to differentiate treegrids and trees.
Looping back for the first question - I believe a grid/grid cell role would be best for that kind of component.
Let's assign to May as I would like to experiment with these changes at the start of a milestone
I have changed the role for the whole CALLSTACK to be a for this use case and for each item to be a . So now as you say users should expect more content when they press tab. If users get delighted by this change I would be open to do this in more views.
Hey - I appreciate the fix! Unfortunately, the component that we're using in our extension is the . Would it be possible to port the same fix over to this component considering this is the actual component our accessibility team is flagging up?
every tree item has an field which your extension can use to manipulate the role or the label of each tree property. I suggest you try using that. For example you could try different roles, or to make the label more verbose as Christian Heilmann suggested here Allowing extensions to change the role of the whole custom tree is currently not possible, and if that is what you would need then I would have to discuss with Alex Ross who is currently on vacation and this would require API changes.

return localize({ comment: ['Debug is a noun in this context, not a verb.'], key: 'callStackAriaLabel' }, "Debug Call Stack"); } <ins> getWidgetRole(): string { // Use treegrid as a role since each element can have additional actions inside #146210 return 'treegrid'; } getRole(_element: CallStackItem): string | undefined { return 'row'; } </ins> getAriaLabel(element: CallStackItem): string { if (element instanceof Thread) { return localize({ key: 'threadAriaLabel', comment: ['Placeholders stand for the thread name and the thread state.For example "Thread 1" and "Stopped'] }, "Thread {0} {1}", element.name, element.stateLabel);


Question:
Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !

dispose(): void; } <ins> function clearContainer(container: HTMLElement) { while (container.firstChild) { container.removeChild(container.firstChild); } } </ins> function renderImage(outputInfo: OutputItem, element: HTMLElement): IDisposable {


Question:
Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !

}; function renderHTML(outputInfo: OutputItem, container: HTMLElement): void { <ins> clearContainer(container); </ins> const htmlContent = outputInfo.text(); const element = document.createElement('div'); const trustedHtml = ttPolicy?.createHTML(htmlContent) ?? htmlContent;


Question:
Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !

} function renderText(outputInfo: OutputItem, container: HTMLElement, ctx: RendererContext<void> & { readonly settings: { readonly lineLimit: number } }): void { <ins> clearContainer(container); </ins> const contentNode = document.createElement('div'); contentNode.classList.add('output-plaintext'); const text = outputInfo.text();


Question:
System: Red Hat Enterprise Linux Workstation release 7.9 (Maipo) OS: Linux myhost 3.10.0-1160.36.2.el7.x8664 SMP Thu Jul 8 02:53:40 UTC 2021 x8664 x8664 x8664 GNU/Linux This began as an occasional annoyance and has escalated into a 100% reproducible annoyance. Using the latest snap install, during normal editing/debugging/etc. on local system. With increasing frequency, Ctrl-O/File-Open would completely freeze the UI with just a blinking cursor. Sometimes switching away and back would repaint part of the screen, increasingly not. Tried switching the output window to various things before attempting the file open (extension manager, main window, etc), but no output was observed before the freeze. Once the UI is frozen, only kill/killall seems to be able to get rid of it. Not sure if it means anything, but de-maximize and maximize still resize the window frame, although the contents aren't redrawn. Can't remember if that requires app cooperation or it that is a pure WM thing. Using snap installed code-insiders made no difference. Uninstalling snap versions and downloading 1.65.0 from the MS repo so far seems to have restored functionality (1.66.0 requires a glibc version unavailable for RHEL7). Haven't tried with (all) extensions disabled, but did disable everything I don't need constantly. One change in workflow recently seems suspiciously coordinated with the start of the issues - began using VS Code on another machine (nfs-mounted home folder, so shared settings/etc.) to attach to running containers (as container-specific user, to specific folder inside container), debug processes inside container, etc. Perhaps something got saved in the settings that is redirecting local File-Open to the remote-containers extension? Probably not, but the timing is mighty suspicious.
Interesting. With 1.65.0 still running, snap installed the latest (1.66.0) again and ran it with: Ctrl-O still hung the 1.66.0 app. Apparently it isn't an extension.
me is the same vscode is really disgusting
yes, I ran into the same problem, vscode hangs when execute any open command, open folder or open a file
Same for me on my Ubuntu 18.04 :-( Installed via tail of :
Also happening here, is there any known workaround at the moment to still open a folder? (Also seems to be related)
points to mismatched gtk library version loaded in the app process or others facing the issue, can you please follow the steps below and attach the generated profile
Thanks! Attached as requested above.
Is the log cut off ? I don't see most the library loads that are required for startup.
hmm, sorry, would be sufficient ? Because that is an only single output which I've got after execution. p.s. I am using managed PC and don't have permissions for :-(
In the past when I tried strace directly with snap packages and it would fail, hence I rely on the flag. Not sure if it works better now. No worries, I hope others hitting this issue might be able to provide the required trace. In the meantime, can you check if the issue exists with our debian package ?
Debian package works well (with some strange behavior). Thanks for a temporary solution. Strange behavior -maybe because I've disconnected all my monitors, but Open Folder dialog opens in background, thus I have to bring it manually to the foreground (but it is better than hanging program anyway ;-))
Here is the log I have with the instruction
I am also having this problem with the latest update (though I never had the application hanging problem) on Ubuntu 18.04
Thanks for the log, it confirms the root issue. Snap bundle ships with a version of libgtk3 that gets loaded by the app for all gtk operations, can be seen with With Electron 14 there was a refactor in the file dialog implementation to support XDG portal specification and the gtk library that was trying to be loaded as part of this is not bundled within the snap and in which case will search the system library paths, if the library cannot be found then the old code path will be utilized that will use the alreaedy loaded gtk library in the process but incases where it is found from the system and gets loaded, if the version mismatches with the already loaded library in the process, it causes the above app freeze. This should be fixed in Electron to use the same calls as chromium ;l=79-82? to load the gtk library.
so how should we solver it ?
I've got the exact same problem. So, if this has been fixed in Electron 18 when can we expect an update to VSCode? Because I'm on 1.67.1 and the error still persists.
This issue is very annoying: ! Hope upgrade to electron18 as soon as possible
This issue started for me after installing . Not sure if that is helpful? After removing this package (and also running afterwards), the issue was gone.
Got the newest version; but same error... Commit: Date: 2022-05-17T18:23:40.286Z Electron: 17.4.1 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Linux x64 4.15.0-177-generic snap
Update to Electron 18 is gonna take a bit longer, I will try to get the fix into Electron 17 as well. The issue is not yet addressed in our insiders and stable.
Latest version (from 2 days ago) still has the same bug (Ubuntu 18.04). Does anyone have a workaround? Any way to install an older version? EDIT: Downloading the Linux 64 .deb from solved the issue for me.
if you're just looking for a workaround, try the terminal command: or . It work's for me at least. But for a more solution maybe 's helps (I haven't tried it myself).
Same issue. Ubuntu 18.04. Channel: latest/stable: 2022-05-18 (97). thank you for the workaround. Removed new snap version and installed 1.65.0. Solved for me.
I was having a similar issue with vscode 1.67.2, non-snap on Ubuntu 20.04. After I noticed the issue I tried an apt upgrade, which didn't fix it. Downgrading to 1.65.2 fixed it for me. I am using i3 for window management.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Verification Steps: Install Ubuntu 18.04, images available from Install gtk3 <= 3.22, Install stable vscode from snap, Launch code and open the file explorer Verify application freezes Install insiders from snap, Launch code-insiders and open the file explorer Verify file explorer launches and application does not hang
can you help in verifying this since you have Ubuntu 18.04?
Hey , I can confirm that I get a dialog with the same setup and . Thanks! p.s. nevertheless, the strange behavior of dialog appearing in background remains the same as for previous solution using - but that is fine for now.

disturl "https://electronjs.org/headers" <del> target "17.4.6" </del> <ins> target "17.4.7" </ins> runtime "electron" build_from_source "true"


Question:
System: Red Hat Enterprise Linux Workstation release 7.9 (Maipo) OS: Linux myhost 3.10.0-1160.36.2.el7.x8664 SMP Thu Jul 8 02:53:40 UTC 2021 x8664 x8664 x8664 GNU/Linux This began as an occasional annoyance and has escalated into a 100% reproducible annoyance. Using the latest snap install, during normal editing/debugging/etc. on local system. With increasing frequency, Ctrl-O/File-Open would completely freeze the UI with just a blinking cursor. Sometimes switching away and back would repaint part of the screen, increasingly not. Tried switching the output window to various things before attempting the file open (extension manager, main window, etc), but no output was observed before the freeze. Once the UI is frozen, only kill/killall seems to be able to get rid of it. Not sure if it means anything, but de-maximize and maximize still resize the window frame, although the contents aren't redrawn. Can't remember if that requires app cooperation or it that is a pure WM thing. Using snap installed code-insiders made no difference. Uninstalling snap versions and downloading 1.65.0 from the MS repo so far seems to have restored functionality (1.66.0 requires a glibc version unavailable for RHEL7). Haven't tried with (all) extensions disabled, but did disable everything I don't need constantly. One change in workflow recently seems suspiciously coordinated with the start of the issues - began using VS Code on another machine (nfs-mounted home folder, so shared settings/etc.) to attach to running containers (as container-specific user, to specific folder inside container), debug processes inside container, etc. Perhaps something got saved in the settings that is redirecting local File-Open to the remote-containers extension? Probably not, but the timing is mighty suspicious.
Interesting. With 1.65.0 still running, snap installed the latest (1.66.0) again and ran it with: Ctrl-O still hung the 1.66.0 app. Apparently it isn't an extension.
me is the same vscode is really disgusting
yes, I ran into the same problem, vscode hangs when execute any open command, open folder or open a file
Same for me on my Ubuntu 18.04 :-( Installed via tail of :
Also happening here, is there any known workaround at the moment to still open a folder? (Also seems to be related)
points to mismatched gtk library version loaded in the app process or others facing the issue, can you please follow the steps below and attach the generated profile
Thanks! Attached as requested above.
Is the log cut off ? I don't see most the library loads that are required for startup.
hmm, sorry, would be sufficient ? Because that is an only single output which I've got after execution. p.s. I am using managed PC and don't have permissions for :-(
In the past when I tried strace directly with snap packages and it would fail, hence I rely on the flag. Not sure if it works better now. No worries, I hope others hitting this issue might be able to provide the required trace. In the meantime, can you check if the issue exists with our debian package ?
Debian package works well (with some strange behavior). Thanks for a temporary solution. Strange behavior -maybe because I've disconnected all my monitors, but Open Folder dialog opens in background, thus I have to bring it manually to the foreground (but it is better than hanging program anyway ;-))
Here is the log I have with the instruction
I am also having this problem with the latest update (though I never had the application hanging problem) on Ubuntu 18.04
Thanks for the log, it confirms the root issue. Snap bundle ships with a version of libgtk3 that gets loaded by the app for all gtk operations, can be seen with With Electron 14 there was a refactor in the file dialog implementation to support XDG portal specification and the gtk library that was trying to be loaded as part of this is not bundled within the snap and in which case will search the system library paths, if the library cannot be found then the old code path will be utilized that will use the alreaedy loaded gtk library in the process but incases where it is found from the system and gets loaded, if the version mismatches with the already loaded library in the process, it causes the above app freeze. This should be fixed in Electron to use the same calls as chromium ;l=79-82? to load the gtk library.
so how should we solver it ?
I've got the exact same problem. So, if this has been fixed in Electron 18 when can we expect an update to VSCode? Because I'm on 1.67.1 and the error still persists.
This issue is very annoying: ! Hope upgrade to electron18 as soon as possible
This issue started for me after installing . Not sure if that is helpful? After removing this package (and also running afterwards), the issue was gone.
Got the newest version; but same error... Commit: Date: 2022-05-17T18:23:40.286Z Electron: 17.4.1 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Linux x64 4.15.0-177-generic snap
Update to Electron 18 is gonna take a bit longer, I will try to get the fix into Electron 17 as well. The issue is not yet addressed in our insiders and stable.
Latest version (from 2 days ago) still has the same bug (Ubuntu 18.04). Does anyone have a workaround? Any way to install an older version? EDIT: Downloading the Linux 64 .deb from solved the issue for me.
if you're just looking for a workaround, try the terminal command: or . It work's for me at least. But for a more solution maybe 's helps (I haven't tried it myself).
Same issue. Ubuntu 18.04. Channel: latest/stable: 2022-05-18 (97). thank you for the workaround. Removed new snap version and installed 1.65.0. Solved for me.
I was having a similar issue with vscode 1.67.2, non-snap on Ubuntu 20.04. After I noticed the issue I tried an apt upgrade, which didn't fix it. Downgrading to 1.65.2 fixed it for me. I am using i3 for window management.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Verification Steps: Install Ubuntu 18.04, images available from Install gtk3 <= 3.22, Install stable vscode from snap, Launch code and open the file explorer Verify application freezes Install insiders from snap, Launch code-insiders and open the file explorer Verify file explorer launches and application does not hang
can you help in verifying this since you have Ubuntu 18.04?
Hey , I can confirm that I get a dialog with the same setup and . Thanks! p.s. nevertheless, the strange behavior of dialog appearing in background remains the same as for previous solution using - but that is fine for now.

"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "3a1945bd6c62459a457bd8d0b922259234816e22" </del> <ins> "commitHash": "66dd03293be5c6c7a06e1517bb80100030973be6" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "17.4.6" </del> <ins> "version": "17.4.7" </ins> }, { "component": {


Question:
System: Red Hat Enterprise Linux Workstation release 7.9 (Maipo) OS: Linux myhost 3.10.0-1160.36.2.el7.x8664 SMP Thu Jul 8 02:53:40 UTC 2021 x8664 x8664 x8664 GNU/Linux This began as an occasional annoyance and has escalated into a 100% reproducible annoyance. Using the latest snap install, during normal editing/debugging/etc. on local system. With increasing frequency, Ctrl-O/File-Open would completely freeze the UI with just a blinking cursor. Sometimes switching away and back would repaint part of the screen, increasingly not. Tried switching the output window to various things before attempting the file open (extension manager, main window, etc), but no output was observed before the freeze. Once the UI is frozen, only kill/killall seems to be able to get rid of it. Not sure if it means anything, but de-maximize and maximize still resize the window frame, although the contents aren't redrawn. Can't remember if that requires app cooperation or it that is a pure WM thing. Using snap installed code-insiders made no difference. Uninstalling snap versions and downloading 1.65.0 from the MS repo so far seems to have restored functionality (1.66.0 requires a glibc version unavailable for RHEL7). Haven't tried with (all) extensions disabled, but did disable everything I don't need constantly. One change in workflow recently seems suspiciously coordinated with the start of the issues - began using VS Code on another machine (nfs-mounted home folder, so shared settings/etc.) to attach to running containers (as container-specific user, to specific folder inside container), debug processes inside container, etc. Perhaps something got saved in the settings that is redirecting local File-Open to the remote-containers extension? Probably not, but the timing is mighty suspicious.
Interesting. With 1.65.0 still running, snap installed the latest (1.66.0) again and ran it with: Ctrl-O still hung the 1.66.0 app. Apparently it isn't an extension.
me is the same vscode is really disgusting
yes, I ran into the same problem, vscode hangs when execute any open command, open folder or open a file
Same for me on my Ubuntu 18.04 :-( Installed via tail of :
Also happening here, is there any known workaround at the moment to still open a folder? (Also seems to be related)
points to mismatched gtk library version loaded in the app process or others facing the issue, can you please follow the steps below and attach the generated profile
Thanks! Attached as requested above.
Is the log cut off ? I don't see most the library loads that are required for startup.
hmm, sorry, would be sufficient ? Because that is an only single output which I've got after execution. p.s. I am using managed PC and don't have permissions for :-(
In the past when I tried strace directly with snap packages and it would fail, hence I rely on the flag. Not sure if it works better now. No worries, I hope others hitting this issue might be able to provide the required trace. In the meantime, can you check if the issue exists with our debian package ?
Debian package works well (with some strange behavior). Thanks for a temporary solution. Strange behavior -maybe because I've disconnected all my monitors, but Open Folder dialog opens in background, thus I have to bring it manually to the foreground (but it is better than hanging program anyway ;-))
Here is the log I have with the instruction
I am also having this problem with the latest update (though I never had the application hanging problem) on Ubuntu 18.04
Thanks for the log, it confirms the root issue. Snap bundle ships with a version of libgtk3 that gets loaded by the app for all gtk operations, can be seen with With Electron 14 there was a refactor in the file dialog implementation to support XDG portal specification and the gtk library that was trying to be loaded as part of this is not bundled within the snap and in which case will search the system library paths, if the library cannot be found then the old code path will be utilized that will use the alreaedy loaded gtk library in the process but incases where it is found from the system and gets loaded, if the version mismatches with the already loaded library in the process, it causes the above app freeze. This should be fixed in Electron to use the same calls as chromium ;l=79-82? to load the gtk library.
so how should we solver it ?
I've got the exact same problem. So, if this has been fixed in Electron 18 when can we expect an update to VSCode? Because I'm on 1.67.1 and the error still persists.
This issue is very annoying: ! Hope upgrade to electron18 as soon as possible
This issue started for me after installing . Not sure if that is helpful? After removing this package (and also running afterwards), the issue was gone.
Got the newest version; but same error... Commit: Date: 2022-05-17T18:23:40.286Z Electron: 17.4.1 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Linux x64 4.15.0-177-generic snap
Update to Electron 18 is gonna take a bit longer, I will try to get the fix into Electron 17 as well. The issue is not yet addressed in our insiders and stable.
Latest version (from 2 days ago) still has the same bug (Ubuntu 18.04). Does anyone have a workaround? Any way to install an older version? EDIT: Downloading the Linux 64 .deb from solved the issue for me.
if you're just looking for a workaround, try the terminal command: or . It work's for me at least. But for a more solution maybe 's helps (I haven't tried it myself).
Same issue. Ubuntu 18.04. Channel: latest/stable: 2022-05-18 (97). thank you for the workaround. Removed new snap version and installed 1.65.0. Solved for me.
I was having a similar issue with vscode 1.67.2, non-snap on Ubuntu 20.04. After I noticed the issue I tried an apt upgrade, which didn't fix it. Downgrading to 1.65.2 fixed it for me. I am using i3 for window management.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Verification Steps: Install Ubuntu 18.04, images available from Install gtk3 <= 3.22, Install stable vscode from snap, Launch code and open the file explorer Verify application freezes Install insiders from snap, Launch code-insiders and open the file explorer Verify file explorer launches and application does not hang
can you help in verifying this since you have Ubuntu 18.04?
Hey , I can confirm that I get a dialog with the same setup and . Thanks! p.s. nevertheless, the strange behavior of dialog appearing in background remains the same as for previous solution using - but that is fine for now.

"cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "17.4.6", </del> <ins> "electron": "17.4.7", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^19.1.0",


Question:
System: Red Hat Enterprise Linux Workstation release 7.9 (Maipo) OS: Linux myhost 3.10.0-1160.36.2.el7.x8664 SMP Thu Jul 8 02:53:40 UTC 2021 x8664 x8664 x8664 GNU/Linux This began as an occasional annoyance and has escalated into a 100% reproducible annoyance. Using the latest snap install, during normal editing/debugging/etc. on local system. With increasing frequency, Ctrl-O/File-Open would completely freeze the UI with just a blinking cursor. Sometimes switching away and back would repaint part of the screen, increasingly not. Tried switching the output window to various things before attempting the file open (extension manager, main window, etc), but no output was observed before the freeze. Once the UI is frozen, only kill/killall seems to be able to get rid of it. Not sure if it means anything, but de-maximize and maximize still resize the window frame, although the contents aren't redrawn. Can't remember if that requires app cooperation or it that is a pure WM thing. Using snap installed code-insiders made no difference. Uninstalling snap versions and downloading 1.65.0 from the MS repo so far seems to have restored functionality (1.66.0 requires a glibc version unavailable for RHEL7). Haven't tried with (all) extensions disabled, but did disable everything I don't need constantly. One change in workflow recently seems suspiciously coordinated with the start of the issues - began using VS Code on another machine (nfs-mounted home folder, so shared settings/etc.) to attach to running containers (as container-specific user, to specific folder inside container), debug processes inside container, etc. Perhaps something got saved in the settings that is redirecting local File-Open to the remote-containers extension? Probably not, but the timing is mighty suspicious.
Interesting. With 1.65.0 still running, snap installed the latest (1.66.0) again and ran it with: Ctrl-O still hung the 1.66.0 app. Apparently it isn't an extension.
me is the same vscode is really disgusting
yes, I ran into the same problem, vscode hangs when execute any open command, open folder or open a file
Same for me on my Ubuntu 18.04 :-( Installed via tail of :
Also happening here, is there any known workaround at the moment to still open a folder? (Also seems to be related)
points to mismatched gtk library version loaded in the app process or others facing the issue, can you please follow the steps below and attach the generated profile
Thanks! Attached as requested above.
Is the log cut off ? I don't see most the library loads that are required for startup.
hmm, sorry, would be sufficient ? Because that is an only single output which I've got after execution. p.s. I am using managed PC and don't have permissions for :-(
In the past when I tried strace directly with snap packages and it would fail, hence I rely on the flag. Not sure if it works better now. No worries, I hope others hitting this issue might be able to provide the required trace. In the meantime, can you check if the issue exists with our debian package ?
Debian package works well (with some strange behavior). Thanks for a temporary solution. Strange behavior -maybe because I've disconnected all my monitors, but Open Folder dialog opens in background, thus I have to bring it manually to the foreground (but it is better than hanging program anyway ;-))
Here is the log I have with the instruction
I am also having this problem with the latest update (though I never had the application hanging problem) on Ubuntu 18.04
Thanks for the log, it confirms the root issue. Snap bundle ships with a version of libgtk3 that gets loaded by the app for all gtk operations, can be seen with With Electron 14 there was a refactor in the file dialog implementation to support XDG portal specification and the gtk library that was trying to be loaded as part of this is not bundled within the snap and in which case will search the system library paths, if the library cannot be found then the old code path will be utilized that will use the alreaedy loaded gtk library in the process but incases where it is found from the system and gets loaded, if the version mismatches with the already loaded library in the process, it causes the above app freeze. This should be fixed in Electron to use the same calls as chromium ;l=79-82? to load the gtk library.
so how should we solver it ?
I've got the exact same problem. So, if this has been fixed in Electron 18 when can we expect an update to VSCode? Because I'm on 1.67.1 and the error still persists.
This issue is very annoying: ! Hope upgrade to electron18 as soon as possible
This issue started for me after installing . Not sure if that is helpful? After removing this package (and also running afterwards), the issue was gone.
Got the newest version; but same error... Commit: Date: 2022-05-17T18:23:40.286Z Electron: 17.4.1 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Linux x64 4.15.0-177-generic snap
Update to Electron 18 is gonna take a bit longer, I will try to get the fix into Electron 17 as well. The issue is not yet addressed in our insiders and stable.
Latest version (from 2 days ago) still has the same bug (Ubuntu 18.04). Does anyone have a workaround? Any way to install an older version? EDIT: Downloading the Linux 64 .deb from solved the issue for me.
if you're just looking for a workaround, try the terminal command: or . It work's for me at least. But for a more solution maybe 's helps (I haven't tried it myself).
Same issue. Ubuntu 18.04. Channel: latest/stable: 2022-05-18 (97). thank you for the workaround. Removed new snap version and installed 1.65.0. Solved for me.
I was having a similar issue with vscode 1.67.2, non-snap on Ubuntu 20.04. After I noticed the issue I tried an apt upgrade, which didn't fix it. Downgrading to 1.65.2 fixed it for me. I am using i3 for window management.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Verification Steps: Install Ubuntu 18.04, images available from Install gtk3 <= 3.22, Install stable vscode from snap, Launch code and open the file explorer Verify application freezes Install insiders from snap, Launch code-insiders and open the file explorer Verify file explorer launches and application does not hang
can you help in verifying this since you have Ubuntu 18.04?
Hey , I can confirm that I get a dialog with the same setup and . Thanks! p.s. nevertheless, the strange behavior of dialog appearing in background remains the same as for previous solution using - but that is fine for now.

resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.45.tgz#cf1144091d6683cbd45a231954a745f02fb24598" integrity sha512-czF9eYVuOmlY/vxyMQz2rGlNSjZpxNQYBe1gmQv7al171qOIhgyO9k7D5AKlgeTCSPKk+LHhj5ZyIdmEub9oNg== <del> electron@17.4.6: version "17.4.6" resolved "https://registry.yarnpkg.com/electron/-/electron-17.4.6.tgz#4837b3adb2636992a33da734a77794dd932fb05c" integrity sha512-9aPjlyWoVxchD/iw5KcbQ7ZaC5ezxsObBrMbGjpdMmDL5dktI0EkT6x2l2CYPZCi4rQG/6qlPfTZJeVPIIwI2Q== </del> <ins> electron@17.4.7: version "17.4.7" resolved "https://registry.yarnpkg.com/electron/-/electron-17.4.7.tgz#5ae9105f2ee28e6405c79c7101f0c956676da697" integrity sha512-CMdUpd6oEwqbF7wcXwy9VNNXfTTbaeRg+zrGZciPzyzsEmJ9vzWcR1WpOxIQ4sIMjUyo1pFbvaD0VOgI2t4x3A== </ins> dependencies: "@electron/get" "^1.13.0" "@types/node" "^14.6.2"


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.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR. I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at . I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up! I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

disturl "https://electronjs.org/headers" <del> target "19.0.11" </del> <ins> target "19.0.12" </ins> runtime "electron" build_from_source "true"


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.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR. I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at . I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up! I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {