Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "19.1.8", </del> <ins> "electron": "19.1.9", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

jupyter-keymap1.0.0 jupyter-renderers1.0.12 vscode-jupyter-cell-tags0.1.6 vscode-jupyter-slideshow0.1.5 remote-containers0.266.1 remote-ssh0.94.0 remote-ssh-edit0.84.0 remote-wsl0.72.0 vscode-remote-extensionpack0.23.0 cmake-tools1.12.27 cpptools1.13.8 cpptools-extension-pack1.3.0 makefile-tools0.6.0 powershell2022.12.1 remote-explorer0.0.3 vsliveshare1.0.5788 vsliveshare-audio0.1.91 vsliveshare-pack0.4.0 gremlins0.26.0 format-html-in-php1.7.0 nunjucks0.3.1 markdown-preview-enhanced0.6.5 code-spell-checker2.12.0 best-light-themes-pack1.0.2 cmake0.0.17 theme-generator0.0.8 php-debug1.29.1 php-pack1.0.3 linkerscript1.0.2 php-intellisense1.0.13 (11 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.74.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Updated to the latest version still same issue
Which find widget is it? Is it the find within a file or globally across the workspace?
Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our . Please take the time to review these and update the issue. Happy Coding!
It's within a file
are you searching against a large file? Can you please share the document you search if possible to help troubleshoot?
Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our . Please take the time to review these and update the issue. Happy Coding!
I used this text in a new file and when I did the above steps it crashed my system.


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "19.1.8", </del> <ins> "electron": "19.1.9", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

It's pure javascript code but not sure how this can crash the system. Assigning to our Electron experts.
Hi, could you attach a ?
It is not creating a dump file. Any suggestions to getting crash data from linux (Pop!_OS)
Can you please share a screen recording of the steps you have tried to get the crash dumps, thanks!
I finally got it to dump. Let me know if there is anything else I can do to help
Are you using a screen reader ? Seems like accessibility tree is enabled in your instance and the crash stacks point to Segmentation fault in the accessibility code path. Crash is addressed in
cannot repro, but would be good if also verifies this is fixed
I used the latest insiders and it worked as expected. Thank you very much! I tired it on the current release to make sure it was not fixed by me updating my system. The current release still crashed.
Also to note in current release I disabled all plugins and it still crashed and anytime I do it twice it crashes my whole system. So it is definitely fixed in the insider release


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "19.1.8", </del> <ins> "electron": "19.1.9", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.74.0 (Universal) OS Version: MacOS Monterrey 12.5.1 (21G83) While using a window manager on Mac (Mosaic), I'm not able to resize / place the vscode window on the designated location on the screen. This is relatively new behavior, can confirm this was not an issue prior to release . I believe this release started this bug. vs code is the only application I know of that has this issue. I included a screen recording showing the problem. https://user- Steps to Reproduce: a window manager (mosaic), drag and drop vscode into any of the resizing blocks.
requires a purchase, is there a repro with other open source window managers ? In your demo, you seem to using native titlebar. Does the issue repro when launching with ?
Hi I was unable to reproduce it with a free alternative from the apple store (). Setting was not successful either. Normally I would approach the developer of Mosaic myself but it's only vs code that stands out here, every other app I know of (30+) work just fine. Even vs code used to work like any other app, hence this bug report. Mosaic does have a 7 day free trial if that's of any help:
I actually went for that but I just get pop-up that trial is expired on starting the application :( I have an idea what might have caused this issue in the runtime, Can you maybe help with confirming the issue by following the steps below which requires running VSCode from source.


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "19.1.8", </del> <ins> "electron": "19.1.9", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

If the above steps are difficult to attempt now, I will try to provide a custom build later this week to verify.
Thanks for the update. Will give this a try and get back to you
Hi sorry for the long wait. Happy new year by the way! I followed your steps and I can confirm that running with from source I can resize/reposition windows just fine with Mosaic.
Happy new year :) and Thanks for confirming. As part of an accessibility experiment we disabled the attribute in the which looks like the Mosaic window manager relies on.


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "19.1.8", </del> <ins> "electron": "19.1.9", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

From: Crash dump: I tried to use but the result seems weird, maybe you can help me explain how you do it? Attaching the output here:
will use symbols from which does not contain symbols for our custom Electron builds, so you will have to manually replace the symbols under with corresponding ones extracted from
should address this crash.
but then our instructions are not correct right? can we please update them to explain how to do this step by step? thanks!


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "19.1.8", </del> <ins> "electron": "19.1.9", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

Just upgraded to macos 12.3, try to ENABLE System Integrity Protection if you have disabled it before: Originally posted by in
[(42)] opendir /Users/xxx/Library/Application Support/Code/Crashpad/attachments/-107c-4a3e-8990-: No such file or directory (2) objc[2187]: Class WebSwapCGLLayer is implemented in both /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/Frameworks/libANGLE- (0x7ffa4f13a8f0) and /Applications/Visual Studio (0x115684ce0). One of the two will be used. Which one is undefined. [(171)] EXCCRASH should not contain exception 12 [(70)] exception EXCGUARD invalid in EXCCRASH [main 2022-11-01T07:19:07.195Z] CodeWindow: renderer process gone (reason: killed, code: 9)
Local OS Version: macOS 13.0 (22A380)
If the issue persists with latest stable , can you provide the crash logs following the steps at , thanks!
my version is 1.74
In your case, is SIP enabled or disabled ? Does it crash when you run with ?
! The same mistake. Are you running normally on the latest Mac 13 system
I think is not specifically a vscode problem. Im getting this for every Chromium <108 based electron app like: Logitech G-Hub I replaced the with the latest it working since but please don't do that it requires SIP disabled and this is not a solution not even a workaround. !
This "not even a workaround" works here as well. Thank you for sharing! SIP was reduced beforehand due to OCLP, so I don't know about it. But definitely not recommended reducing/disabling it! For anyone curios:
If you are using OCLP with reduced SIP you just need to add ipccontrolport_options=0 to the nvram boot-args.


Question: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.8.0", <del> "electron": "19.1.8", </del> <ins> "electron": "19.1.9", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",

Upstream issue
sudo nvram boot-args="-v csenforcementdisable=1 amfigetoutofmyway=1 keepsyms=1 intcoprocunrestricted=1 amfiunrestricttaskforpid=1 amfiallowanysignature=1 csdebug=1 ipccontrolport_options=0" exec this command,program is ok
are there steps for this?
this requires booting macOS with custom arguments specifically SIP and AMFI disabled, better for authors to verify this issue. can you help verify if this issue is addressed with our latest insiders without having to add to the boot args, thanks!
Are there any conclusions? I also have this problem
this will be fixed in our next stable release
Today it keeps failing. !
please create a new issue with crash dumps based on the steps here , thanks!


Question: }, 'workbench.editor.enablePreviewFromQuickOpen': { 'type': 'boolean', <del> 'markdownDescription': localize('enablePreviewFromQuickOpen', "Controls whether editors opened from Quick Open show as preview editors. Preview editors do not stay open, and are reused until explicitly set to be kept open (via double click or editing). This value is ignored when `#workbench.editor.enablePreview#` is disabled."), </del> <ins> 'markdownDescription': localize('enablePreviewFromQuickOpen', "Controls whether editors opened from Quick Open show as preview editors. Preview editors do not stay open, and are reused until explicitly set to be kept open (via double click or editing). When enabled, hold Ctrl before selection to open an editor as a non-preview. This value is ignored when `#workbench.editor.enablePreview#` is disabled."), </ins> 'default': false }, 'workbench.editor.enablePreviewFromCodeNavigation': {

<!-- 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.73.0 (Universal) OS Version: 13.0 Steps to Reproduce: open (cmd+p) file The UI button for from quick open works. The shortcut also works for file selection in the explorer My settings: Related to
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.73.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Setting aside your Ctrl+Enter issue, did you know that Ctrl+RightArrow will already do what you want? It intentionally leaves the quickpick open so you can open another of the matches, but it's easy enough to close by pressing Esc.
ctrl+enter appears to be working for me even with your settings. What is it doing for you?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
sorry for the late reply. has the same effect as for me, it opens the file in the current tab. this also opens the file in the current tab for me, leaving quickopen open
if you remove these keybinding settings, does anything change? I'd also love to see what settings you have in your user settings to see if maybe something is up there.
Thanks for reaching back. I commented all keyboard shortcuts and disabled all extensions. Indeed I got it to work when I commented all config of . Then I got to pinpoint it to this setting: which apparently needs to be .


Question: }, 'workbench.editor.enablePreviewFromQuickOpen': { 'type': 'boolean', <del> 'markdownDescription': localize('enablePreviewFromQuickOpen', "Controls whether editors opened from Quick Open show as preview editors. Preview editors do not stay open, and are reused until explicitly set to be kept open (via double click or editing). This value is ignored when `#workbench.editor.enablePreview#` is disabled."), </del> <ins> 'markdownDescription': localize('enablePreviewFromQuickOpen', "Controls whether editors opened from Quick Open show as preview editors. Preview editors do not stay open, and are reused until explicitly set to be kept open (via double click or editing). When enabled, hold Ctrl before selection to open an editor as a non-preview. This value is ignored when `#workbench.editor.enablePreview#` is disabled."), </ins> 'default': false }, 'workbench.editor.enablePreviewFromCodeNavigation': {

Thanks for your help!
That's interesting. is there are scenario where we can open to the side but as a preview? I wonder if this is why this setting affects the behavior.
This is driven by this line: I can only speculate that when I re-implemented quick open, I took this behaviour over from our first version. If I had to guess, then we had this rule back then: always opens to the side opens an editor as non-preview when preview editors are enabled opens an editor to the side when preview editors are disabled So I would argue that -click is the key to use here, same as for the explorer for example. And has special semantics depending on your settings. But we can certainly revisit this and make it consistent if there is inconsistency.
Thanks. That is the behavior I see. Maybe we update the setting description to make this more clear? Current: Maybe we add: "non-preview" or whatever jargon we use. Thoughts Not entirely sure we need to define Preview editor here too.
Yeah I like the idea of updating settings, feel free to do that!
verification: read the docs for the settings. Does the use of there make sense (knowing that we don't want to change the behavior)


Question: } } catch (error) { addToSkipped.push(e); <del> if (error instanceof ExtensionManagementError && [ExtensionManagementErrorCode.Incompatible, ExtensionManagementErrorCode.IncompatiblePreRelease, ExtensionManagementErrorCode.IncompatibleTargetPlatform].includes(error.code)) { this.logService.info(`${syncResourceLogLabel}: Skipped synchronizing extension because the compatible extension is not found.`, extension.displayName || extension.identifier.id); } else { this.logService.error(error); this.logService.info(`${syncResourceLogLabel}: Skipped synchronizing extension`, extension.displayName || extension.identifier.id); } </del> <ins> this.logService.error(error); this.logService.info(`${syncResourceLogLabel}: Skipped synchronizing extension`, extension.displayName || extension.identifier.id); </ins> } } else { addToSkipped.push(e); this.logService.info(`${syncResourceLogLabel}: Skipped synchronizing extension because the extension is not found.`, e.identifier.id); } })); <del> } </del> <ins> }); } </ins> <del> const newSkippedExtensions: ISyncExtension[] = []; for (const skippedExtension of skippedExtensions) { if (!removeFromSkipped.some(e => areSameExtensions(e, skippedExtension.identifier))) { newSkippedExtensions.push(skippedExtension); </del> <ins> // 2. Next uninstall the removed extensions if (removed.length) { const extensionsToRemove = installedExtensions.filter(({ identifier, isBuiltin }) => !isBuiltin && removed.some(r => areSameExtensions(identifier, r))); await Promises.settled(extensionsToRemove.map(async extensionToRemove => { this.logService.trace(`${syncResourceLogLabel}: Uninstalling local extension...`, extensionToRemove.identifier.id); await this.extensionManagementService.uninstall(extensionToRemove, { donotIncludePack: true, donotCheckDependents: true, profileLocation: profile.extensionsResource }); this.logService.info(`${syncResourceLogLabel}: Uninstalled local extension.`, extensionToRemove.identifier.id); removeFromSkipped.push(extensionToRemove.identifier); })); } // 3. Install extensions at the end for (const [e, extension] of extensionsToInstall) { try { this.logService.trace(`${syncResourceLogLabel}: Installing extension...`, extension.identifier.id, extension.version); await this.extensionManagementService.installFromGallery(extension, { isMachineScoped: false/* set isMachineScoped value to prevent install and sync dialog in web */, donotIncludePackAndDependencies: true, installPreReleaseVersion: e.preRelease, profileLocation: profile.extensionsResource, context: { [EXTENSIONS_SYNC_CONTEXT_KEY]: true } }); this.logService.info(`${syncResourceLogLabel}: Installed extension.`, extension.identifier.id, extension.version); removeFromSkipped.push(extension.identifier); } catch (error) { addToSkipped.push(e); if (error instanceof ExtensionManagementError && [ExtensionManagementErrorCode.Incompatible, ExtensionManagementErrorCode.IncompatiblePreRelease, ExtensionManagementErrorCode.IncompatibleTargetPlatform].includes(error.code)) { this.logService.info(`${syncResourceLogLabel}: Skipped synchronizing extension because the compatible extension is not found.`, extension.displayName || extension.identifier.id); } else { this.logService.error(error); this.logService.info(`${syncResourceLogLabel}: Skipped synchronizing extension`, extension.displayName || extension.identifier.id); </ins> } } <del> for (const skippedExtension of addToSkipped) { if (!newSkippedExtensions.some(e => areSameExtensions(e.identifier, skippedExtension.identifier))) { newSkippedExtensions.push(skippedExtension); } </del> <ins> } const newSkippedExtensions: ISyncExtension[] = []; for (const skippedExtension of skippedExtensions) { if (!removeFromSkipped.some(e => areSameExtensions(e, skippedExtension.identifier))) { newSkippedExtensions.push(skippedExtension); </ins> } <del> return newSkippedExtensions; }); </del> <ins> } for (const skippedExtension of addToSkipped) { if (!newSkippedExtensions.some(e => areSameExtensions(e.identifier, skippedExtension.identifier))) { newSkippedExtensions.push(skippedExtension); } } return newSkippedExtensions; </ins> } private updateExtensionState(state: IStringDictionary<any>, extension: ILocalExtension | IGalleryExtension, version: string | undefined, extensionStorageService: IExtensionStorageService): void {

I don't think the state of walkthrough progress is synced between machines, so I see this on each new machine I setup: !
Again, we do try to sync the state but there may be a race where it's not available in time. I'll investigate more..
Fixed it by adding the context to the installation event when extensions are synced by settings sync. Walk through component shall simply ignore walk through for those extensions which are installed by settings sync (irrespective of the walk through state is synced or not).


Question: import { DisposableStore, dispose, IDisposable } from 'vs/base/common/lifecycle'; import { ScrollEvent } from 'vs/base/common/scrollable'; import { IThemable } from 'vs/base/common/styler'; <ins> import { isIterable } from 'vs/base/common/types'; </ins> interface IAsyncDataTreeNode<TInput, T> { element: TInput | T;

takes much longer to render with file nesting enabled. Impact is lessened by disabling file nest auto-expansions. is not significantly slower to render with nesting, though I have not collected proper numbers yet.
closedWith
takes a comparable amount of time to render with file nesting enabled, though there is a perceptible delay for both. However, I do also notice that the window becomes intermittently unresponsive after expanding , e.g. when scrolling in the explorer. Is this known?
Yeah, same thing happens with nesting disabled. There's an open issue somewhere for ways to reduce that (like streaming the dir contents).


Question: }); } <del> private static _createItemKindFilter(editor: ICodeEditor): Set<CompletionItemKind> { </del> <ins> private static _createSuggestFilter(editor: ICodeEditor): { itemKind: Set<CompletionItemKind>; showDeprecated: boolean } { </ins> // kind filter and snippet sort rules const result = new Set<CompletionItemKind>();

I'd like a setting to optionally prevent deprecated things from showing up in intellisense suggestions. For example, I'd like a way to prevent from being suggested here, so that I don't use it despite a non-deprecated version being available. ! My linter can catch it, but it'd be even nicer never to see the deprecated option. There are several documentation systems that use the tag: JSDoc: TSDoc: JavaDoc: Yard (for Ruby): Other systems use different, similar tags. I'm not sure if this is an issue for the VSCode core, or for something language-specific.
Sorry if this is a duplicate or is already possible. There are enough issues here and questions/answers on Stack Overflow that it's hard to be confident. This issue is related:
Not showing deprecated suggestions can be implemented by individual language extensions today (not striking out but tracks that). Adding just to see this is something we want better VS Code api support for in some way Otherwise, we can track this as a feature request for js/s
I'd say this is a dupe of and it would be us adding some API flag and then allows users to configure how the suggest UX is handling that flag
/duplicate of
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues . See also our guidelines. Happy Coding!
Okay, that makes sense. What does "js/s" mean?
is it possible to add a setting like , so I can disable it to prevent deprecated from showing up in suggestions list?
Hey any update on that?
Verify that the setting exists and that it filters deprecated elements from IntelliSense


Question: assertSelections(editor, new Selection(1, 22, 1, 22)); }); <del> test('A little confusing visual effect of highlighting for snippet tabstop #43270', async function () { </del> <ins> test('User defined snippet tab stops ignored #72862', function () { </ins> const ctrl = new SnippetController2(editor, logService, contextKeys); model.setValue(''); editor.setSelection(new Selection(1, 1, 1, 1)); <del> ctrl.insert('background-color: ${1:fff};$0'); assertSelections(editor, new Selection(1, 19, 1, 22)); editor.setSelection(new Selection(1, 22, 1, 22)); </del> <ins> ctrl.insert('export default $1'); </ins> assertContextKeys(contextKeys, true, false, true); <del> editor.trigger('', 'deleteRight', null); assert.equal(model.getValue(), 'background-color: fff'); await timeout(0); // this depends on re-scheduling of events... assertContextKeys(contextKeys, false, false, false); </del> }); });

<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.33.1 OS Version: Windows_NT x64 10.0. Steps to Reproduce: a new user snippet file for the project. The one I encounter the issue with is: the snippet and attempt to press TAB after writing the first variable cursor does not move to the next stop, instead a tab character is The desired behavior would be for the cursor to move to the next tab stop. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Seems to work just fine for me... Any special keybinding or setting? !
The action you took is not the problem I encounter and does indeed work the same way for me. Could you try to edit "SystemName", the first tab stop, then press TAB to go to "Required Components"? vsCode just inserts a tab character after whatever I wrote instead of going to the next tab stop.
Ok, thanks for clarifying. For some reason snippet mode stops when making that edit... Not sure why
I have encountered similar issue, however, I could add a single blank space in the snippet which "fixed" the tab navigation. Also, my example is far simpler. See
This is a regression from I will revert that change and re-open the corresponding issue (which is much more rare than these issues)
Thank you for fixing this, looking forward to the next release.


Question: if (!model) { return false; } <del> if (model.uri.scheme === 'output') { // in output editor return false; } </del> if (editor.getOption(EditorOption.inDiffEditor)) { // this editor belongs to a diff editor for (const diffEditor of codeEditorService.listDiffEditors()) {

Visual Studio's Output window has a "Toggle Word Wrap" button, but VS Code has word wrapping always (?) enabled. For certain scenarious like the pending "C/C++ References" output it is desirable for word wrapping to be disabled for the results to be more easily read. There is a "View: Toggle Word Wrap" command, but it applies to the active document only (and not the Output panel, even if it's active). And/or if the OutputChannel interface could add a toggleWordWrap capability, that would allow extensions to set an appropriate default for their particular Output channel. This seems like a pretty basic feature that other Output channel providers would want, but I couldn't find an existing feature request on this.
This describes the same issue and led to adding a config option but it doesn't seem to work or the feature request was misunderstood?
Thanks a lot -- I can use that [Log] setting as a workaround (by setting it in our configurationDefaults); however, the result is still not ideal because it will apply to all Output windows and our C/C++ extension would prefer to isolate the behavior to a specific one. (And a button in the UI would make it easier for users to figure out how to overwrite our "no wrap" default).
Currently, one workaround is to set:
Yes, that is the same workaround I was describing (which our C/C++ extension uses), but it applies to all the output panes, and we'd prefer to isolate the change to a particular output pane (e.g. "C/C++" or "C/C++ References" and not "Git", etc.).
that's a nice to have feature.
For log files, I had the word wrap button visible & after a few moments it just disappeared
It looks like the 'editor.wordWrap' setting no longer works for [Log]. Was it removed intentionally or it is a bug?
That setting is working for me with non-Insiders VS Code with our C/C++ output window, but I see certain output panes like "Window" ignoring the setting somehow (i.e. it always wraps).
Ah, it's working for me now. It looks like it requires a Reload Window after it is set.
command is now also supported for Output Channels.


Question: 'libdrm2 (>= 2.4.38)', 'libexpat1 (>= 2.0.1)', 'libgbm1 (>= 8.1~0)', <del> 'libgcc-s1 (>= 3.0)', 'libgcc-s1 (>= 3.5)', </del> 'libglib2.0-0 (>= 2.16.0)', 'libglib2.0-0 (>= 2.39.4)', 'libgtk-3-0 (>= 3.9.10)',

<!-- 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: Insiders 1.71 OS Version: Ubuntu 18.04 amd64 Steps to Reproduce: to install latest code-insiders packages from MS repository () The issue is that with the dependency on Debian derivatives changed to which only exists on newer releases (20.04 and later I think). I realise that support for Ubuntu-Ancient is low on the priority list, but I am sadly stuck with it, and would appreciate if there was a workaround. Installing newer libgcc releases as suggested in some places easily leads to a very broken system.
This is a side effect of now using bullseye sysroot, we should apply the following change https://chromium- to our debian calculate package deps.


Question: # means the user re-exported the PS1 so we should re-wrap it if [[ "$__vsc_custom_PS1" == "" || "$__vsc_custom_PS1" != "$PS1" ]]; then __vsc_original_PS1=$PS1 <del> __vsc_custom_PS1="[$(__vsc_prompt_start)]$PREFIX$__vsc_original_PS1[$(__vsc_prompt_end)]" </del> <ins> __vsc_custom_PS1="[$(__vsc_prompt_start)]$__vsc_original_PS1[$(__vsc_prompt_end)]" </ins> PS1="$__vsc_custom_PS1" fi if [[ "$__vsc_custom_PS2" == "" || "$__vsc_custom_PS2" != "$PS2" ]]; then

Type: <bBug</bIn the new shell integration options for Bash and Zsh, VS Code wraps the PS1 prompt variable to support new functionality. However, when it does this, it prefixes the PREFIX environment variable to the existing PS1 when creating the new PS1 prompt. See the picture below for an example. ! For Bash, the problem is at: For Zsh, see: Steps to reproduce: either Bash or Zsh, enable the integrated terminal a value to a variable named PREFIX in the integrated terminal that the value you assigned to PREFIX is prepended to the prompt The PREFIX environment variable is commonly used across a variety of projects in the Linux world for configuring and building applications (grepping for 'PREFIX during the build process and it makes the terminal hard to use. This issue is the cause of . I can submit a pull request for this if you'd like. VS Code version: Code 1.71.0 (, 2022-09-01T07:36:10.600Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 <!-- generated by issue reporter --
thanks for the investigation and yes would appreciate a PR for this
I can't remember why PREFIX is there, we should blame history before doing the fix
Looks like PREFIX was only used in the initial commit to accomplish what is currently done with _vscpromptstart(), and it was safe to do so as PREFIX was declared as a local variable. Here are the original commits of the relevant files: Zsh: Bash: The second commit to modify these files () modified the updateprompt() function and removed the local PREFIX variable, but did not remove the variable from the PS1 assignment.
For Zsh specifically, in , extra references to PREFIX were to fix a separate issue.
Nice, looks like it's safe to switch to in bash. I'm guessing it's safe in zsh too, do you agree?
<!-- 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


Question: registry.registerWorkbenchAction(new SyncActionDescriptor(SaveAllAction, SaveAllAction.ID, SaveAllAction.LABEL), category, ['save', 'all', 'files']); registry.registerWorkbenchAction(new SyncActionDescriptor(SaveFilesAction, SaveFilesAction.ID, null /* only for programmatic trigger */)); registry.registerWorkbenchAction(new SyncActionDescriptor(RevertFileAction, RevertFileAction.ID, RevertFileAction.LABEL), category, ['revert', 'file']); <ins> registry.registerWorkbenchAction(new SyncActionDescriptor(GlobalNewFileAction, GlobalNewFileAction.ID, GlobalNewFileAction.LABEL), category, ['new', 'file']); </ins> registry.registerWorkbenchAction(new SyncActionDescriptor(GlobalNewFolderAction, GlobalNewFolderAction.ID, GlobalNewFolderAction.LABEL), category, ['new', 'folder']); registry.registerWorkbenchAction(new SyncActionDescriptor(GlobalCompareResourcesAction, GlobalCompareResourcesAction.ID, GlobalCompareResourcesAction.LABEL), category, ['compare', 'files']); registry.registerWorkbenchAction(new SyncActionDescriptor(CloseFileAction, CloseFileAction.ID, CloseFileAction.LABEL, { primary: KeyMod.chord(KeyMod.CtrlCmd | KeyCode.KEY_K, KeyCode.KEY_W) }), category, ['close', 'file']);

VSCode Version: 1.0.0 OS Version: OSX 10.11.3 I noticed that we can set to a keybinding. Which creates a nice input field in the sidebar to create the directory at the current selected position. ! But there is no possibility to do this for a file. Yes you can bind but it does not do the same thing. It just creates a new and when pressing <kbdcmd</kbd+ <kbds</kbdyou have to choose the destination in a picker. So, is it possible to add something for a new file as well? It would really improve my speed because I don't have to touch my mouse anymore to create a new named file in a specific directory.
sounds like a good example for a PR?
Yes I looked into it but to be honest, I have to clue where to start :). So if you can point me in the right direction, I would be very happy to do one :).
I would start by fulltext search for the action id () and that brings you here: From there you can get a feeling how this global action works and maybe add the new one. You will also see the one on top for creating an untitled file (which is not what you want). When you find the references of that action you will see where it is being registered to the system:
Alright, awesome. Thank you very much Will see what I can do :).


Question: } } <del> class TreeMenus extends Disposable implements IDisposable { </del> <ins> class TreeMenus implements IDisposable { </ins> private contextKeyService: IContextKeyService | undefined; private _onDidChange = new Emitter<ITreeItem>(); public readonly onDidChange = this._onDidChange.event;

<!-- 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: V1.81.1 OS Version: Linux kkuser-virtual-machine 5.15.0-83-generic ~20.04.1-Ubuntu SMP Mon Aug 21 14:00:49 UTC 2023 x8664 x8664 x8664 GNU/Linux Steps to Reproduce: are constant changes in attribute states in the treeview calls to () functions result in memory leakage
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.82.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
<!-- 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!


Question: } private _layout(): void { <del> const windowWidth = window.innerWidth; const width = windowWidth * DIMENSION_DEFAULT.WIDTH; this._editorWidget.layout({ width, height: this._editorWidget.getContentHeight() }); const left = Math.round((windowWidth - width) / 2); this._editorContainer.style.left = `${left}px`; </del> <ins> this._editorWidget.layout({ width: DIMENSION_DEFAULT.WIDTH, height: this._editorWidget.getContentHeight() }); </ins> } private async _getTextModel(resource: URI): Promise<ITextModel | null> {

When resizing the windows while the accessible help menu is visible, the help menu slides diagonally: !


Question: } private _layout(): void { <del> const windowWidth = window.innerWidth; const width = windowWidth * DIMENSION_DEFAULT.WIDTH; this._editorWidget.layout({ width, height: this._editorWidget.getContentHeight() }); const left = Math.round((windowWidth - width) / 2); this._editorContainer.style.left = `${left}px`; </del> <ins> this._editorWidget.layout({ width: DIMENSION_DEFAULT.WIDTH, height: this._editorWidget.getContentHeight() }); </ins> } private async _getTextModel(resource: URI): Promise<ITextModel | null> {

Repro: Alt+F1 ! If should be in the center as that's the most obvious location Version: 1.80.0-insider (user setup) Commit: Date: 2023-06-28T08:01:04.380Z Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0.
Putting it here makes the most sense to me because that's where we put other components - like the quick pick. I want to get feedback from low vision users
That's fine, but if you're styling like the command palette we should position it in a similar way ! So below the title bar and not quite and maybe a little less wide
Re , we should also size the height similar to quick pick
But shouldn't the height be determined by the contents?
yes, but have a similar height cap to the quick pick
We should also use the same font as the quick pick
I think you've convinced me - this should be in the center.
Personally I preferred the top position, I'd just render it as the quick pick: Same position and same style. VS Code does not have many vertically centered dialogs. If you want to make it vertically centered, I'd suggest to align it with other vertically centered dialogs, like the trust dialog (notice the background shadow): ! ! Generally, I think, if there is no particular reason to be different, we should try to have a consistent UI throughout the entire product. I'm still in favor of the top position, as the workspace trust dialog is the only vertically centered dialog I know of and it is strongly modal (you have to click one of the buttons to make it disappear). FYI
Fading the background like the trust dialog is good imo, I like centered as it's a very special mode and it's modal as in clicking outside will always dismiss it, unlike the quick pick which may not dismiss when clicking outside. In the end the visual appearance isn't that important really, I just want it to be very obvious when the accessible view is up.
I agree that we should try to align with existing design. My personal preference is to have it positioned like the quick pick.


Question: } private _layout(): void { <del> const windowWidth = window.innerWidth; const width = windowWidth * DIMENSION_DEFAULT.WIDTH; this._editorWidget.layout({ width, height: this._editorWidget.getContentHeight() }); const left = Math.round((windowWidth - width) / 2); this._editorContainer.style.left = `${left}px`; </del> <ins> this._editorWidget.layout({ width: DIMENSION_DEFAULT.WIDTH, height: this._editorWidget.getContentHeight() }); </ins> } private async _getTextModel(resource: URI): Promise<ITextModel | null> {

But in the end, it is not super important as pointed out.
One issue with doing it as the quick pick is it would look wrong being so narrow, and making is narrow would make it less accessible, say if a low vision user was using it.
Not sure it needs to be as narrow as quick pick. I just think the positioning of the quick pick is fitting. So the top and center. It could be wider or longer.
Now that we have the focus border, it is more obvious, so fine to be at the top IMO.
This is still not fixed imo, it should follow quick pick and look like this (native title bar): ! Not this (custom title bar): !
Verified off main :+1:


Question: super.render(container); addClass(container, 'switch-output'); this._register(attachStylerCallback(this.themeService, { selectBorder }, colors => { <del> container.style.border = colors.selectBorder ? `1px solid ${colors.selectBorder}` : ''; </del> <ins> container.style.borderColor = colors.selectBorder ? `${colors.selectBorder}` : ''; </ins> })); }

The select box in the panel header should have a white background: ! This is similar to the recent breakage with the simple editor widget background color in SCM and extensions views.
To Verify: to an obvious color. that terminal and output select boxes are using these when they are in their default locations in panel.


Question: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import { ContentHoverController } from 'vs/editor/contrib/hover/browser/contentHover'; import { Range } from 'vs/editor/common/core/range'; import { Position } from 'vs/editor/common/core/position'; import { IHoverPart } from 'vs/editor/contrib/hover/browser/hoverTypes'; suite('Content Hover', () => { test('issue #151235: Gitlens hover shows up in the wrong place', () => { const actual = ContentHoverController.computeHoverRanges( new Range(5, 5, 5, 5), [<IHoverPart>{ range: new Range(4, 1, 5, 6) }] ); assert.deepStrictEqual( actual, { showAtPosition: new Position(5, 5), showAtRange: new Range(5, 5, 5, 5), highlightRange: new Range(4, 1, 5, 6) } ); }); }); </ins>

! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at


Question: <del> a010e3d6e90e3ae1d7df517044510db0419500c25b0243ac371b2cdc34264fe5 *chromedriver-v30.5.0-darwin-arm64.zip bb5444359e6214a393ab2b9ee6d096e4202fd32050c05bc0868d3f220501efb9 *chromedriver-v30.5.0-darwin-x64.zip bb02fee91d901cd2ff24200c6488691330d946277cb8fbd5681eb7fe04d6b70a *chromedriver-v30.5.0-linux-arm64.zip 3337363abe08a74d30c0a4eb990c35c97bb5692e1c28afd2ab732ac9c51fcf10 *chromedriver-v30.5.0-linux-armv7l.zip bb9c1b5b11712b52e7cbdbf38aa6f180bd4acc9866a3c9a023d443ac93a1bfd3 *chromedriver-v30.5.0-linux-x64.zip c81eec95055c6fc553cddcbe405ce6a4aa9b2e397f65f551ce8a69772dacc80e *chromedriver-v30.5.0-mas-arm64.zip cce049c0bcaeeb82656971363cf2dcce9eae38cbbee558a5204085cac2b700fa *chromedriver-v30.5.0-mas-x64.zip 474cee6b6ab8d8ff4d5beb834981b694aedfa6434e89c77391fb50fd9940421f *chromedriver-v30.5.0-win32-arm64.zip e841d999d224c6562422657a669b1e807f9e1fd99fbfdad9275e86637ee77a2b *chromedriver-v30.5.0-win32-ia32.zip 3e62f30a511ae9058a4e665e56613b7412af1640e15e9b0cbf7237fa0fa5ac1b *chromedriver-v30.5.0-win32-x64.zip 928586b78c1b59cdeab32542c0dcc7763a3eacaa2b21f3fcb6345af522e2600a *electron-api.json 12f0d3689ac7be36b312ef81cffb99ac2ed35eecd6650aefc691085317942bce *electron-v30.5.0-darwin-arm64-dsym-snapshot.zip 84eb4590e500f85ec854fed4e2ea479c118b075a546e3398ac95d093cdd4f49c *electron-v30.5.0-darwin-arm64-dsym.zip bac4837a937f620ae3f6290bb2e2c0d29f051d10b968e3e247751b727ceaf3d3 *electron-v30.5.0-darwin-arm64-symbols.zip 1715379e74d5c5983cf74059eae174cc59bb48ef774d32d6a23fa2e52ae8f8da *electron-v30.5.0-darwin-arm64.zip f1849de448bd973118572dd0e70ea6f8b862e0ed09879323a872f4d4d8c84ff0 *electron-v30.5.0-darwin-x64-dsym-snapshot.zip 1d2677b2b01cda73480d87a02dfbf8ef3b39c0d9c7f785b88edc0bbb9ded0bf4 *electron-v30.5.0-darwin-x64-dsym.zip 34592256b3d940fb6828edcb23cd0f241605dbaa9423d429aa2472143a6c908f *electron-v30.5.0-darwin-x64-symbols.zip 135aaa5c7b9cbd6128a6fb43df522d9bc4894c6ceb115e1db5caa2b2e2f2c9f4 *electron-v30.5.0-darwin-x64.zip 7115b03c3aed17f5d9b1b134f7daf3ffb838f5180f4223358acf3061cf7e8eea *electron-v30.5.0-linux-arm64-debug.zip 75c9532cf91c468dd37c2c961d1e7dbce133f8fe3565cc391f5eea66ae843b4f *electron-v30.5.0-linux-arm64-symbols.zip a3857bdf84379d8a4984955368b3940df9b1b1d098ed6c6120d34cde950e41c6 *electron-v30.5.0-linux-arm64.zip 7115b03c3aed17f5d9b1b134f7daf3ffb838f5180f4223358acf3061cf7e8eea *electron-v30.5.0-linux-armv7l-debug.zip 6de5b4aee19b2da78444cca76d35a3a20d72252dd9e31055ab96c727629007be *electron-v30.5.0-linux-armv7l-symbols.zip ba4cad948732d39242d934dade317785ea8239fed6175fe143f7ad747c8524d9 *electron-v30.5.0-linux-armv7l.zip 2b447d516777af53809ee80820a7c93e704ebaa3b253e7d5b4ecf5f104f2b855 *electron-v30.5.0-linux-x64-debug.zip 9abc7246ab2e29424700ff30c03a72d9f8508d7819ea5d924a606b4ee16e74fd *electron-v30.5.0-linux-x64-symbols.zip 167d48e0c6b9714d3e1bcf66cc37f81a886694038e12c754866db313c1c7c90e *electron-v30.5.0-linux-x64.zip 5aef36099d1fd316c6593bcf9895641fe79e97d3e2191a6c00e63a033e9d628b *electron-v30.5.0-mas-arm64-dsym-snapshot.zip cafae0c4d8b00424a7edf1234587a4a5f49ed209c649a5773131eb805790fdc4 *electron-v30.5.0-mas-arm64-dsym.zip c859b5d4e0fb117e6666db858878efbe77e9cf835125ba69b68099ad3d8975c0 *electron-v30.5.0-mas-arm64-symbols.zip 7458cd6f830640fcfbf262bf207113ff7a4ff62951f3ee2f24075059b141821b *electron-v30.5.0-mas-arm64.zip 894697a4588bcac62565c5416f43e3ea96efe65436c660c0473e382d6ff7075d *electron-v30.5.0-mas-x64-dsym-snapshot.zip 37ef7ac94c20a30be8a53346fb2949429e3adbd5485e9c7cd440b821bd8e3a49 *electron-v30.5.0-mas-x64-dsym.zip b18452e34e0569adc647ebf749712bbe1c7ac60d63624015607f1eb4d3d8f3f6 *electron-v30.5.0-mas-x64-symbols.zip 3fbff016735efd6313be0fcfcbf1856d1e0b25329c9219e7da3fa3585f075f04 *electron-v30.5.0-mas-x64.zip fdf4e69f7601dbe12eb09cca968ff261e3efc8c718f5a74f5805108420abb7b8 *electron-v30.5.0-win32-arm64-pdb.zip e0ce8ed7dc7cb633ed2fcd8f9d2a28dfbd180235b4e2f20747a12eaf397b8808 *electron-v30.5.0-win32-arm64-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.0-win32-arm64-toolchain-profile.zip 61ea193db53d4f5ae95a758b53fbd8675e9b87d5e8c97549ce716eb7830f71a3 *electron-v30.5.0-win32-arm64.zip 3f3133f4db5384a10611f778b3e4d8f759d88d0f93fc1226066bd2324805cef2 *electron-v30.5.0-win32-ia32-pdb.zip 206f84d0a1a4096e793e4152609792fbd6e118d9b3fe96db40b22c6c83f822f8 *electron-v30.5.0-win32-ia32-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.0-win32-ia32-toolchain-profile.zip 8ab671665fad3eb50c0ba79201944dc6a1cc08dd1ec89a5aa458415671307178 *electron-v30.5.0-win32-ia32.zip adc776f542ae6c8f2030a99a0eb4c55857d065708620d52119cc067c264cc08a *electron-v30.5.0-win32-x64-pdb.zip b1fa7b22af5e31f49278ece5cb60d1ce310547db154802c74baa30264b9aaf69 *electron-v30.5.0-win32-x64-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.0-win32-x64-toolchain-profile.zip 2b9007396722c03d6b064e7f277b502990bc2a060066ed202dea4f4ede77a820 *electron-v30.5.0-win32-x64.zip 4acb73a8e98f769c14910e6a16f7902e1281291ecec0c80598ce07bf97878238 *electron.d.ts dded5f95e489ec68829ba2ea2f851601ecc30e534c5fb16c9bee97c196e6eba0 *ffmpeg-v30.5.0-darwin-arm64.zip 3b26980535e45e6fd23b34f464f85263edf434e749722bec70f07a5538dadaf3 *ffmpeg-v30.5.0-darwin-x64.zip 93f433080429f0edffb838a1655c4faacdb49efae24acf97b35c9eccd87abc63 *ffmpeg-v30.5.0-linux-arm64.zip 4f7583513d48b48c44a2cbc4430cbc9a33d8f9728622166db688e3de61190821 *ffmpeg-v30.5.0-linux-armv7l.zip 42aa45bcfebac623904082fbe74a94a9d115237118493baa9845bb4ed63a1ffe *ffmpeg-v30.5.0-linux-x64.zip dded5f95e489ec68829ba2ea2f851601ecc30e534c5fb16c9bee97c196e6eba0 *ffmpeg-v30.5.0-mas-arm64.zip 3b26980535e45e6fd23b34f464f85263edf434e749722bec70f07a5538dadaf3 *ffmpeg-v30.5.0-mas-x64.zip 418ac6118a1d0f4fe245bfd3f7db59293629db0c81ad4dcf27a15197c49b0835 *ffmpeg-v30.5.0-win32-arm64.zip c5980cb28dcef56e7674c754b8863c9b5e67ecdb6684f71e32d10a335b92c5fb *ffmpeg-v30.5.0-win32-ia32.zip 7dffa8b18aa0a7941a2d03d8ac393b865a39dd93ad408e9efdd8e51061798c12 *ffmpeg-v30.5.0-win32-x64.zip 2abc27d8460ca60a336767634ab608b9c5450d0ac9720a6fbbdd9e83f837163d *hunspell_dictionaries.zip 7d3254bf7242ea858cadc17686c2ba1c2b7239e00628c8ae260373e9e35617b2 *libcxx-objects-v30.5.0-linux-arm64.zip 94cc5ba1b3fe4e1db1b4f0ce4140cc3cdf42d54d6e8150d4c1dc98508f7cdad2 *libcxx-objects-v30.5.0-linux-armv7l.zip 21193d743044c1f3052d69efaf11fc1475e5d27f014d0f701127e6da1501bee3 *libcxx-objects-v30.5.0-linux-x64.zip 24ec523a5a5bac709f0df9bb198f52fa786be4b6c828a7cf0117012ffa28f1ce *libcxx_headers.zip </del> <ins> 3de7da4462c7690f75680aecac8fddedc4b998d0da769136d8eff2932b36004e *chromedriver-v30.5.1-darwin-arm64.zip d89b89f7c2ba45cb10df7fc23722bacf6f77e13002c42648762cd18ae3fa9182 *chromedriver-v30.5.1-darwin-x64.zip 3722d46929fd2c7b33c17d37464a08150e60d9269053eb67195795254fb5e947 *chromedriver-v30.5.1-linux-arm64.zip a786d51f834c24b768bd415bf9a2fc5c1d9abdf9dc0b1a091bf9a8ff101becfe *chromedriver-v30.5.1-linux-armv7l.zip 688e4da8dbcb7dbfacab6f29341d96736e6d06e4c8029835b83ef30b69885b01 *chromedriver-v30.5.1-linux-x64.zip 786a7c2659ad97d5a09866b9aafd55edc015cb17a87bd8d72aa5925f2bfcf55a *chromedriver-v30.5.1-mas-arm64.zip 398759d1dc02fc4928d48ff0f8fbade8811347e1a51d1cedcb2ba9350fbed04d *chromedriver-v30.5.1-mas-x64.zip 65766f1270d1876e2a81acfb4b1130dc4a41eb7165842afa8f41ea438bf2fecb *chromedriver-v30.5.1-win32-arm64.zip ca9fe0abd1032ebd51497049cb1bb2ae1dd9592697b278f6b1ee2a1a25148891 *chromedriver-v30.5.1-win32-ia32.zip b6b6ea2202e0139ea436288add736d19078bfb190fc0b22937283927f3024bb9 *chromedriver-v30.5.1-win32-x64.zip 50e8b2d59916bc180873324fdbeb8227dbb8b2375cc936e58b7c9885fb23376d *electron-api.json 595db4fa3f755432bf59cbbaf591ee44b576e15952d014d83d3748646b2e338c *electron-v30.5.1-darwin-arm64-dsym-snapshot.zip c1beb80553f3c9575e638625ce0ffbfdb87b6f8b23799eb132954b2bb74a9a2f *electron-v30.5.1-darwin-arm64-dsym.zip cba315d6d6f607a2ee6cfc437b46f92da88daded86f0130d85129adb4742bc48 *electron-v30.5.1-darwin-arm64-symbols.zip d312544ea29844cf328b44b9dbde12f4fdced90cb442dfca6df36c098dbb6e7a *electron-v30.5.1-darwin-arm64.zip fd24d585d28909c082d703db3fcc5ffa0b55e1077ff320e25ed510f36e6a3761 *electron-v30.5.1-darwin-x64-dsym-snapshot.zip 4d1a2adea4b98c4d0b03c6561fca146aab102d636d359e48ce418c465df891ae *electron-v30.5.1-darwin-x64-dsym.zip d9065eaf659f4c3e8a75f5453ceb65269763b2e57110bdcc01904b9a1e33a62c *electron-v30.5.1-darwin-x64-symbols.zip faf9dcc20d525607ea205f2f6a1dfe3270f6268aa439bb0ba5646c7e4fbbd842 *electron-v30.5.1-darwin-x64.zip b85dba1cdb49591542dcecff3e710f29b81285569c8c5db8c1181c3ed818ba44 *electron-v30.5.1-linux-arm64-debug.zip 5e97cc105282783d1c20d8e8dd4ca1134342839235288840cb50f314ca7a6ede *electron-v30.5.1-linux-arm64-symbols.zip eb31470c0d7cd6e23e7ce0d89cc93a2356c9dac8bcc997e335353b8aa995afa0 *electron-v30.5.1-linux-arm64.zip b85dba1cdb49591542dcecff3e710f29b81285569c8c5db8c1181c3ed818ba44 *electron-v30.5.1-linux-armv7l-debug.zip 137548cd73cd648107f6e01c777e411838173309848a492b42825857cec7d110 *electron-v30.5.1-linux-armv7l-symbols.zip 224bd46983e503101c756c72d10b195f14712a7a56438718acb126017dd04edf *electron-v30.5.1-linux-armv7l.zip 1f87fadebc444c9c0de43f52972a3f61af83ca0594c3de368f7579ce613fcb60 *electron-v30.5.1-linux-x64-debug.zip aae78654f599a68310bdbdc0e3de8db644320ef44e58a5c6e5c693dff5cd1970 *electron-v30.5.1-linux-x64-symbols.zip ec4707783d39e86005f42899e30ae59e50dd5d9c7f28531ed494eb43f2361403 *electron-v30.5.1-linux-x64.zip c61f3121e52fd29987814b7805b597ef3fc78b2ce891eba5e3fc6bbe14128f23 *electron-v30.5.1-mas-arm64-dsym-snapshot.zip f934e55ef6c986d3ec56626b2605fed16030efc45efcd8b05afa9322d625ec56 *electron-v30.5.1-mas-arm64-dsym.zip 3cc36e99f2cd59d7cb2f47b52d19609c2a2358f6ddde35fd832872abe241cc8d *electron-v30.5.1-mas-arm64-symbols.zip c5085ab1fb74dfa4a4e463dcb688989bc63baf44007419fd96db4e7c974fb6db *electron-v30.5.1-mas-arm64.zip 47102b6dcd5892de734be2b48e40bbbdbc5e0a228bf5fec33071661d2724d946 *electron-v30.5.1-mas-x64-dsym-snapshot.zip 607091ddfd313ed27bb5a0acb6fa58b0d65cb87e6c6ce9b373949b4b152476d8 *electron-v30.5.1-mas-x64-dsym.zip ac49568635d41e1075bca39c97aca1f2fcede702f721ddce5d80f18cc2dd1067 *electron-v30.5.1-mas-x64-symbols.zip 3746bc4ba32ab9c11398a393d54ba81733088729ae7cef4e5dccf1e64dc82b0a *electron-v30.5.1-mas-x64.zip 930ad941c8bc0aa5e4e3457b235f104846939974d71bde5b42a8980de2d4a35d *electron-v30.5.1-win32-arm64-pdb.zip 11c1252547b381ab6e40cc032ee60c5209dee9ea1102d1b47ad3fcd4da03049f *electron-v30.5.1-win32-arm64-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.1-win32-arm64-toolchain-profile.zip f18baa98ba9c04b346fda9f40fc3150a57b539d0cd510971a073983f78e0a20c *electron-v30.5.1-win32-arm64.zip b03c7297dc61aa234ab2273c419d9ae064e52c2c0c3dd56f09135f81964630b5 *electron-v30.5.1-win32-ia32-pdb.zip 8fc570c7f4d97eb6b745fb4af5932311d1da57058da8f39a3d97d6e099cd6982 *electron-v30.5.1-win32-ia32-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.1-win32-ia32-toolchain-profile.zip 20845163bf9d5a4ead03c5f0280c9bae71f0ab1fc03362f3406ed12620e4d9cd *electron-v30.5.1-win32-ia32.zip 019f3ae97a69dc837d89c44d25e0e5dadc88564b74202c5a3524fc6ab59490bc *electron-v30.5.1-win32-x64-pdb.zip 2eb4889fe275e5ea42cf6f51821bcceb833d5714aa1b45ad7915495afb447e94 *electron-v30.5.1-win32-x64-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.1-win32-x64-toolchain-profile.zip 443119bb559fc2ca297a57cf79f2bce532e853ada070c1e71460c9657c13b4b3 *electron-v30.5.1-win32-x64.zip deecdc1f3f5ea9548ef73774f412c7af489afeb7dca1c394b5add10e929aff42 *electron.d.ts 14319b51118a5c94e108731f6b5c4e701c700212e790198ba22242eb9674a334 *ffmpeg-v30.5.1-darwin-arm64.zip bfd5110457438fa8b113a8806db45f30b8975304d95e5efb1b71b0f5e46757fe *ffmpeg-v30.5.1-darwin-x64.zip 44ebf3185fc24404647da0c1f9e496effefd32ff3dbc2499c022164b919d06ed *ffmpeg-v30.5.1-linux-arm64.zip 4f7583513d48b48c44a2cbc4430cbc9a33d8f9728622166db688e3de61190821 *ffmpeg-v30.5.1-linux-armv7l.zip 154900e5db5810f63e38fd4551cfff3d88d6eac39226e06e12e1e43558d360a4 *ffmpeg-v30.5.1-linux-x64.zip 14319b51118a5c94e108731f6b5c4e701c700212e790198ba22242eb9674a334 *ffmpeg-v30.5.1-mas-arm64.zip bfd5110457438fa8b113a8806db45f30b8975304d95e5efb1b71b0f5e46757fe *ffmpeg-v30.5.1-mas-x64.zip f2169c4b6b9f073c20652953599f2453947936e851ff25c9f2719e7d889faea3 *ffmpeg-v30.5.1-win32-arm64.zip 90745f1422ae0431b295cb5d27ff03e69c890f3572ef6c4655774b892419e94f *ffmpeg-v30.5.1-win32-ia32.zip 567fe8952f17b224d4492980af741b470e86b31d58e7c6a9262258eeae490122 *ffmpeg-v30.5.1-win32-x64.zip 8bbbadb52a19f074d9f8bd533891e2bacbe4813101ae6c344cfc88e28b1429a3 *hunspell_dictionaries.zip 61137508aee6837c70a2ead2e31dd106d753ec5fac01b49e7e8701be0e09e7aa *libcxx-objects-v30.5.1-linux-arm64.zip 3c285f012f256f767e777550a1f18054cfcffc4e13ad6fa4e4e90dd58ec22069 *libcxx-objects-v30.5.1-linux-armv7l.zip 9b96b53c8dfbc70a0f617f78dde89a1e8510ae2261bcddfbf7c12c61eb5a3d73 *libcxx-objects-v30.5.1-linux-x64.zip 1b5cbe24d6356a388e166bff60d7452583019ea7dec85f593c552eb287346f43 *libcxx_headers.zip </ins> eae200a0d1fd0d4b881358bdef600111891c75ecc4db679b680b0cbaf87ecfc3 *libcxxabi_headers.zip <del> cdd3c02c5998ae39eda53af1627a7f069db29dc13b0287bcfba6197bd9a1f52e *mksnapshot-v30.5.0-darwin-arm64.zip 4212dc901cdaa3e65a905a69c246efe8012318ad9e4141b0e1508f7befadc615 *mksnapshot-v30.5.0-darwin-x64.zip 41ba980d159d59705187fc9a383014cb68a642044c8c39c68f9396bab4fda168 *mksnapshot-v30.5.0-linux-arm64-x64.zip fa2b974e8016ab576c23262c89aa910208542ecec3a2d4344df3f79a0bbb0b30 *mksnapshot-v30.5.0-linux-armv7l-x64.zip cdb205f80890cccc0e3c23bbe8bfa4777171b989f10c532ff488c5a4657a9cf2 *mksnapshot-v30.5.0-linux-x64.zip be468e8c0a3175541e1234d66b50db2932434e77a22d6a6ad3649f36c530aff1 *mksnapshot-v30.5.0-mas-arm64.zip f0bb8d110295ccc0cd0938a63f6a372cf6e80dd511cc1309fd4a7a1bde23dce2 *mksnapshot-v30.5.0-mas-x64.zip 65ed62069016fa0ae0928d394c55678fa530978d1d7fa74a8b02b6b09d7a6e50 *mksnapshot-v30.5.0-win32-arm64-x64.zip 918bf0cc88f4830af21bc7621fde1e32df8869751d898af0ad34e19c63f677a7 *mksnapshot-v30.5.0-win32-ia32.zip 6d6badd9e8ea6df7531e3c1533939686e78c33983cf24e9c98357c2a6d7e6206 *mksnapshot-v30.5.0-win32-x64.zip </del> <ins> ed1f7463b5869acf57dd388208918652182b049b2846f572d52ed47e7c091d54 *mksnapshot-v30.5.1-darwin-arm64.zip bc80de1f29b869cdb2676d2dc08cbb4bd6228a6825b1b0bfc13acee0b070ac3e *mksnapshot-v30.5.1-darwin-x64.zip 5e526ca4f4250a9b9b040d6eb60f1d2b8db974ab68c27e46198f4bf8dc1ef347 *mksnapshot-v30.5.1-linux-arm64-x64.zip c40ca2a45cc9ab4e1668f063860ba243baef8c192a253638e4c93aaccb0ef8da *mksnapshot-v30.5.1-linux-armv7l-x64.zip a3134e0b0980547167dd3ca2f17dd2f40a7db697ab563ba6257534f9ad0d256d *mksnapshot-v30.5.1-linux-x64.zip 82776eafcb3e4d053e275ad50d84151f41a651986baacda20c6ed722854cb8fb *mksnapshot-v30.5.1-mas-arm64.zip 9d6d95d4cb121a29fd68d64557edd8c9859345ac37d0645de8aff518391755ed *mksnapshot-v30.5.1-mas-x64.zip 94b9ce6cb40ae001962b77525d12483c3458776066a69a4e714b327bab1decfc *mksnapshot-v30.5.1-win32-arm64-x64.zip 4d89d06c2e85b25d52bb64f48258ad5d05b98ac21697ae9c49ccd19bad9d7d94 *mksnapshot-v30.5.1-win32-ia32.zip ccfd322bafde0485a0ac6b0acc3669c7b08f30003a1c2e044eebc1bf02289de3 *mksnapshot-v30.5.1-win32-x64.zip </ins>

Testing Version: 1.90.0-insider Commit: Date: 2024-05-29T05:51:07.154Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Linux x64 5.15.0-107-generic open a file in an editor run . This opens a file selection dialog initialized to the home folder
Same problem with open folder dialog
VS Code is awesome, but the open file dialog on Linux has been ridiculously buggy for years. More than two years to fix the problem of the dialog opening in the background. The fix, in the latest version, involves using a dialog inside a portal with no type-ahead support that opens in $HOME or recent files. The open/save file dialog is a crucial control in any application. There should be a way to use the native OS dialog. I'm going to downgrade to the previous version (1.89.1) and keep it as long as it takes.
cc
We hadn't patched the portal code to support most of the file dialogs options, it is being addressed via
This is now addressed in the runtime via , fix will be available once we adopt
Reopening since we have reverted the updated due to other regressions , will be revisited in August.
This issue is not resolved for me, here is for comparison how the file dialog opens in an older version of VS Code vs. now: Good behaviour: ! Bad behaviour: !
Filed
I'm on xfce on xubuntu 22.04. Version 1.89.1-1715060508_amd64 does not have the issue. Later versions do have it. The problem is that instead of forcing the "Open File" path, to that of the current file being edited, vscode delegates the path selection to the operating system, which resolves the "Recent Files" path. Since recent files is truly not useful in vscode, I can at least pilot the path to be that of the home folder with $gsettings set startup-mode 'cwd' from the previous value. Clearly this is very inconvenient. Is there any update about it?
The issue is not resolved for me either.


Question: <del> a010e3d6e90e3ae1d7df517044510db0419500c25b0243ac371b2cdc34264fe5 *chromedriver-v30.5.0-darwin-arm64.zip bb5444359e6214a393ab2b9ee6d096e4202fd32050c05bc0868d3f220501efb9 *chromedriver-v30.5.0-darwin-x64.zip bb02fee91d901cd2ff24200c6488691330d946277cb8fbd5681eb7fe04d6b70a *chromedriver-v30.5.0-linux-arm64.zip 3337363abe08a74d30c0a4eb990c35c97bb5692e1c28afd2ab732ac9c51fcf10 *chromedriver-v30.5.0-linux-armv7l.zip bb9c1b5b11712b52e7cbdbf38aa6f180bd4acc9866a3c9a023d443ac93a1bfd3 *chromedriver-v30.5.0-linux-x64.zip c81eec95055c6fc553cddcbe405ce6a4aa9b2e397f65f551ce8a69772dacc80e *chromedriver-v30.5.0-mas-arm64.zip cce049c0bcaeeb82656971363cf2dcce9eae38cbbee558a5204085cac2b700fa *chromedriver-v30.5.0-mas-x64.zip 474cee6b6ab8d8ff4d5beb834981b694aedfa6434e89c77391fb50fd9940421f *chromedriver-v30.5.0-win32-arm64.zip e841d999d224c6562422657a669b1e807f9e1fd99fbfdad9275e86637ee77a2b *chromedriver-v30.5.0-win32-ia32.zip 3e62f30a511ae9058a4e665e56613b7412af1640e15e9b0cbf7237fa0fa5ac1b *chromedriver-v30.5.0-win32-x64.zip 928586b78c1b59cdeab32542c0dcc7763a3eacaa2b21f3fcb6345af522e2600a *electron-api.json 12f0d3689ac7be36b312ef81cffb99ac2ed35eecd6650aefc691085317942bce *electron-v30.5.0-darwin-arm64-dsym-snapshot.zip 84eb4590e500f85ec854fed4e2ea479c118b075a546e3398ac95d093cdd4f49c *electron-v30.5.0-darwin-arm64-dsym.zip bac4837a937f620ae3f6290bb2e2c0d29f051d10b968e3e247751b727ceaf3d3 *electron-v30.5.0-darwin-arm64-symbols.zip 1715379e74d5c5983cf74059eae174cc59bb48ef774d32d6a23fa2e52ae8f8da *electron-v30.5.0-darwin-arm64.zip f1849de448bd973118572dd0e70ea6f8b862e0ed09879323a872f4d4d8c84ff0 *electron-v30.5.0-darwin-x64-dsym-snapshot.zip 1d2677b2b01cda73480d87a02dfbf8ef3b39c0d9c7f785b88edc0bbb9ded0bf4 *electron-v30.5.0-darwin-x64-dsym.zip 34592256b3d940fb6828edcb23cd0f241605dbaa9423d429aa2472143a6c908f *electron-v30.5.0-darwin-x64-symbols.zip 135aaa5c7b9cbd6128a6fb43df522d9bc4894c6ceb115e1db5caa2b2e2f2c9f4 *electron-v30.5.0-darwin-x64.zip 7115b03c3aed17f5d9b1b134f7daf3ffb838f5180f4223358acf3061cf7e8eea *electron-v30.5.0-linux-arm64-debug.zip 75c9532cf91c468dd37c2c961d1e7dbce133f8fe3565cc391f5eea66ae843b4f *electron-v30.5.0-linux-arm64-symbols.zip a3857bdf84379d8a4984955368b3940df9b1b1d098ed6c6120d34cde950e41c6 *electron-v30.5.0-linux-arm64.zip 7115b03c3aed17f5d9b1b134f7daf3ffb838f5180f4223358acf3061cf7e8eea *electron-v30.5.0-linux-armv7l-debug.zip 6de5b4aee19b2da78444cca76d35a3a20d72252dd9e31055ab96c727629007be *electron-v30.5.0-linux-armv7l-symbols.zip ba4cad948732d39242d934dade317785ea8239fed6175fe143f7ad747c8524d9 *electron-v30.5.0-linux-armv7l.zip 2b447d516777af53809ee80820a7c93e704ebaa3b253e7d5b4ecf5f104f2b855 *electron-v30.5.0-linux-x64-debug.zip 9abc7246ab2e29424700ff30c03a72d9f8508d7819ea5d924a606b4ee16e74fd *electron-v30.5.0-linux-x64-symbols.zip 167d48e0c6b9714d3e1bcf66cc37f81a886694038e12c754866db313c1c7c90e *electron-v30.5.0-linux-x64.zip 5aef36099d1fd316c6593bcf9895641fe79e97d3e2191a6c00e63a033e9d628b *electron-v30.5.0-mas-arm64-dsym-snapshot.zip cafae0c4d8b00424a7edf1234587a4a5f49ed209c649a5773131eb805790fdc4 *electron-v30.5.0-mas-arm64-dsym.zip c859b5d4e0fb117e6666db858878efbe77e9cf835125ba69b68099ad3d8975c0 *electron-v30.5.0-mas-arm64-symbols.zip 7458cd6f830640fcfbf262bf207113ff7a4ff62951f3ee2f24075059b141821b *electron-v30.5.0-mas-arm64.zip 894697a4588bcac62565c5416f43e3ea96efe65436c660c0473e382d6ff7075d *electron-v30.5.0-mas-x64-dsym-snapshot.zip 37ef7ac94c20a30be8a53346fb2949429e3adbd5485e9c7cd440b821bd8e3a49 *electron-v30.5.0-mas-x64-dsym.zip b18452e34e0569adc647ebf749712bbe1c7ac60d63624015607f1eb4d3d8f3f6 *electron-v30.5.0-mas-x64-symbols.zip 3fbff016735efd6313be0fcfcbf1856d1e0b25329c9219e7da3fa3585f075f04 *electron-v30.5.0-mas-x64.zip fdf4e69f7601dbe12eb09cca968ff261e3efc8c718f5a74f5805108420abb7b8 *electron-v30.5.0-win32-arm64-pdb.zip e0ce8ed7dc7cb633ed2fcd8f9d2a28dfbd180235b4e2f20747a12eaf397b8808 *electron-v30.5.0-win32-arm64-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.0-win32-arm64-toolchain-profile.zip 61ea193db53d4f5ae95a758b53fbd8675e9b87d5e8c97549ce716eb7830f71a3 *electron-v30.5.0-win32-arm64.zip 3f3133f4db5384a10611f778b3e4d8f759d88d0f93fc1226066bd2324805cef2 *electron-v30.5.0-win32-ia32-pdb.zip 206f84d0a1a4096e793e4152609792fbd6e118d9b3fe96db40b22c6c83f822f8 *electron-v30.5.0-win32-ia32-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.0-win32-ia32-toolchain-profile.zip 8ab671665fad3eb50c0ba79201944dc6a1cc08dd1ec89a5aa458415671307178 *electron-v30.5.0-win32-ia32.zip adc776f542ae6c8f2030a99a0eb4c55857d065708620d52119cc067c264cc08a *electron-v30.5.0-win32-x64-pdb.zip b1fa7b22af5e31f49278ece5cb60d1ce310547db154802c74baa30264b9aaf69 *electron-v30.5.0-win32-x64-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.0-win32-x64-toolchain-profile.zip 2b9007396722c03d6b064e7f277b502990bc2a060066ed202dea4f4ede77a820 *electron-v30.5.0-win32-x64.zip 4acb73a8e98f769c14910e6a16f7902e1281291ecec0c80598ce07bf97878238 *electron.d.ts dded5f95e489ec68829ba2ea2f851601ecc30e534c5fb16c9bee97c196e6eba0 *ffmpeg-v30.5.0-darwin-arm64.zip 3b26980535e45e6fd23b34f464f85263edf434e749722bec70f07a5538dadaf3 *ffmpeg-v30.5.0-darwin-x64.zip 93f433080429f0edffb838a1655c4faacdb49efae24acf97b35c9eccd87abc63 *ffmpeg-v30.5.0-linux-arm64.zip 4f7583513d48b48c44a2cbc4430cbc9a33d8f9728622166db688e3de61190821 *ffmpeg-v30.5.0-linux-armv7l.zip 42aa45bcfebac623904082fbe74a94a9d115237118493baa9845bb4ed63a1ffe *ffmpeg-v30.5.0-linux-x64.zip dded5f95e489ec68829ba2ea2f851601ecc30e534c5fb16c9bee97c196e6eba0 *ffmpeg-v30.5.0-mas-arm64.zip 3b26980535e45e6fd23b34f464f85263edf434e749722bec70f07a5538dadaf3 *ffmpeg-v30.5.0-mas-x64.zip 418ac6118a1d0f4fe245bfd3f7db59293629db0c81ad4dcf27a15197c49b0835 *ffmpeg-v30.5.0-win32-arm64.zip c5980cb28dcef56e7674c754b8863c9b5e67ecdb6684f71e32d10a335b92c5fb *ffmpeg-v30.5.0-win32-ia32.zip 7dffa8b18aa0a7941a2d03d8ac393b865a39dd93ad408e9efdd8e51061798c12 *ffmpeg-v30.5.0-win32-x64.zip 2abc27d8460ca60a336767634ab608b9c5450d0ac9720a6fbbdd9e83f837163d *hunspell_dictionaries.zip 7d3254bf7242ea858cadc17686c2ba1c2b7239e00628c8ae260373e9e35617b2 *libcxx-objects-v30.5.0-linux-arm64.zip 94cc5ba1b3fe4e1db1b4f0ce4140cc3cdf42d54d6e8150d4c1dc98508f7cdad2 *libcxx-objects-v30.5.0-linux-armv7l.zip 21193d743044c1f3052d69efaf11fc1475e5d27f014d0f701127e6da1501bee3 *libcxx-objects-v30.5.0-linux-x64.zip 24ec523a5a5bac709f0df9bb198f52fa786be4b6c828a7cf0117012ffa28f1ce *libcxx_headers.zip </del> <ins> 3de7da4462c7690f75680aecac8fddedc4b998d0da769136d8eff2932b36004e *chromedriver-v30.5.1-darwin-arm64.zip d89b89f7c2ba45cb10df7fc23722bacf6f77e13002c42648762cd18ae3fa9182 *chromedriver-v30.5.1-darwin-x64.zip 3722d46929fd2c7b33c17d37464a08150e60d9269053eb67195795254fb5e947 *chromedriver-v30.5.1-linux-arm64.zip a786d51f834c24b768bd415bf9a2fc5c1d9abdf9dc0b1a091bf9a8ff101becfe *chromedriver-v30.5.1-linux-armv7l.zip 688e4da8dbcb7dbfacab6f29341d96736e6d06e4c8029835b83ef30b69885b01 *chromedriver-v30.5.1-linux-x64.zip 786a7c2659ad97d5a09866b9aafd55edc015cb17a87bd8d72aa5925f2bfcf55a *chromedriver-v30.5.1-mas-arm64.zip 398759d1dc02fc4928d48ff0f8fbade8811347e1a51d1cedcb2ba9350fbed04d *chromedriver-v30.5.1-mas-x64.zip 65766f1270d1876e2a81acfb4b1130dc4a41eb7165842afa8f41ea438bf2fecb *chromedriver-v30.5.1-win32-arm64.zip ca9fe0abd1032ebd51497049cb1bb2ae1dd9592697b278f6b1ee2a1a25148891 *chromedriver-v30.5.1-win32-ia32.zip b6b6ea2202e0139ea436288add736d19078bfb190fc0b22937283927f3024bb9 *chromedriver-v30.5.1-win32-x64.zip 50e8b2d59916bc180873324fdbeb8227dbb8b2375cc936e58b7c9885fb23376d *electron-api.json 595db4fa3f755432bf59cbbaf591ee44b576e15952d014d83d3748646b2e338c *electron-v30.5.1-darwin-arm64-dsym-snapshot.zip c1beb80553f3c9575e638625ce0ffbfdb87b6f8b23799eb132954b2bb74a9a2f *electron-v30.5.1-darwin-arm64-dsym.zip cba315d6d6f607a2ee6cfc437b46f92da88daded86f0130d85129adb4742bc48 *electron-v30.5.1-darwin-arm64-symbols.zip d312544ea29844cf328b44b9dbde12f4fdced90cb442dfca6df36c098dbb6e7a *electron-v30.5.1-darwin-arm64.zip fd24d585d28909c082d703db3fcc5ffa0b55e1077ff320e25ed510f36e6a3761 *electron-v30.5.1-darwin-x64-dsym-snapshot.zip 4d1a2adea4b98c4d0b03c6561fca146aab102d636d359e48ce418c465df891ae *electron-v30.5.1-darwin-x64-dsym.zip d9065eaf659f4c3e8a75f5453ceb65269763b2e57110bdcc01904b9a1e33a62c *electron-v30.5.1-darwin-x64-symbols.zip faf9dcc20d525607ea205f2f6a1dfe3270f6268aa439bb0ba5646c7e4fbbd842 *electron-v30.5.1-darwin-x64.zip b85dba1cdb49591542dcecff3e710f29b81285569c8c5db8c1181c3ed818ba44 *electron-v30.5.1-linux-arm64-debug.zip 5e97cc105282783d1c20d8e8dd4ca1134342839235288840cb50f314ca7a6ede *electron-v30.5.1-linux-arm64-symbols.zip eb31470c0d7cd6e23e7ce0d89cc93a2356c9dac8bcc997e335353b8aa995afa0 *electron-v30.5.1-linux-arm64.zip b85dba1cdb49591542dcecff3e710f29b81285569c8c5db8c1181c3ed818ba44 *electron-v30.5.1-linux-armv7l-debug.zip 137548cd73cd648107f6e01c777e411838173309848a492b42825857cec7d110 *electron-v30.5.1-linux-armv7l-symbols.zip 224bd46983e503101c756c72d10b195f14712a7a56438718acb126017dd04edf *electron-v30.5.1-linux-armv7l.zip 1f87fadebc444c9c0de43f52972a3f61af83ca0594c3de368f7579ce613fcb60 *electron-v30.5.1-linux-x64-debug.zip aae78654f599a68310bdbdc0e3de8db644320ef44e58a5c6e5c693dff5cd1970 *electron-v30.5.1-linux-x64-symbols.zip ec4707783d39e86005f42899e30ae59e50dd5d9c7f28531ed494eb43f2361403 *electron-v30.5.1-linux-x64.zip c61f3121e52fd29987814b7805b597ef3fc78b2ce891eba5e3fc6bbe14128f23 *electron-v30.5.1-mas-arm64-dsym-snapshot.zip f934e55ef6c986d3ec56626b2605fed16030efc45efcd8b05afa9322d625ec56 *electron-v30.5.1-mas-arm64-dsym.zip 3cc36e99f2cd59d7cb2f47b52d19609c2a2358f6ddde35fd832872abe241cc8d *electron-v30.5.1-mas-arm64-symbols.zip c5085ab1fb74dfa4a4e463dcb688989bc63baf44007419fd96db4e7c974fb6db *electron-v30.5.1-mas-arm64.zip 47102b6dcd5892de734be2b48e40bbbdbc5e0a228bf5fec33071661d2724d946 *electron-v30.5.1-mas-x64-dsym-snapshot.zip 607091ddfd313ed27bb5a0acb6fa58b0d65cb87e6c6ce9b373949b4b152476d8 *electron-v30.5.1-mas-x64-dsym.zip ac49568635d41e1075bca39c97aca1f2fcede702f721ddce5d80f18cc2dd1067 *electron-v30.5.1-mas-x64-symbols.zip 3746bc4ba32ab9c11398a393d54ba81733088729ae7cef4e5dccf1e64dc82b0a *electron-v30.5.1-mas-x64.zip 930ad941c8bc0aa5e4e3457b235f104846939974d71bde5b42a8980de2d4a35d *electron-v30.5.1-win32-arm64-pdb.zip 11c1252547b381ab6e40cc032ee60c5209dee9ea1102d1b47ad3fcd4da03049f *electron-v30.5.1-win32-arm64-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.1-win32-arm64-toolchain-profile.zip f18baa98ba9c04b346fda9f40fc3150a57b539d0cd510971a073983f78e0a20c *electron-v30.5.1-win32-arm64.zip b03c7297dc61aa234ab2273c419d9ae064e52c2c0c3dd56f09135f81964630b5 *electron-v30.5.1-win32-ia32-pdb.zip 8fc570c7f4d97eb6b745fb4af5932311d1da57058da8f39a3d97d6e099cd6982 *electron-v30.5.1-win32-ia32-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.1-win32-ia32-toolchain-profile.zip 20845163bf9d5a4ead03c5f0280c9bae71f0ab1fc03362f3406ed12620e4d9cd *electron-v30.5.1-win32-ia32.zip 019f3ae97a69dc837d89c44d25e0e5dadc88564b74202c5a3524fc6ab59490bc *electron-v30.5.1-win32-x64-pdb.zip 2eb4889fe275e5ea42cf6f51821bcceb833d5714aa1b45ad7915495afb447e94 *electron-v30.5.1-win32-x64-symbols.zip 7351fa5cb892853a7d4b67d8858d0f9cc6506c554a2e42c9ad7e8d5e29ae2743 *electron-v30.5.1-win32-x64-toolchain-profile.zip 443119bb559fc2ca297a57cf79f2bce532e853ada070c1e71460c9657c13b4b3 *electron-v30.5.1-win32-x64.zip deecdc1f3f5ea9548ef73774f412c7af489afeb7dca1c394b5add10e929aff42 *electron.d.ts 14319b51118a5c94e108731f6b5c4e701c700212e790198ba22242eb9674a334 *ffmpeg-v30.5.1-darwin-arm64.zip bfd5110457438fa8b113a8806db45f30b8975304d95e5efb1b71b0f5e46757fe *ffmpeg-v30.5.1-darwin-x64.zip 44ebf3185fc24404647da0c1f9e496effefd32ff3dbc2499c022164b919d06ed *ffmpeg-v30.5.1-linux-arm64.zip 4f7583513d48b48c44a2cbc4430cbc9a33d8f9728622166db688e3de61190821 *ffmpeg-v30.5.1-linux-armv7l.zip 154900e5db5810f63e38fd4551cfff3d88d6eac39226e06e12e1e43558d360a4 *ffmpeg-v30.5.1-linux-x64.zip 14319b51118a5c94e108731f6b5c4e701c700212e790198ba22242eb9674a334 *ffmpeg-v30.5.1-mas-arm64.zip bfd5110457438fa8b113a8806db45f30b8975304d95e5efb1b71b0f5e46757fe *ffmpeg-v30.5.1-mas-x64.zip f2169c4b6b9f073c20652953599f2453947936e851ff25c9f2719e7d889faea3 *ffmpeg-v30.5.1-win32-arm64.zip 90745f1422ae0431b295cb5d27ff03e69c890f3572ef6c4655774b892419e94f *ffmpeg-v30.5.1-win32-ia32.zip 567fe8952f17b224d4492980af741b470e86b31d58e7c6a9262258eeae490122 *ffmpeg-v30.5.1-win32-x64.zip 8bbbadb52a19f074d9f8bd533891e2bacbe4813101ae6c344cfc88e28b1429a3 *hunspell_dictionaries.zip 61137508aee6837c70a2ead2e31dd106d753ec5fac01b49e7e8701be0e09e7aa *libcxx-objects-v30.5.1-linux-arm64.zip 3c285f012f256f767e777550a1f18054cfcffc4e13ad6fa4e4e90dd58ec22069 *libcxx-objects-v30.5.1-linux-armv7l.zip 9b96b53c8dfbc70a0f617f78dde89a1e8510ae2261bcddfbf7c12c61eb5a3d73 *libcxx-objects-v30.5.1-linux-x64.zip 1b5cbe24d6356a388e166bff60d7452583019ea7dec85f593c552eb287346f43 *libcxx_headers.zip </ins> eae200a0d1fd0d4b881358bdef600111891c75ecc4db679b680b0cbaf87ecfc3 *libcxxabi_headers.zip <del> cdd3c02c5998ae39eda53af1627a7f069db29dc13b0287bcfba6197bd9a1f52e *mksnapshot-v30.5.0-darwin-arm64.zip 4212dc901cdaa3e65a905a69c246efe8012318ad9e4141b0e1508f7befadc615 *mksnapshot-v30.5.0-darwin-x64.zip 41ba980d159d59705187fc9a383014cb68a642044c8c39c68f9396bab4fda168 *mksnapshot-v30.5.0-linux-arm64-x64.zip fa2b974e8016ab576c23262c89aa910208542ecec3a2d4344df3f79a0bbb0b30 *mksnapshot-v30.5.0-linux-armv7l-x64.zip cdb205f80890cccc0e3c23bbe8bfa4777171b989f10c532ff488c5a4657a9cf2 *mksnapshot-v30.5.0-linux-x64.zip be468e8c0a3175541e1234d66b50db2932434e77a22d6a6ad3649f36c530aff1 *mksnapshot-v30.5.0-mas-arm64.zip f0bb8d110295ccc0cd0938a63f6a372cf6e80dd511cc1309fd4a7a1bde23dce2 *mksnapshot-v30.5.0-mas-x64.zip 65ed62069016fa0ae0928d394c55678fa530978d1d7fa74a8b02b6b09d7a6e50 *mksnapshot-v30.5.0-win32-arm64-x64.zip 918bf0cc88f4830af21bc7621fde1e32df8869751d898af0ad34e19c63f677a7 *mksnapshot-v30.5.0-win32-ia32.zip 6d6badd9e8ea6df7531e3c1533939686e78c33983cf24e9c98357c2a6d7e6206 *mksnapshot-v30.5.0-win32-x64.zip </del> <ins> ed1f7463b5869acf57dd388208918652182b049b2846f572d52ed47e7c091d54 *mksnapshot-v30.5.1-darwin-arm64.zip bc80de1f29b869cdb2676d2dc08cbb4bd6228a6825b1b0bfc13acee0b070ac3e *mksnapshot-v30.5.1-darwin-x64.zip 5e526ca4f4250a9b9b040d6eb60f1d2b8db974ab68c27e46198f4bf8dc1ef347 *mksnapshot-v30.5.1-linux-arm64-x64.zip c40ca2a45cc9ab4e1668f063860ba243baef8c192a253638e4c93aaccb0ef8da *mksnapshot-v30.5.1-linux-armv7l-x64.zip a3134e0b0980547167dd3ca2f17dd2f40a7db697ab563ba6257534f9ad0d256d *mksnapshot-v30.5.1-linux-x64.zip 82776eafcb3e4d053e275ad50d84151f41a651986baacda20c6ed722854cb8fb *mksnapshot-v30.5.1-mas-arm64.zip 9d6d95d4cb121a29fd68d64557edd8c9859345ac37d0645de8aff518391755ed *mksnapshot-v30.5.1-mas-x64.zip 94b9ce6cb40ae001962b77525d12483c3458776066a69a4e714b327bab1decfc *mksnapshot-v30.5.1-win32-arm64-x64.zip 4d89d06c2e85b25d52bb64f48258ad5d05b98ac21697ae9c49ccd19bad9d7d94 *mksnapshot-v30.5.1-win32-ia32.zip ccfd322bafde0485a0ac6b0acc3669c7b08f30003a1c2e044eebc1bf02289de3 *mksnapshot-v30.5.1-win32-x64.zip </ins>

The file-open and directory-open dialogs still do not appear even though built on Electron 30.1.2. This is reproducible 100% of the time in openSUSE Tumbleweed and in Leap.
The file-open/directory-open or save dialog not being shown remains unresolved on Linux in release 1.93.1 built with electron 30.4.0.


Question: j:number, lastIncludedCharIndex:number, len:number, <del> characterClasses = getCharacterClasses(), characterClassesLength = characterClasses.length, </del> linkBeginIndex:number, state:number, ch:string,

VSCode Version: 1.0 OS Version: OS X 10.11.4 I just upgraded my VSCode to 1.0 release. Since it supports Traditional Chinese now, my default language was set to so that some of comments in the newly config file is in Chinese. As you can see in the following screenshot, a Chinese character "", which is equivalent to the period "." in English, was matched as part of valid URL, and it caused VSCode direct to a incorrect URL. ! I have a working fix for this issue, the naive solution is to check if in is greater than 128, which means a non-ASCII character. Why to match only ASCII character? Because when you copy a URL from most of web browsers to clipboard, it will be automatically converted into ASCII-only string. Also, I came up with another idea to modify the to let it cache all the result of ASCII characters (0~127). In this way, we only need to modify the default case of the switch clause in the state machine. Which solution is more preferable? Please give me some advice then I can submit the patch ASAP.


Question: })); this.nextBtn = this._register(new SimpleButton({ <del> label: NLS_NEXT_MATCH_BTN_LABEL, </del> <ins> label: NLS_NEXT_MATCH_BTN_LABEL + (options.nextMatchActionId ? this._getKeybinding(options.nextMatchActionId) : ''), </ins> icon: findNextMatchIcon, onTrigger: () => { this.find(false);

Terminal: <img width="328" alt="image" src=""Editor: <img width="436" alt="image" src=""


Question: content.push(`.monaco-list${suffix}:not(.drop-target):not(.dragging) .monaco-list-row:hover:not(.selected):not(.focused) { color:  ${styles.listHoverForeground}; }`); } <del> if (styles.listSelectionOutline) { content.push(`.monaco-list${suffix} .monaco-list-row.selected { outline: 1px dotted ${styles.listSelectionOutline}; outline-offset: -1px; }`); </del> <ins> /** * Outlines */ const focusAndSelectionOutline = asCssValueWithDefault(styles.listFocusAndSelectionOutline, asCssValueWithDefault(styles.listSelectionOutline, styles.listFocusOutline ?? '')); if (focusAndSelectionOutline) { // default: listFocusOutline content.push(`.monaco-list${suffix}:focus .monaco-list-row.focused.selected { outline: 1px solid ${focusAndSelectionOutline}; outline-offset: -1px;}`); </ins> } <del> if (styles.listFocusOutline) { </del> <ins> if (styles.listFocusOutline) { // default: set </ins> content.push(` .monaco-drag-image, .monaco-list${suffix}:focus .monaco-list-row.focused { outline: 1px solid ${styles.listFocusOutline}; outline-offset: -1px; }

This seems really aggressive and probably not intentional <img width="406" alt="image" src="https://user-"
I think this rule references a css variable that isn't defined <img width="501" alt="image" src="https://user-" it looks like you were in this area recently, it looks like there is a default that we don't fall back to, do you know what's going on?


Question: // Don't dispose editor when instance is torn down on shutdown to avoid extra work and so // the editor/tabs don't disappear <del> this._lifecycleService.onWillShutdown(() => { </del> <ins> this._lifecycleService.onWillShutdown((e: WillShutdownEvent) => { </ins> this._isShuttingDown = true; dispose(disposeListeners); <ins> // Don't touch processes if the shutdown was a result of reload as they will be reattached const shouldPersistTerminals = this._configurationService.getValue<boolean>(TerminalSettingId.EnablePersistentSessions) && e.reason === ShutdownReason.RELOAD; if (shouldPersistTerminals) { instance.detachProcessAndDispose(TerminalExitReason.Shutdown); } else { instance.dispose(TerminalExitReason.Shutdown); } </ins> }); }

Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.


Question: // Don't dispose editor when instance is torn down on shutdown to avoid extra work and so // the editor/tabs don't disappear <del> this._lifecycleService.onWillShutdown(() => { </del> <ins> this._lifecycleService.onWillShutdown((e: WillShutdownEvent) => { </ins> this._isShuttingDown = true; dispose(disposeListeners); <ins> // Don't touch processes if the shutdown was a result of reload as they will be reattached const shouldPersistTerminals = this._configurationService.getValue<boolean>(TerminalSettingId.EnablePersistentSessions) && e.reason === ShutdownReason.RELOAD; if (shouldPersistTerminals) { instance.detachProcessAndDispose(TerminalExitReason.Shutdown); } else { instance.dispose(TerminalExitReason.Shutdown); } </ins> }); }

/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders


Question: return c; } clientSnippetSupport = getClientCapability('textDocument.completion.completionItem.snippetSupport', false); dynamicFormatterRegistration = getClientCapability('textDocument.rangeFormatting.dynamicRegistration', false) && (typeof initializationOptions.provideFormatter !== 'boolean'); foldingRangeLimitDefault = getClientCapability('textDocument.foldingRange.rangeLimit', Number.MAX_VALUE); hierarchicalDocumentSymbolSupport = getClientCapability('textDocument.documentSymbol.hierarchicalDocumentSymbolSupport', false); formatterMaxNumberOfEdits = initializationOptions.customCapabilities?.rangeFormatting?.editLimit || Number.MAX_VALUE; <del> const pullDiagnosticSupport = getClientCapability('textDocument.diagnostic', undefined); if (pullDiagnosticSupport === undefined) { </del> <ins> const supportsDiagnosticPull = getClientCapability('textDocument.diagnostic', undefined); if (supportsDiagnosticPull === undefined) { </ins> diagnosticsSupport = registerDiagnosticsPushSupport(documents, connection, runtime, validateTextDocument); } else { diagnosticsSupport = registerDiagnosticsPullSupport(documents, connection, runtime, validateTextDocument); } const capabilities: ServerCapabilities = { textDocumentSync: TextDocumentSyncKind.Incremental, completionProvider: clientSnippetSupport ? {

LSP now support pull diagnostics. Adopt for [x] CSS [x] JSON [x] HTML


Question: import { ICodeEditor } from 'vs/editor/browser/editorBrowser'; import { NullLogService } from 'vs/platform/log/common/log'; import { Handler } from 'vs/editor/common/editorCommon'; <del> import { timeout } from 'vs/base/common/async'; </del> suite('SnippetController2', function () {

<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.33.1 OS Version: Windows_NT x64 10.0. Steps to Reproduce: a new user snippet file for the project. The one I encounter the issue with is: the snippet and attempt to press TAB after writing the first variable cursor does not move to the next stop, instead a tab character is The desired behavior would be for the cursor to move to the next tab stop. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Seems to work just fine for me... Any special keybinding or setting? !
The action you took is not the problem I encounter and does indeed work the same way for me. Could you try to edit "SystemName", the first tab stop, then press TAB to go to "Required Components"? vsCode just inserts a tab character after whatever I wrote instead of going to the next tab stop.
Ok, thanks for clarifying. For some reason snippet mode stops when making that edit... Not sure why
I have encountered similar issue, however, I could add a single blank space in the snippet which "fixed" the tab navigation. Also, my example is far simpler. See
This is a regression from I will revert that change and re-open the corresponding issue (which is much more rare than these issues)
Thank you for fixing this, looking forward to the next release.


Question: import { ITerminalInstance, IXtermTerminal } from 'vs/workbench/contrib/terminal/browser/terminal'; import { TerminalCommandId } from 'vs/workbench/contrib/terminal/common/terminal'; import type { Terminal } from '@xterm/xterm'; <ins> import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; </ins> export const enum ClassName { Active = 'active',

Type: <bFeature Request</bCC Please consider auto-activiating accessible view in terminal when user hit enter key. In most cases, screen reader users want to open accessible view after executing command in terminal. Thus, pressing Enter key can do: the current command to terminal. Accessible View immediately. Rather than having this as the default mode, we could consider adding this as a custom user setting. VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-02T09:02:24.464Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
This makes sense. let us know if you have any thoughts.
I imagine this mode can boost user productivity because VSCode now sends user typing in Accessible View directly to the active terminal. If this mode is , users will experience more seamless round trip between terminal input and accessible view without having to press Alt+F2 and ESC.
To verify, enable . Run a command in the terminal. The accessible view should open.


Question: res = path.substr(0, pos); } res += encodeTable[code]; <del> } else { if (res !== undefined) { res += path[pos]; } </del> <ins> } else if (res !== undefined) { res += path[pos]; </ins> } } return res !== undefined ? res : path;

Issue Type: <bBug</bdeveloper tools themes Everything appears to work as normal, but the console gets flooded with errors. VS Code version: Code - Insiders 1.36.0-insider (, 2019-06-14T10:36:51.530Z) OS version: Darwin x64 18.6.0 <details<summarySystem Info</summary </details<details<summaryExtensions (13)</summaryExtensionVersion ------ vscode-eslint1.9.0 gitlens9.8.2 vsc-material-theme2.9.0 remote-containers0.61.0 remote-ssh-edit-nightly2019.6. remote-ssh-explorer-nightly2019.6. remote-ssh-nightly2019.6. vscode-typescript-tslint-plugin1.1.0 debugger-for-chrome4.11.3 vscode-docker0.6.2 material-icon-theme3.8.0 polacode0.3.2 vscode-sort-json1.13.0 </details<!-- generated by issue reporter --
I can't repo this. Which developer tools and theme are you talking about specifically?
I tried repoing this again and it appears that this error is related to installing a new theme. Here are some better repo steps: developer tools themes (no errors) a theme themes (errors even if it is one of the themes shipped with VS code) The errors go away after a reload, but installing a theme does not tell me a reload is required.
Ok, with the extensions view open, I sometimes see Does not cause seem to cause any actual problems
I get that as well sometimes, but do you not get the webview must be attached to the DOM error as well?
I can reproduce it. Steps: on any extension to load it's Readme in an editor that editor theme (this triggers the webview error) step 1 (this triggers the guestInstanceId error)


Question: default: 'openOnFirstSessionStart', description: nls.localize('openDebug', "Controls whether debug view should be open on debugging session start.") }, <ins> 'debug.enableAllHovers': { type: 'boolean', description: nls.localize({ comment: ['This is the description for a setting'], key: 'enableAllHovers' }, "Controls if the non debug hovers should be enabled while debugging. If true the hover providers will be called to provide a hover. Regular hovers will not be shown even if this setting is true."), default: false }, </ins> 'launch': { type: 'object', description: nls.localize({ comment: ['This is the description for a setting'], key: 'launch' }, "Global debug launch configuration. Should be used as an alternative to 'launch.json' that is shared across workspaces"),

To be verified with: : : set the new config options start debugging The hover provider should be invoked.


Question: class TestTerminalContributionService implements ITerminalContributionService { _serviceBrand: undefined; terminalProfiles: readonly IExtensionTerminalProfile[] = []; <del> quickFixes: ITerminalCommandSelector[] = []; </del> <ins> quickFixes: Promise<ITerminalCommandSelector[]> = new Promise((r) => { r([]); }); </ins> setProfiles(profiles: IExtensionTerminalProfile[]): void { this.terminalProfiles = profiles; }

Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-


Question: this._isChangingDecorations = false; this._shouldFocus = false; this._colorPicker = null; <ins> this._preferBelow = this._editor.getOption(EditorOption.hover).below; </ins> this._hoverOperation = new HoverOperation( this._computer,

Issue Type: <bFeature Request</bI want the message could display under the variables it refers to. Because the message box blocks the code over the current line. Thank you. VS Code version: Code 1.36.1 (, 2019-07-08T22:59:35.033Z) OS version: Windows_NT x64 10.0.


Question: MoveToEditorInstance = 'workbench.action.terminal.moveToEditorInstance', MoveToTerminalPanel = 'workbench.action.terminal.moveToTerminalPanel', SetDimensions = 'workbench.action.terminal.setDimensions', <del> ClearCommandHistory = 'workbench.action.terminal.clearCommandHistory', </del> <ins> ClearPreviousSessionHistory = 'workbench.action.terminal.clearPreviousSessionHistory', </ins> WriteDataToTerminal = 'workbench.action.terminal.writeDataToTerminal', ShowTextureAtlas = 'workbench.action.terminal.showTextureAtlas', ShowTerminalAccessibilityHelp = 'workbench.action.terminal.showAccessibilityHelp',

Testing Linux some commands in your terminal 1 Terminal Clear Command History 1 Terminal run recent commands the commands are still there, nothing got cleared !
This is by design as clearing history only clears the previous session commands. We don't discard the current session as they're all in the active terminal marked by decorations. It does however clear the active terminal's current session history from the previous session history (which hides by default as they would duplicate the content).
I find this very counterintuitive... As no other clear command in VS Code behaves that way.
I cleared recently opened and the active windows still show up, this is essentially the same thing the terminal history is doing: !
On macOS, i run , and when i run again, i can see all the commands, including those from the previous session. <img width="802" alt="Screen Shot 2022-02-24 at 11 07 24 AM" src="https://user-"
I agree that it's a little confusing. Perhaps we should say instead?
I now get the clear command history and a clear previous session command history command. Neither command seems to be clearing the command history. I'm on Windows with pwsh. !
the change you made was to the quickaccess code, this is nothing to do with the terminal so we need to revert that
can you help with verification steps for this one. Since I do not see the "Clear Command History" in quick pick. Does this only appear on Linux?
the title of the command is
thanks. After running that commend I still see the recent commands. So the command history is not cleared. Is this expected?
I still see previous session history commands given to the terminal after running the command.
is the group called or is it or something similar? Only the first is expected to be cleared. This worked fine for me just now.


Question: background-color: var(--vscode-inlineChat-regionHighlight); } <del> .monaco-workbench .inline-chat-slash-command { </del> <ins> .monaco-workbench .interactive-session .interactive-input-and-execute-toolbar .monaco-editor .inline-chat-slash-command { </ins> background-color: var(--vscode-chat-slashCommandBackground); <del> color: var(--vscode-chat-slashCommandForeground); </del> <ins> color: var(--vscode-chat-slashCommandForeground); /* Overrides the foreground color rule in chat.css */ </ins> border-radius: 4px; padding: 1px; }

Testing ! !
doesn't reproduce in the panel chat
I somehow suffer from this change which explicitly targets some monaco tokens...
This isn't nice but there's actually no other way to override the foreground color of an editor- because typically you have syntax highlighting. We do this for all the other "input box"-style editors. I think I opened a feature request when I did this. We should align this rule with your rule for coloring the decoration so that it can override it properly.
labeling so it gets verified
Thanks
in the latest insider's, still seeing this ! !
There is two separate issues with different steps. There is a difference between rendering of slash command and normal prompt text. the only useful/visible information in the original issue description is slash commands (please use words and not images to describe issues!). For verification you have not used slash commands but normal prompt text which is a different case. Please file a separate issue, use words/steps and don't rely on screen captures with just white on white text
Steps to reproduce/verify use HC light and dark theme open inline chat and type a slash command, e.d make sure the command is readable when selecting its text


Question: break; } } <del> characterBounds.push(new DOMRect(parentBounds.left + contentLeft + left, top, width, lineHeight)); </del> <ins> characterBounds.push(new DOMRect(parentBounds.left + contentLeft + left - editorScrollLeft, top, width, lineHeight)); </ins> } this._editContext.updateCharacterBounds(e.rangeStart, characterBounds); }

Version: 1.94.0-insider Commit: Date: 2024-09-23T05:12:01.964Z Electron: 30.5.0 ElectronBuildId: Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 Steps to Reproduce: a very long line. Google IME for Japanese. at the last of the long line. position of the IME widget is not optimal. ! With , it is worse. !
Hi yes thanks a lot for opening this valuable issue. This is happening because we use the model ranges instead of the view ranges in the control bounds, selection bounds and character bounds positioning. The following PR fixes this:
I try the OSS version from the repository. The issue with is fixed. However, I still see the issue with Version: 1.94.0 Commit: Date: Unknown Electron: 30.5.1 ElectronBuildId: undefined Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 a very long line. Google IME for Japanese. at the last of the long line. position of the IME widget is not optimal. !
Oh I see thanks for letting me know that is curious. I will reopen the issue and have a look.
After investigating the issue, I believe this happens because I didn't remove the editor scroll left position from the bounds set for the selection and character bounds. The following PR should fix this.


Question: readonly shortStats?: boolean; readonly author?: string; readonly refNames?: string[]; <ins> readonly maxParents?: number; </ins> } export interface CommitOptions {

a folder/workspace in VS Code Insiders a git repository in the folder a file, make changes to it, and create multiple commits Expected: commits should appear in the history graph Actual: no commits are being shown in the history graph
this only works when there are multiple commits. I.e. if we has just one commit in the repo, then history isn't displayed. Else works as expected.
Thanks! I have filed to handle the single commit scenario