Question: Type: <bBug</bIn editor, I can't use and alt+[` do not have specific "when" clause and conflict against inline suggestion view in keybindings. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-28T12:08:04.472Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.13 copilot1.99.297 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.3 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.12.0 vscode-pylance2023.7.40 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.2417 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --

import { KeyCode, KeyMod } from 'vs/base/common/keyCodes'; import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { MenuId } from 'vs/platform/actions/common/actions'; <ins> import { RawContextKey } from 'vs/platform/contextkey/common/contextkey'; export const accessibilityHelpIsShown = new RawContextKey<boolean>('accessibilityHelpIsShown', false, true); export const accessibleViewIsShown = new RawContextKey<boolean>('accessibleViewIsShown', false, true); </ins> export const enum AccessibilityVerbositySettingId { Terminal = 'accessibility.verbosity.terminal',


Question: Type: <bBug</bIn editor, I can't use and alt+[` do not have specific "when" clause and conflict against inline suggestion view in keybindings. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-28T12:08:04.472Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.13 copilot1.99.297 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.3 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.12.0 vscode-pylance2023.7.40 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.2417 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --

export const AccessibleViewNextAction = registerCommand(new MultiCommand({ id: 'editor.action.accessibleViewNext', <del> precondition: undefined, </del> <ins> precondition: accessibleViewIsShown, </ins> kbOpts: { primary: KeyMod.Alt | KeyCode.BracketRight, weight: KeybindingWeight.WorkbenchContrib


Question: Type: <bBug</bIn editor, I can't use and alt+[` do not have specific "when" clause and conflict against inline suggestion view in keybindings. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-28T12:08:04.472Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.13 copilot1.99.297 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.3 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.12.0 vscode-pylance2023.7.40 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.2417 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --

export const AccessibleViewPreviousAction = registerCommand(new MultiCommand({ id: 'editor.action.accessibleViewPrevious', <del> precondition: undefined, </del> <ins> precondition: accessibleViewIsShown, </ins> kbOpts: { primary: KeyMod.Alt | KeyCode.BracketLeft, weight: KeybindingWeight.WorkbenchContrib


Question: Type: <bBug</bIn editor, I can't use and alt+[` do not have specific "when" clause and conflict against inline suggestion view in keybindings. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-28T12:08:04.472Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.13 copilot1.99.297 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.3 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.12.0 vscode-pylance2023.7.40 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.2417 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --

import { localize } from 'vs/nls'; import { IAccessibilityService } from 'vs/platform/accessibility/common/accessibility'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; <del> import { IContextKey, IContextKeyService, RawContextKey } from 'vs/platform/contextkey/common/contextkey'; </del> <ins> import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; </ins> import { IContextViewDelegate, IContextViewService } from 'vs/platform/contextview/browser/contextView'; import { IInstantiationService, createDecorator } from 'vs/platform/instantiation/common/instantiation'; import { IOpenerService } from 'vs/platform/opener/common/opener';


Question: Type: <bBug</bIn editor, I can't use and alt+[` do not have specific "when" clause and conflict against inline suggestion view in keybindings. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-28T12:08:04.472Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.13 copilot1.99.297 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.3 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.12.0 vscode-pylance2023.7.40 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.2417 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --

import { getSimpleEditorOptions } from 'vs/workbench/contrib/codeEditor/browser/simpleEditorOptions'; import { CodeActionController } from 'vs/editor/contrib/codeAction/browser/codeActionController'; import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; <del> import { AccessibilityVerbositySettingId, AccessibleViewAction, AccessibleViewNextAction, AccessibleViewPreviousAction } from 'vs/workbench/contrib/accessibility/browser/accessibilityContribution'; </del> <ins> import { AccessibilityVerbositySettingId, AccessibleViewAction, AccessibleViewNextAction, AccessibleViewPreviousAction, accessibilityHelpIsShown, accessibleViewIsShown } from 'vs/workbench/contrib/accessibility/browser/accessibilityContribution'; </ins> import { ILayoutService } from 'vs/platform/layout/browser/layoutService'; const enum DIMENSIONS {


Question: Type: <bBug</bIn editor, I can't use and alt+[` do not have specific "when" clause and conflict against inline suggestion view in keybindings. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-28T12:08:04.472Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.13 copilot1.99.297 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.3 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.12.0 vscode-pylance2023.7.40 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.2417 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --

type: AccessibleViewType; } <del> export const accessibilityHelpIsShown = new RawContextKey<boolean>('accessibilityHelpIsShown', false, true); export const accessibleViewIsShown = new RawContextKey<boolean>('accessibleViewIsShown', false, true); </del> class AccessibleView extends Disposable { private _editorWidget: CodeEditorWidget; private _accessiblityHelpIsShown: IContextKey<boolean>;


Question: Type: <bBug</bIn editor, I can't use and alt+[` do not have specific "when" clause and conflict against inline suggestion view in keybindings. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-28T12:08:04.472Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.13 copilot1.99.297 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.3 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.12.0 vscode-pylance2023.7.40 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.2417 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --

import { ServicesAccessor } from 'vs/platform/instantiation/common/instantiation'; import { IAccessibilityService } from 'vs/platform/accessibility/common/accessibility'; import { Action2, registerAction2 } from 'vs/platform/actions/common/actions'; <del> import { accessibilityHelpIsShown } from 'vs/workbench/contrib/accessibility/browser/accessibleView'; </del> <ins> import { accessibilityHelpIsShown } from 'vs/workbench/contrib/accessibility/browser/accessibilityContribution'; </ins> import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { KeyCode, KeyMod } from 'vs/base/common/keyCodes'; import { alert } from 'vs/base/browser/ui/aria/aria';


Question:
When exporting a profile, a SR user has to navigate the whole list to reach the button. We should either move the button to the top or have a keybinding/command which does this. cc <img width="293" alt="Screenshot 2023-07-31 at 11 30 34 AM" src=""
Is not the tab should take to Export button when the complete tree is focused instead of focusing the check box?
I'm not following
Try to get into the state where Tree is focused not any of the elements of the Tree. For eg: <img width="662" alt="image" src=""See the outline focusing the tree. Press <tabnow. This should focus the Export button right?
correct - pressing tab when my screen looks like the above causes focus to be lost rather than going to the button.
Tab at this state is taking focus to the checkbox in the tree. IMO checkbox should be focused when the row is focused and you tab then. Is it possible to change this behaviour?

this.setHover(node.checkbox); this.setAccessibilityInformation(node.checkbox); this.toggle.domNode.classList.add(TreeItemCheckbox.checkboxClass); <ins> this.toggle.domNode.tabIndex = 1; </ins> DOM.append(this.checkboxContainer, this.toggle.domNode); this.registerListener(node); }


} async toggleAppliationScope(extension: ILocalExtension, fromProfileLocation: URI): Promise<ILocalExtension> { <del> if (isApplicationScopedExtension(extension.manifest)) { </del> <ins> if (isApplicationScopedExtension(extension.manifest) || extension.isBuiltin) { </ins> return extension; }


menu: { id: MenuId.ExtensionContext, group: '2_configure', <del> when: ContextKeyExpr.and(ContextKeyExpr.equals('extensionStatus', 'installed'), ContextKeyExpr.has('isDefaultApplicationScopedExtension').negate()), </del> <ins> when: ContextKeyExpr.and(ContextKeyExpr.equals('extensionStatus', 'installed'), ContextKeyExpr.has('isDefaultApplicationScopedExtension').negate(), ContextKeyExpr.has('isBuiltinExtension').negate()), </ins> order: 3 }, run: async (accessor: ServicesAccessor, id: string) => {


} async toggleApplyExtensionToAllProfiles(extension: IExtension): Promise<void> { <del> if (!extension.local || isApplicationScopedExtension(extension.local.manifest)) { </del> <ins> if (!extension.local || isApplicationScopedExtension(extension.local.manifest) || extension.isBuiltin) { </ins> return; } await this.extensionManagementService.toggleAppliationScope(extension.local, this.userDataProfileService.currentProfile.extensionsResource);


Question:
VS Code Version: 1.82.0-insider OS Version: Ubuntu 22.04 The path is missing the first character in the path for a specific file on the 'git show --textconv' lines 'ub-folder' vs 'sub-folder' If the command is run manually, with the correct path there are no issues Working (Non-root folder) 2023-08-03 19:10:33.264 [info] git show --textconv [4ms] 2023-08-03 19:10:33.267 [info] git ls-tree -l HEAD -- [4ms] Not Working (Root folder) 2023-08-03 19:12:26.351 [info] git show --textconv [20ms] 2023-08-03 19:12:26.386 [info] git ls-tree -l HEAD -- [35ms] Expected (Root folder) 2023-08-03 19:12:26.351 [info] git show --textconv [20ms] 2023-08-03 19:12:26.386 [info] git ls-tree -l HEAD -- [35ms] Originally posted by in
could you please share repro steps that I could use to reproduce this? Or the complete contents of the git output window would also help. I have a suspicion where the issue is but I need the logs to reproduce and fix the issue. Thanks!
Hello Ladislau Szomoru, open vsc go to Source Control (Ctrl+Shift+G) look under "Staged Changes" and click on notice left side is always empty and right side shows entire file changed. Thanks, Gregory Porras

* Given the `repository.root` compute the relative path while trying to preserve * the casing of the resource URI. The `repository.root` segment of the path can * have a casing mismatch if the folder/workspace is being opened with incorrect <del> * casing. </del> <ins> * casing which is why we attempt to use substring() before relative(). </ins> */ export function relativePath(from: string, to: string): string { <del> // On Windows, there are cases in which `from` is a path that contains a trailing `` character // (ex: C:, serverfolder) due to the implementation of `path.normalize()`. This behavior is // by design as documented in https://github.com/nodejs/node/issues/1765. if (isWindows) { from = from.replace(/$/, ''); </del> <ins> // There are cases in which the `from` path may contain a trailing separator at // the end (ex: "C:", "serverfolder" (Windows) or "/" (Linux/macOS)) which // is by design as documented in https://github.com/nodejs/node/issues/1765. If // the trailing separator is missing, we add it. if (from.charAt(from.length - 1) !== sep) { from += sep; </ins> } if (isDescendant(from, to) && from.length < to.length) { <del> return to.substring(from.length + 1); </del> <ins> return to.substring(from.length); </ins> } // Fallback to `path.relative`


Question:
hover over editor tabs observe some kind of shadow dropping over the text
This only reproduces with set to and tabs enabled in general. Hovering over any tab shows the white shadow at the end of the label. With this setting, every tab label has a element to draw a linear gradient (): <img width="400" alt="image" src=""A tab itself is a container of a label and the toolbar with the close button. The close button is set to to not take more space than needed. When you hover, the toolbar is made visible, actually pushing the element into view having the described effect: <img width="504" alt="image" src=""I actually think this is an OK behaviour for when the tab is small enough that the label cannot full show, and that was the intention. However, it is a bit strange that this would happen even for a tab that shows fully and has enough space. If someone wants to chime in to take a look with a reasonably small change, opening for help wanted. But may decide to close out of scope as this does not seem like it was ever a regression.

padding-right: 5px; /* with tab sizing shrink/fixed and badges, we want a right-padding because the close button is hidden */ } <ins> .monaco-workbench .part.editor > .content .editor-group-container > .title .tabs-container > .tab.sizing-shrink:not(.tab-actions-left):not(.tab-actions-off) .tab-label { padding-right: 5px; /* ensure that the gradient does not show when tab actions show https://github.com/microsoft/vscode/issues/189625*/ } </ins> .monaco-workbench .part.editor > .content .editor-group-container > .title .tabs-container > .tab.sticky-compact:not(.has-icon) .monaco-icon-label { text-align: center; /* ensure that sticky-compact tabs without icon have label centered */ }


Question:
Insiders 1.82.0 Looks like the command center and associated toolbar buttons aren't functioning when clicked. Weirdly it seems like I can sometimes(?) get a hover state but it doesn't always work. Repeated clicks minimizes the window which makes me think the events are going straight to the titlebar and being handled as such.
I can reproduce
Maybe an Electron 25 update regression with draggable regions and custom title bar? //cc
looks like behavior on macOS is now aligned with windows and linux, the region no longer emits events. Behavior changed with this commit and verified with the following fiddle Looks like we would need to revert this change to align with Windows and Linux.
Yeah, looks like drag and click isn't working for macOS anymore. It always seems like an oversight/bug but a wanted one. To enable clicking again I have the for the CC even for mac. On the downside it means that the window cannot be repositioned from the CC anymore
Slack is the same, you cannot drag from their command center either.

/* Window Title Menu */ .monaco-workbench .part.titlebar > .titlebar-container > .titlebar-center > .window-title > .command-center { z-index: 2500; <del> } /* MacOS Desktop supports click event despite `drag` and therefore we don't need to clear it */ .monaco-workbench:not(.mac) .part.titlebar > .titlebar-container > .titlebar-center > .window-title > .command-center, .monaco-workbench.mac.web .part.titlebar > .titlebar-container > .titlebar-center > .window-title > .command-center { </del> -webkit-app-region: no-drag; }


Question:
Settings: !
How it should be: <img width="442" alt="image" src=""
Hm, strange. I haven't made any changes here lately. I'm noting that is not having an effect on the foreground color used on the tree within Explorer. It does however affect other lists like the one used in the quick pick. I also noticed the terminal tabs tree flicker to use that red before being stomped on again. Not sure what's going on here yet.
Looks like this is from
Gotcha I might just revert the change and switch it to something more specific - I didn't consider all the other applications of the list widget and checking other themes (it was okay in a couple of the themes I checked)

} if (styles.listFocusForeground) { <del> content.push(`.monaco-list${suffix}:focus .monaco-list-row.focused:not(.monaco-list-row.action.option-disabled) { color: ${styles.listFocusForeground}; }`); </del> <ins> content.push(`.monaco-list${suffix}:focus .monaco-list-row.focused { color: ${styles.listFocusForeground}; }`); </ins> } if (styles.listActiveSelectionBackground) {


Question:
Settings: !
How it should be: <img width="442" alt="image" src=""
Hm, strange. I haven't made any changes here lately. I'm noting that is not having an effect on the foreground color used on the tree within Explorer. It does however affect other lists like the one used in the quick pick. I also noticed the terminal tabs tree flicker to use that red before being stomped on again. Not sure what's going on here yet.
Looks like this is from
Gotcha I might just revert the change and switch it to something more specific - I didn't consider all the other applications of the list widget and checking other themes (it was okay in a couple of the themes I checked)

} .action-widget .monaco-list-row.action.option-disabled, <ins> .action-widget .monaco-list:focus .monaco-list-row.focused.action.option-disabled, </ins> .action-widget .monaco-list-row.action.option-disabled .codicon { color: var(--vscode-disabledForeground); } .action-widget .monaco-list-row.action:not(.option-disabled) .codicon { color: inherit; }


Question:
Type: <bPerformance Issue</bIn a bash terminal with Shell Integration, execute the following command, which is 5k characters long: On both my machines (Linux native and Windows + RemoteSSH), this commande takes 1s to execute. Make it 10k characters and it takes 4s. At 15k, it takes 8s. I'm using bash version 4.4.23 (the one shipped on SLES15 SP4). It appears to be related to the Bash Shell Integration, specifically the function located . This can even be reproduced outside of VSCode, in plain bash. Just define this function in a shell and execute it with a long argument. As a workaround, it is possible to disable Shell Integration in the settings and open new terminals. With a newer bash 5.2 built by myself, performances are better, but still non-negligible: 5k: 0.5s, 10k: 1.5s, 15k: 3.5s. Note: I get similar numbers with a bash 4.4 compiled by myself, so better performances with newer bash might just be related to different compilation options/optimizations. VS Code version: Code 1.81.1 (, 2023-08-09T22:18:39.991Z) OS version: Linux x64 5.14.21-.24.28-default Modes: <details<summarySystem Info</summary </details<details<summaryProcess Info</summary</details<details<summaryWorkspace Info</summary</details<details<summaryExtensions (1)</summaryExtensionVersion ------ remote-ssh0.90.1 </details<!-- generated by issue reporter --
Thanks for the report, hopefully a bash expert will spot this and help optimize the function
Unfortunately this still seems to be quite slow for me. Normal bash runs quicky (). Bash in VS Code has had a core stuck at 100% CPU for a few minutes now with no signs of letting up... <img width="790" alt="image" src=""Doing some binary searching, it's "fast" until the echo hits 1989 characters (a total command length of 2001 characters), at which point it stalls as above
Actually, it seems any command over 2000 characters in bash stalls and takes a long time to run. Doesn't have to be an echo. It seems like time taken is somewhat exponential, 2001 characters take 21s to run for me while 2100 characters jumps that up to 29s. That seems to be the point at which we use a 'fast' implementation. In reality this seems much slower on macOS at least
Hi. Could you check that whether you have command and on your system? Since I actually provided two fast impl in the PR, I would like to know which is problemetic for subsequent troubleshooting. Edit: never mind. I have reproduced the hang and propose another fix.

builtin printf '%s' "${terms[2]:-}" } <ins> __vsc_escape_value_fast() { builtin local LC_ALL=C out out=${1///} out=${out//;/x3b} builtin printf '%sn' "${out}" } </ins> # The property (P) and command (E) codes embed values which require escaping. # Backslashes are doubled. Non-alphanumeric characters are converted to escaped hex. __vsc_escape_value() { <ins> # If the input being too large, switch to the faster function if [ "${#1}" -ge 2000 ]; then __vsc_escape_value_fast "$1" builtin return fi </ins> # Process text byte by byte, not by codepoint. builtin local LC_ALL=C str="${1}" i byte token out=''


Question:
Workaround This is an issue in Chromium itself. For now there are the following two workarounds: ### <blockQuote</blockQuote1. ### <blockQuote</blockQuote## Bug <!-- 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. -- <!-- 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. --1. ### VS Code Version Per: affected version is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.82.0-insider Commit | Date | 2023-08-11T17:10:45.392Z Electron | 25.4.0 ElectronBuildId | Chromium | 114.0.5735.248 | 18.15.0 V8 | 11.4.183.27-electron.0 OS | Linux x64 6.4.9-1-default </blockQuoteHowever, per: that , that is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.81.1 Commit | Date | 2023-08-09T22:18:39.991Z Electron | 22.3.18 ElectronBuildId | Chromium | 108.0.5359.215 | 16.17.1 V8 | 10.8.168.25-electron.0 OS | Linux x64 6.4.9-1-default snap ### OS Version <blockQuote</blockQuote</details## Steps to Reproduce 1. The GUI is invisible: the menubar continues to operate correctly.
82 updated to Electron 25 and doesn't work on older OS.
I'm using cpe:/o:opensuse:tumbleweed:, which updated 2600 packages yesterday (which I have installed) yet this problem remains. Nobody in their right mind would consider that to be old. Additionally, I am using which means that no independent part of the OS should be considered old. This is the most bleeding edge system for miles. Regardless, should I perhaps open a linked issue at
Oh, sorry, I thought it's an old OS issue. Before reporting in the electron repo, what is Help Toggle Developer Tools bringing up? Have you tried to do a clean reinstall of VSCode Insider? Perhaps it was just a bad build. Or, alternatively, you could try to download the latest Insider installer and install over your existing broken version (which I assume it's 3-4 days older than what you'd get right now) - that should effectively update it.
No problem. Thanks. Apologies for being curt. ! ! Appears that it's reproducible.
Very strange, indeed. I'm out of ideas. Would be interesting to be able to test with a previous Insider version, but for that you would need to have the old package and disable automatic updates. Electron was updated from 22 to 25 on August 8, so the last version with Electron 22 is the Insider from August 7, which is also the last version that I've tested and still working on Windows 7. Anything after that doesn't start anymore on Win 7. I'm not sure whether the Electron update on August 8 is causing your issue, though...
does the log file explain anything? To me, it seemed a little too verbose to be of much use. I can try other methods to get relevant diagnostic data if you are able to instruct me.
I see many GPU-related errors, such as: Errors: link failed but did not provide an info log [(48)] (checkLinkStatus): Program link or binary loading failed with no info log. [(81)] Skia shader compilation error Found these: So it's definitely something related to the new Chromium included in Electron 25 and these issues seem relatively recent. The first link recommends to disable hardware acceleration, you could try searching how to do that from command line in the new Insider. Unfortunately, I don't have the time to dig deeper right now.
per , do you know whether VSCode contains a directory? I haven't been able to locate it.
remediates the problem. Because indeed this issue is dependent upon , before this update is rolled out, there needs to be remediating measures (or the update needs to be temporarily halted) lest it break a great many peoples' installations.
Can you please take a look at this? It's Chromium/Electron 25 related, so I immediately thought of you. Please see the response just above for a possible solution. Thanks!
Thanks for investigating the issue, given there are workarounds in place this is not necessarily a release blocker. I will wait for chromium to address this issue and backport the fix to Electron 25.
could a patch at least be to the affected releases to delete the relevant directory? Surely users shall be affected otherwise? I doubt we can expect them to diagnose a known issue if the solution is so simple.
We don't want to delete the GPUCache for all users and the affected scenario described in is not possible to detect from the application layer. I think the best I can do is to add this issue to the release notes and document the workarounds for visibility.
Why?
It will have impact on startup performance, for now I would wait to see the impact of this issue across our users and decide on a fix forward. The upstream issue has also been open for a while now, signifying its low impact.
Just happened again. !
This is mentioned in the 1.82 release notes I guess the issue remains in 1.83-insiders, haven't tried it yet.
It appears weird to me that solely VSCode appears to be affected by this (on my system) because Discord has been very happily updating frequently, and obviously has its own Electron-provided directory. !
Related on Stack Overflow: Related on Reddit: ,
Got this installed via fedora yesterday This wasted quiet some time on my end, as I first went searching for changes to fedora itself and finding this issue on vscode wasn't trivial.
Leaving this here for future me, as I now have that problem on a different PC
This also happens for other Electron based programs like Element and also chromium and firefox. see
I'd disagree, . It doesn't read like pragmatism - more like "didn't want to do a good fix". Startup time after the workaround felt normal. Super aggravating that this wasn't resolved with a one-time installation task to clear the GPU cache. Hard to know the aggregate cost incurred by people encountering this issue, but "not small" is probably an underestimation. Linked-issue count wouldn't be a good proxy for that metric, in that product-support's practice as shown in seems to be linking to the known-issue buried in the release notes, not to this issue. Sorry for the flames, but there you have it. When one's coding environment gets fsck'd, it's no fun, and erodes trust. Please consider.
I, for one, find great enjoyment in my coding environments.
This issue has reemerged with the latest version 1.82.3 for Ubuntu 20.04.1: Removing after the upgrade still works to get vscode running
It occurs for me almost every update of the package. It's ridiculous.
Same.
As mentioned before, this is caused by the new update in VSCode I have personally reverted to until this issue is properly solved
I was under the impression from the chromium bug that this is one time change and not required for every startup. I see that you are using snap version of VSCode, can you check if you are required to delete the cache for every start using the instead ?
I must rectify my comment: with the snap of version v1.82.1, it was required to clear the cache every startup, with v1.82.2 I don't remember having to do it, while with v1.82.3 it was needed only once on upgrade. I will edit my previous comment to fix it.
We had a runtime version bump between to , which seems like a trigger in the snap case. Can you setup deb package, we will have release this week. It would be good to confirm if updating requires to clear the cache in the deb package as well.
For what it's worth, I haven't encountered it on the rpm again
I've tried the following: removing v1.82.3 (snap) and installing v1.82.3 (deb) did require clearing the cache. removing v1.82.3 (deb) and installing v1.82.2 (deb) did not require removing the GPUCache. upgrading v1.82.2 (deb) to v1.82.3 (deb) using apt did not require removing the GPUCache. hope it helps
I'm not using the snap any more. I use the package provided directly by Microsoft from
Encountered this problem on Fedora 39, probably after upgrading my vscode rpm which is currently on version 1.82.3. Problem disappeared after running .
Not with VSCode specifically: but when updating to electron v28 alpha, had this issue. Also solved with (or just deleting the entire Electron dir within ).
Also ran into this, thanks for this workaround, it worked.
I also ran into the issue in VSCodium (which is a special build script for this source code) after an upgrade to 1.83.1 on Debian Trixie and XFCE 4.18. The worked like a charm (which is the equivalent folder on Debian for VSCodium). I did find that I only ran into the issue on my RX 550 (Lexa) and not my Radeon RX 580 (Polaris); I found that the bug disappeared when running the program with appended to it to run it on the latter graphics card.
This has happened a second time in 1.83.1.
Got it again on fedora using the rpm on a system, where I already dropped the cache once Version 1.83.1
Just installed an update with no vscode update but had a mesa update. VSCode broke again. I assume this is going to happen every time a mesa update is installed (I'm assuming because of what others are stating, could be something other than mesa but seems to be the biggest suspect).
Getting it after every mesa update. But may be "GPUCache" need some harder refresh or detection of brockage?
This issue has been fixed upstream via . It might take a while before it trickles downstream though, since it needs to be picked up by Electron first before it can go into VSCode. I did attempt cherry-picking the commit and generating a local build and it seemed to fix the issue.
The commit is fairly trivial and can probably be safely backported to all supported Electron trees. This is a very widespread issue, affecting virtually every Electron app running on Linux. It would be great to get the fix as widely disseminated as possible considering how slow the app ecosystem is to update versions. Is there a linked Electron issue for this? Do we need to create one if not or does the Electron project accept drive-by backport PRs?
I haven't found any linked Electron issues yet. Based on , since the patch is temporary, has been committed upstream, and will eventually be removed, I think the Electron folks will accept the patch. However, do take note that the commit has dependencies on previous commits. On my working local build, I have these 3 commits cherry-picked in chronological order: Therefore, if anyone is going to bring this up to the Electron team, all 3 patches would need to be merged. Add the patch files to the and append the filenames of said patch files to the . Depending on the Electron build version, there might also be some merge conflicts. Based on my experience, those conflicts should be resolvable, but I did not test all of the older Electron major version release branches. For each branch, we would need to double-check if the 2 dependency commits are already included in their respective Chromium version or not.
Thank you for the backporting work to Electron versions 25-28 over the past few days. Downstream applications should now be able to pick those fixes up. Once VSCode picks up the fix, we should be able to close this issue.
<!-- 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!
I'll verify when the next release reaches me on openSUSE.
by chance, were you able to verify the fix for the issue yet?
the time period hasn't been quite long enough to be certain. This usually occurs on an update or after approximately two months. However, VSCode did update recently, and this didn't occur (not that it was guaranteed). Consequently, if upstream has fixed the issue, and we're using the patched version, because it hasn't appeared yet, I'll keep this completed until it occurs (and we can reasonably consider this complete).
Considering the issue as verified on 1.85.x. 1.86.0 will go out in around a week. Feel free to comment on this issue thread if the issue comes up again after that.

disturl "https://electronjs.org/headers" <del> target "25.9.2" ms_build_id "24603566" </del> <ins> target "25.9.4" ms_build_id "25127168" </ins> runtime "electron" build_from_source "true"


Question:
Workaround This is an issue in Chromium itself. For now there are the following two workarounds: ### <blockQuote</blockQuote1. ### <blockQuote</blockQuote## Bug <!-- 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. -- <!-- 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. --1. ### VS Code Version Per: affected version is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.82.0-insider Commit | Date | 2023-08-11T17:10:45.392Z Electron | 25.4.0 ElectronBuildId | Chromium | 114.0.5735.248 | 18.15.0 V8 | 11.4.183.27-electron.0 OS | Linux x64 6.4.9-1-default </blockQuoteHowever, per: that , that is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.81.1 Commit | Date | 2023-08-09T22:18:39.991Z Electron | 22.3.18 ElectronBuildId | Chromium | 108.0.5359.215 | 16.17.1 V8 | 10.8.168.25-electron.0 OS | Linux x64 6.4.9-1-default snap ### OS Version <blockQuote</blockQuote</details## Steps to Reproduce 1. The GUI is invisible: the menubar continues to operate correctly.
82 updated to Electron 25 and doesn't work on older OS.
I'm using cpe:/o:opensuse:tumbleweed:, which updated 2600 packages yesterday (which I have installed) yet this problem remains. Nobody in their right mind would consider that to be old. Additionally, I am using which means that no independent part of the OS should be considered old. This is the most bleeding edge system for miles. Regardless, should I perhaps open a linked issue at
Oh, sorry, I thought it's an old OS issue. Before reporting in the electron repo, what is Help Toggle Developer Tools bringing up? Have you tried to do a clean reinstall of VSCode Insider? Perhaps it was just a bad build. Or, alternatively, you could try to download the latest Insider installer and install over your existing broken version (which I assume it's 3-4 days older than what you'd get right now) - that should effectively update it.
No problem. Thanks. Apologies for being curt. ! ! Appears that it's reproducible.
Very strange, indeed. I'm out of ideas. Would be interesting to be able to test with a previous Insider version, but for that you would need to have the old package and disable automatic updates. Electron was updated from 22 to 25 on August 8, so the last version with Electron 22 is the Insider from August 7, which is also the last version that I've tested and still working on Windows 7. Anything after that doesn't start anymore on Win 7. I'm not sure whether the Electron update on August 8 is causing your issue, though...
does the log file explain anything? To me, it seemed a little too verbose to be of much use. I can try other methods to get relevant diagnostic data if you are able to instruct me.
I see many GPU-related errors, such as: Errors: link failed but did not provide an info log [(48)] (checkLinkStatus): Program link or binary loading failed with no info log. [(81)] Skia shader compilation error Found these: So it's definitely something related to the new Chromium included in Electron 25 and these issues seem relatively recent. The first link recommends to disable hardware acceleration, you could try searching how to do that from command line in the new Insider. Unfortunately, I don't have the time to dig deeper right now.
per , do you know whether VSCode contains a directory? I haven't been able to locate it.
remediates the problem. Because indeed this issue is dependent upon , before this update is rolled out, there needs to be remediating measures (or the update needs to be temporarily halted) lest it break a great many peoples' installations.
Can you please take a look at this? It's Chromium/Electron 25 related, so I immediately thought of you. Please see the response just above for a possible solution. Thanks!
Thanks for investigating the issue, given there are workarounds in place this is not necessarily a release blocker. I will wait for chromium to address this issue and backport the fix to Electron 25.
could a patch at least be to the affected releases to delete the relevant directory? Surely users shall be affected otherwise? I doubt we can expect them to diagnose a known issue if the solution is so simple.
We don't want to delete the GPUCache for all users and the affected scenario described in is not possible to detect from the application layer. I think the best I can do is to add this issue to the release notes and document the workarounds for visibility.
Why?
It will have impact on startup performance, for now I would wait to see the impact of this issue across our users and decide on a fix forward. The upstream issue has also been open for a while now, signifying its low impact.
Just happened again. !
This is mentioned in the 1.82 release notes I guess the issue remains in 1.83-insiders, haven't tried it yet.
It appears weird to me that solely VSCode appears to be affected by this (on my system) because Discord has been very happily updating frequently, and obviously has its own Electron-provided directory. !
Related on Stack Overflow: Related on Reddit: ,
Got this installed via fedora yesterday This wasted quiet some time on my end, as I first went searching for changes to fedora itself and finding this issue on vscode wasn't trivial.
Leaving this here for future me, as I now have that problem on a different PC
This also happens for other Electron based programs like Element and also chromium and firefox. see
I'd disagree, . It doesn't read like pragmatism - more like "didn't want to do a good fix". Startup time after the workaround felt normal. Super aggravating that this wasn't resolved with a one-time installation task to clear the GPU cache. Hard to know the aggregate cost incurred by people encountering this issue, but "not small" is probably an underestimation. Linked-issue count wouldn't be a good proxy for that metric, in that product-support's practice as shown in seems to be linking to the known-issue buried in the release notes, not to this issue. Sorry for the flames, but there you have it. When one's coding environment gets fsck'd, it's no fun, and erodes trust. Please consider.
I, for one, find great enjoyment in my coding environments.
This issue has reemerged with the latest version 1.82.3 for Ubuntu 20.04.1: Removing after the upgrade still works to get vscode running
It occurs for me almost every update of the package. It's ridiculous.
Same.
As mentioned before, this is caused by the new update in VSCode I have personally reverted to until this issue is properly solved
I was under the impression from the chromium bug that this is one time change and not required for every startup. I see that you are using snap version of VSCode, can you check if you are required to delete the cache for every start using the instead ?
I must rectify my comment: with the snap of version v1.82.1, it was required to clear the cache every startup, with v1.82.2 I don't remember having to do it, while with v1.82.3 it was needed only once on upgrade. I will edit my previous comment to fix it.
We had a runtime version bump between to , which seems like a trigger in the snap case. Can you setup deb package, we will have release this week. It would be good to confirm if updating requires to clear the cache in the deb package as well.
For what it's worth, I haven't encountered it on the rpm again
I've tried the following: removing v1.82.3 (snap) and installing v1.82.3 (deb) did require clearing the cache. removing v1.82.3 (deb) and installing v1.82.2 (deb) did not require removing the GPUCache. upgrading v1.82.2 (deb) to v1.82.3 (deb) using apt did not require removing the GPUCache. hope it helps
I'm not using the snap any more. I use the package provided directly by Microsoft from
Encountered this problem on Fedora 39, probably after upgrading my vscode rpm which is currently on version 1.82.3. Problem disappeared after running .
Not with VSCode specifically: but when updating to electron v28 alpha, had this issue. Also solved with (or just deleting the entire Electron dir within ).
Also ran into this, thanks for this workaround, it worked.
I also ran into the issue in VSCodium (which is a special build script for this source code) after an upgrade to 1.83.1 on Debian Trixie and XFCE 4.18. The worked like a charm (which is the equivalent folder on Debian for VSCodium). I did find that I only ran into the issue on my RX 550 (Lexa) and not my Radeon RX 580 (Polaris); I found that the bug disappeared when running the program with appended to it to run it on the latter graphics card.
This has happened a second time in 1.83.1.
Got it again on fedora using the rpm on a system, where I already dropped the cache once Version 1.83.1
Just installed an update with no vscode update but had a mesa update. VSCode broke again. I assume this is going to happen every time a mesa update is installed (I'm assuming because of what others are stating, could be something other than mesa but seems to be the biggest suspect).
Getting it after every mesa update. But may be "GPUCache" need some harder refresh or detection of brockage?
This issue has been fixed upstream via . It might take a while before it trickles downstream though, since it needs to be picked up by Electron first before it can go into VSCode. I did attempt cherry-picking the commit and generating a local build and it seemed to fix the issue.
The commit is fairly trivial and can probably be safely backported to all supported Electron trees. This is a very widespread issue, affecting virtually every Electron app running on Linux. It would be great to get the fix as widely disseminated as possible considering how slow the app ecosystem is to update versions. Is there a linked Electron issue for this? Do we need to create one if not or does the Electron project accept drive-by backport PRs?
I haven't found any linked Electron issues yet. Based on , since the patch is temporary, has been committed upstream, and will eventually be removed, I think the Electron folks will accept the patch. However, do take note that the commit has dependencies on previous commits. On my working local build, I have these 3 commits cherry-picked in chronological order: Therefore, if anyone is going to bring this up to the Electron team, all 3 patches would need to be merged. Add the patch files to the and append the filenames of said patch files to the . Depending on the Electron build version, there might also be some merge conflicts. Based on my experience, those conflicts should be resolvable, but I did not test all of the older Electron major version release branches. For each branch, we would need to double-check if the 2 dependency commits are already included in their respective Chromium version or not.
Thank you for the backporting work to Electron versions 25-28 over the past few days. Downstream applications should now be able to pick those fixes up. Once VSCode picks up the fix, we should be able to close this issue.
<!-- 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!
I'll verify when the next release reaches me on openSUSE.
by chance, were you able to verify the fix for the issue yet?
the time period hasn't been quite long enough to be certain. This usually occurs on an update or after approximately two months. However, VSCode did update recently, and this didn't occur (not that it was guaranteed). Consequently, if upstream has fixed the issue, and we're using the patched version, because it hasn't appeared yet, I'll keep this completed until it occurs (and we can reasonably consider this complete).
Considering the issue as verified on 1.85.x. 1.86.0 will go out in around a week. Feel free to comment on this issue thread if the issue comes up again after that.

<del> 2606d6745056d248fe7ba21e6a30467d3ea80d2689c5fa6d2a35acf1b4a72ddd *chromedriver-v25.9.2-darwin-arm64.zip 22a86732b9e6c2afc07021ea0adeb92cdbaaa8751843c0d5170b5e96550685e7 *chromedriver-v25.9.2-darwin-x64.zip f5f42513bb55c7c1098e669d12488844ca2e63cd0d3a375db2eab517975c130c *chromedriver-v25.9.2-linux-arm64.zip 28a5613f7e4b117a65ec2882b124bf1d388f1c4fb86b228acadc297601faa6fd *chromedriver-v25.9.2-linux-armv7l.zip 7d01d537383df4b1653647e14fb768d27879943596a87b57ae3f171aa2aaf5d1 *chromedriver-v25.9.2-linux-x64.zip 3fac66fe45b4a5dcd9a4784d66bd8087d0dee5fccf06cb3f34e78f8bef3f0f8f *chromedriver-v25.9.2-mas-arm64.zip a15fc80fac243330f15a7ff7cc834c50c79833e81b871cc45f7239bf1743b4ac *chromedriver-v25.9.2-mas-x64.zip f0a354e01e277b14422e34f8af9c8c43ae975c6fb69a2e61ef275b6ec919f2ab *chromedriver-v25.9.2-win32-arm64.zip 570a6b5bc485bfea9681c97b79832d5d5bcafdd993c13dc4ab11558e3a27c554 *chromedriver-v25.9.2-win32-ia32.zip 4134f539ac304c65dfca9812b0d3943ea64d886989eba8f62828718b106c4eee *chromedriver-v25.9.2-win32-x64.zip 835418b9274c76503542c986d63bb9d98f071c702170536bdd62c1760589e01e *electron-api.json fd9f5b1439445acc69441ef66cc47f56c5c0848dec5f6daf91a476073e72a756 *electron-v25.9.2-darwin-arm64-dsym-snapshot.zip de29ef2a4c7b76281b1cf3ac9e6047a9275cc60167c6cd60509f2eb2a3258842 *electron-v25.9.2-darwin-arm64-dsym.zip 732f51802f2902ca08c3a06a45fe23820b1effbeb3ebd39fcae9fce5a1e0b25d *electron-v25.9.2-darwin-arm64-symbols.zip ab82efb59077a85fd20264f8ad0dedc4c8b0b2fc9d2948ed9461425faf5e35f6 *electron-v25.9.2-darwin-arm64.zip fb924b4dd0d781a14114e54fa556ca326c60665b674712c59163e7b44db675d8 *electron-v25.9.2-darwin-x64-dsym-snapshot.zip 197fc3e120e54578658e2f10b5fcec1d2004f1637d4bee116ff1e12b0c5a1429 *electron-v25.9.2-darwin-x64-dsym.zip 57d0a0f55726524ff843a040e516e425c3537a4602ab8c23120433fbc51470fb *electron-v25.9.2-darwin-x64-symbols.zip 0fe310e2ed13a97cd9c28fb0cf806338cd2e720083e6d1b13d60ba4cedb8f295 *electron-v25.9.2-darwin-x64.zip eb1a31ccd6a89a21538a8b1f0b5d3b77e1fe946b898319e1832cb9dc3abcd753 *electron-v25.9.2-linux-arm64-debug.zip b5b128bed0a09955ad5bb91fa9f5ab9155a547f787ad580bcd5bf409bb697ff6 *electron-v25.9.2-linux-arm64-symbols.zip 0b2d48a29d79fcd21d72d05fdb7638dd2fd257cf0d4cf9bd32f182b2634de466 *electron-v25.9.2-linux-arm64.zip eb1a31ccd6a89a21538a8b1f0b5d3b77e1fe946b898319e1832cb9dc3abcd753 *electron-v25.9.2-linux-armv7l-debug.zip 43f1f4c1475335719ba8f1f7f036a084fb22b5faa908bf4f7d30a96d5d9c159d *electron-v25.9.2-linux-armv7l-symbols.zip 4ea3ee3ad41c69454d9a12518eeff1ec5dbd841c8200dc8652e6c0b101d1259c *electron-v25.9.2-linux-armv7l.zip 1a8daf1f9e155d7143d16367e54e4e3b8e9d71ad580b44c8dfba0cb4e7a1c640 *electron-v25.9.2-linux-x64-debug.zip 803f32ca345d8974cc074dc177e06c62f8bcc98d4a39eccb676b7d302b8fc466 *electron-v25.9.2-linux-x64-symbols.zip aab65a562723e04eadbdee1251a749756b366dc1c5014bcc987c21c0a523fe2f *electron-v25.9.2-linux-x64.zip fd9f5b1439445acc69441ef66cc47f56c5c0848dec5f6daf91a476073e72a756 *electron-v25.9.2-mas-arm64-dsym-snapshot.zip 0ec88ec7bd2b7cb2e5e6b94f13df7d8c22433637004a473370e0959cb01f78cc *electron-v25.9.2-mas-arm64-dsym.zip 398a0575c1974565af99b6759a74967c0709bc101059542a00bfe64a1210a86f *electron-v25.9.2-mas-arm64-symbols.zip 17f86ad33f9fc2ca5eaac5ef87604e65b1eefba5a51d4ad58e70018fdfb84ac6 *electron-v25.9.2-mas-arm64.zip db61b29802ee1f598a3e61211a281656f16e70ae84041e6b2b5dd8ecae43cd67 *electron-v25.9.2-mas-x64-dsym-snapshot.zip 2f76620eb7d632335f7620f5d3713af5e59c98bdb0b323269c2319b7164fcaac *electron-v25.9.2-mas-x64-dsym.zip ea226c8d049e527d84ec5058474fd4e64476e6924fef42b1dbea774925f59064 *electron-v25.9.2-mas-x64-symbols.zip 51b9d192ccb7612211ca9cc8ddb373a86f791d38b369337ad099a133e9d9807a *electron-v25.9.2-mas-x64.zip 53b39857303191ea2f26dda06461e6e612ca0ed799bdf0c26a1a63ff89f7ea1b *electron-v25.9.2-win32-arm64-pdb.zip 49199591c69fbeb68dd57252a3d8525babe79ab98447ad639f2d0c3e63aba4b6 *electron-v25.9.2-win32-arm64-symbols.zip e7b968fc53cc7a10a4ccb5133af045968479685ebb9617f06817f03667fdd425 *electron-v25.9.2-win32-arm64-toolchain-profile.zip 6abd0a6697d7fe8b6add4d1017a01a0ac756d16da5bfa077bd373a685b529bd8 *electron-v25.9.2-win32-arm64.zip cc5c67b027c679eb86882c2ec267d38fafcc5127b49e8a060002541253e2b26b *electron-v25.9.2-win32-ia32-pdb.zip 2cd8aab8aa4eadfce90c8ba6565a77689db1efe55b7eaafedede3b08e8c41f53 *electron-v25.9.2-win32-ia32-symbols.zip e7b968fc53cc7a10a4ccb5133af045968479685ebb9617f06817f03667fdd425 *electron-v25.9.2-win32-ia32-toolchain-profile.zip ac2aebe7d7b21351256fb3b60219269e75ff33f8c3cfbbca682c3622d1943b94 *electron-v25.9.2-win32-ia32.zip 000b506bab92c92e0ff8428033fc7e1c15049437606794c4bec84a66eb29b6cd *electron-v25.9.2-win32-x64-pdb.zip fd40d04de0ef4a04dd720505f03a6d209a38387fe05493869f441037aa950e4d *electron-v25.9.2-win32-x64-symbols.zip e7b968fc53cc7a10a4ccb5133af045968479685ebb9617f06817f03667fdd425 *electron-v25.9.2-win32-x64-toolchain-profile.zip de3fc45f4fa5572d6dbb4f21580e75d3b6429a6b3b833a962c810e7e199b8573 *electron-v25.9.2-win32-x64.zip c3f22fbf99713bb44546278ef1456e4fc9a83d33bf038f6752fea12c7a721337 *electron.d.ts 2a088f4c227405783466e456e69154193a730130f5cc39520091abc8993977bc *ffmpeg-v25.9.2-darwin-arm64.zip 4da4197282a9a31379d2194d1072888b9ed3200663e322df2759b971725a2915 *ffmpeg-v25.9.2-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.9.2-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.9.2-linux-armv7l.zip 39c3e411873262873edff4b9f4b5d9973fb3cab8f700d6ff665872dab3b39eb3 *ffmpeg-v25.9.2-linux-x64.zip 861287a6cb0f546c0e39f49a2b28f5575d66fbddb26486584cc7802e84402339 *ffmpeg-v25.9.2-mas-arm64.zip bcc8315a9e07394510c96ffca20720e3cdb2a4aecc75798bfca8fd60417782aa *ffmpeg-v25.9.2-mas-x64.zip 0ebfe5a72aaf0a9af81ffbcba03763f4baa142c93c31b50ad0145365366f0076 *ffmpeg-v25.9.2-win32-arm64.zip d8e7ea1268145d3481a74152ced8ae677ca5b174f06eb874a6ce0005ff0d471c *ffmpeg-v25.9.2-win32-ia32.zip d1f499b957377c3822c43eadf3bc32e7cb04b52fb2fd51ba22f14cd61ef01727 *ffmpeg-v25.9.2-win32-x64.zip 86a0df1394e741feb21a891747775911d5c2f9cd940662826b33c309275abb7c *hunspell_dictionaries.zip 4c4bab279b39c4e463dcb3a897e256e5e4f088e6e6495f6aea10e26703ecafc3 *libcxx-objects-v25.9.2-linux-arm64.zip d2b6349a89c9fce3ccc0a9a430b059eb18cd3967dbbe34bfcae54b3f58cd462a *libcxx-objects-v25.9.2-linux-armv7l.zip e8d4b1a3228c0709dc54d780bd4d33727fff30c38f8e00409a6eaf54a69e5869 *libcxx-objects-v25.9.2-linux-x64.zip 7679259e7cb02140806cc616d012102462d671ae07c4673ad0c2c9a6716444a6 *libcxx_headers.zip b1683af6708bceaa966e5168fda51223fa51e09549abc90f5744d500f9260c92 *libcxxabi_headers.zip 4fed33611a889d0100a6fbf4253cf9dcb9fbe3c42f7c86d8886d460a9a9cf8e6 *mksnapshot-v25.9.2-darwin-arm64.zip 5e1daea6393bd977a70020c36f1e4ee4e416c8c4eafe2b27b38292e4acb1764b *mksnapshot-v25.9.2-darwin-x64.zip 92ff719eb83df7f107d4dd3970122333f4bde194292c568b5c0a5ea4684bc9f1 *mksnapshot-v25.9.2-linux-arm64-x64.zip e621d50652f2afa49f47ab7cccd07f7d29ef60f694a0e70d4e6434ddd07cf282 *mksnapshot-v25.9.2-linux-armv7l-x64.zip 012c24dd59f7b5b4322e53c12bb6450a7b15bc6800042fcf3804ba14685f8188 *mksnapshot-v25.9.2-linux-x64.zip 62e880bf8594b1d83926984c252d86990f1386655bd1375afc0fd3054018adef *mksnapshot-v25.9.2-mas-arm64.zip 0742e1bfcbe171199f0a333fddbf401a61777928d462b852d21fec2822b2c46e *mksnapshot-v25.9.2-mas-x64.zip b019e6e117e13238465d1758274ebbaf7ccb999921dcb11ef1e3a9a5a6df952b *mksnapshot-v25.9.2-win32-arm64-x64.zip bc7196f1fd2ba3aedc6c16e96e455d280155dfc493a0d0f6ce7bffe645e39e1e *mksnapshot-v25.9.2-win32-ia32.zip 2d152f09969d69439e831b4212e77ea157a9e4b3a9b3ad55d4f2efcc547c25eb *mksnapshot-v25.9.2-win32-x64.zip </del>  No newline at end of file <ins> 004cb2a93a7094449675ac49998f1c1572dd74b7839039332525f44a2a4d6905 *chromedriver-v25.9.4-darwin-arm64.zip e578c2b7c88ae066664c0562ca77f776d419a6ae5045383df9718e743147f880 *chromedriver-v25.9.4-darwin-x64.zip 7c0f030cf143d682ae838e078d560b76b5f0af8c65d67f6026167c0a04c8f60b *chromedriver-v25.9.4-linux-arm64.zip 320026f620bdd708aff88c97ee9bf40d2fbad4fce4be0be3c8252876c9a629ec *chromedriver-v25.9.4-linux-armv7l.zip 65d4473294f024e4ba56a72ba9f87bec51207a7c924fda998acf499e5db4da9c *chromedriver-v25.9.4-linux-x64.zip 191ba934dace5851f60ec5cdb040202dacebf837ae6b8483649cc85da698ffeb *chromedriver-v25.9.4-mas-arm64.zip 1da9b56db091b1825cb3913de5eb12e30bb55f55023e044bed9e6d1518ab86f7 *chromedriver-v25.9.4-mas-x64.zip 3efd22a6d4500603f629f5c58af44570909df6871eccc9d17c01d04ab17ca47e *chromedriver-v25.9.4-win32-arm64.zip cd8b4be4d491f39aebc97102e2a48e43260eff693163c1526f1fb0b401ec0a81 *chromedriver-v25.9.4-win32-ia32.zip 03df2f38e3a07f70b766a5f0a9548acf8b35148dcb97d12e0479fd527da423e3 *chromedriver-v25.9.4-win32-x64.zip f1c4c82db5b9649d7e9cdb4c482a76ded439f6b11267f4b5eb869616a7f8244a *electron-api.json ac61c1f78f4bebf74073b4dbca356bc3aef6b44b4b069f8f2bfdb03d562e50f9 *electron-v25.9.4-darwin-arm64-dsym-snapshot.zip 54424b0db7f38794dbc5aff1bf3a20fc93f0f35a03fce8eaaf523bbc075fef83 *electron-v25.9.4-darwin-arm64-dsym.zip 1d816ad4c6a6e198d8ae6bb49698982f0f0298a605db09d46d3d4509c16a84a1 *electron-v25.9.4-darwin-arm64-symbols.zip 8022153ed1437a5785a0f819d14f41ae1026c1c5c1406d535a32c2a0ec1e4ba3 *electron-v25.9.4-darwin-arm64.zip 1a76a3c9ef80989488ed5a5cb9d4f54d284f79931f98907e6dbe3437271b33c0 *electron-v25.9.4-darwin-x64-dsym-snapshot.zip 92b14aa0a6dbbf9dd4829464ecea4ee77536f6c45cd393aa00b502eb5d72e480 *electron-v25.9.4-darwin-x64-dsym.zip 0bd268108df307e6d7770fea8882b5072ced5da23a0914e3e660e26c80314174 *electron-v25.9.4-darwin-x64-symbols.zip 4a3b55cfdb3fedbe188f51c552ffa1f9d17d145926990ca914faccbb72634ee6 *electron-v25.9.4-darwin-x64.zip 59bde360b480228cb166836d678682146d6f4cf9c8e6a534087c974e827b11bb *electron-v25.9.4-linux-arm64-debug.zip c8a2174ddfa18eeb326c830cbaf944931038de422d7e8492a9a5680dd54c77eb *electron-v25.9.4-linux-arm64-symbols.zip 119481d318dec273434f9f4f43fb808ff66858cc0da1f17deccc6b08a99fbb83 *electron-v25.9.4-linux-arm64.zip 59bde360b480228cb166836d678682146d6f4cf9c8e6a534087c974e827b11bb *electron-v25.9.4-linux-armv7l-debug.zip f791ce6c4bfe8ae7a00df9ac9dad766ce5ac4e502092b02c0361327a84ac07a8 *electron-v25.9.4-linux-armv7l-symbols.zip 2ef1673f4c6b943b35dc1dd3379aae7534f2456c91eabc704e2db35012aac706 *electron-v25.9.4-linux-armv7l.zip ff0e6cd86b963d87edd02202284e1fd29842f5fa85b4ca7a21ab753507ab3a9d *electron-v25.9.4-linux-x64-debug.zip add83741ede569ec1ed243aea8a77d782674a59c62221a4b9bd07507af62441e *electron-v25.9.4-linux-x64-symbols.zip 84f92675e3a9616cc163de673ebfafaad3c2976dc500612875a23849bc3661ce *electron-v25.9.4-linux-x64.zip ac61c1f78f4bebf74073b4dbca356bc3aef6b44b4b069f8f2bfdb03d562e50f9 *electron-v25.9.4-mas-arm64-dsym-snapshot.zip a76831375f19b4d48766211026446f2b073247c1e1a29edb52683caa0d0fc349 *electron-v25.9.4-mas-arm64-dsym.zip 5a8a82ac24fdd31389391a157509b0a45e23d7e70236968b7b4a2130d930d04f *electron-v25.9.4-mas-arm64-symbols.zip c7e47d78ee8fc6d9112a38977cf1ebbec31cdf06b8a0540f120e7a69500c56f7 *electron-v25.9.4-mas-arm64.zip 94253d587d9ed00b1741a64ca36e32fe8bc60cc32df48675bef89af081c4f0ec *electron-v25.9.4-mas-x64-dsym-snapshot.zip bf6e83d683c7fb88e21b93d4926b1e3dc9151f94e1bb4635ae2b77992b2c6598 *electron-v25.9.4-mas-x64-dsym.zip 4b9758d4a74e21f66eedb95392d098e057e509a1f0eecc09729fa36747918838 *electron-v25.9.4-mas-x64-symbols.zip 6e26f31b8088563b2cc4d1552d9ff00e61bc7ef1b95b7cfe404564f84b5b210d *electron-v25.9.4-mas-x64.zip c6fe73f028eff3dfdd6408b8762b5e0d2a67b3bd110b5910d1bec1fa85da8a5a *electron-v25.9.4-win32-arm64-pdb.zip ccccad00e4e16048743d5252023665b74ab804a7482606dc0dc9ad01f94c988b *electron-v25.9.4-win32-arm64-symbols.zip e7b968fc53cc7a10a4ccb5133af045968479685ebb9617f06817f03667fdd425 *electron-v25.9.4-win32-arm64-toolchain-profile.zip 667c212b51400bfd1ab78a83d2adcdd6c9624a71b1a6892432e38ce9658d8093 *electron-v25.9.4-win32-arm64.zip 320dab9a57c4f0efa1ecadb4a07ec15adecaa913ef62524cacaa9f011292571f *electron-v25.9.4-win32-ia32-pdb.zip 2875e171ebba7fc12be3133cabbd38cdca30d3cedbb89a1e1e11270380b4afc5 *electron-v25.9.4-win32-ia32-symbols.zip e7b968fc53cc7a10a4ccb5133af045968479685ebb9617f06817f03667fdd425 *electron-v25.9.4-win32-ia32-toolchain-profile.zip 18b11abf7b1f2f4568c3cf5dc9a2a0fc5349b6e3f40ecb91e086b030f254510d *electron-v25.9.4-win32-ia32.zip a4b49fee1139071eb33c014ed8ac49cf83065a6d95255c44acc78c3922c56185 *electron-v25.9.4-win32-x64-pdb.zip 1712567ed6b050501a974e33a9a46cd806965d73b36ec8e18346d49022f74a8a *electron-v25.9.4-win32-x64-symbols.zip e7b968fc53cc7a10a4ccb5133af045968479685ebb9617f06817f03667fdd425 *electron-v25.9.4-win32-x64-toolchain-profile.zip 03abc9d5b2b28b440e9e5b0fc61806e3f3c2888dac5d5939957726bd68955113 *electron-v25.9.4-win32-x64.zip 706c40b11144551b2da43cdfd191c2e3e2bf0d7600b8d2751f3a806f72d0ede2 *electron.d.ts 859e7f8f6b6faf1fd004ef335ccff6f25f18c17f1aa63031e0af238899513958 *ffmpeg-v25.9.4-darwin-arm64.zip 3b63d30acb2bc5cdcc94ac2dc9e69e0919bf5038d3fd61f822c183280684cc4e *ffmpeg-v25.9.4-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.9.4-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.9.4-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.9.4-linux-x64.zip dae4d7857e7cf2d1333ce522ed3c8e3639a95432015a649a6cc3d064ddc076eb *ffmpeg-v25.9.4-mas-arm64.zip b2d9a72f57a18c68c30cbbde305ba91e740656746e37d5ce22e8895e7ec36a74 *ffmpeg-v25.9.4-mas-x64.zip 7ebbd70835b6bbd1d12e432a2b0df4fb5fccd4039c6b5125401069b1c0ff6f0e *ffmpeg-v25.9.4-win32-arm64.zip 128499e322306bf4900106d1120e28d93cafd7af5c5052109f2739360c7e212a *ffmpeg-v25.9.4-win32-ia32.zip 00a2e9d9b783899662b430feb5fb030e89ae7682ef4e3bf8eb4c8ecbfd435b84 *ffmpeg-v25.9.4-win32-x64.zip 1b9943e151314644652f738afa309d1d4f3cb18fc505e568c1f80e66e0ccf1b3 *hunspell_dictionaries.zip 631aac564c555332dbf9d7acdcce6852c594cd84d3afd3056e738c64f4b1cb1b *libcxx-objects-v25.9.4-linux-arm64.zip 4ad907d1b04bb93aba78b086ffdf16e2c0aa23f5a3901ad23ab4fd1aa46e80a3 *libcxx-objects-v25.9.4-linux-armv7l.zip c8950fb9555c33015cb0d2299dfb2b35daa1c0c7d392bf53a96f570b8c064c93 *libcxx-objects-v25.9.4-linux-x64.zip aaafbf6dfc756d3244d6085c419eec5dc3aa7b12face8a0bab1733aed3e7f3e7 *libcxx_headers.zip c571e713663bdc68f5956e45b975b89bd23cc2e401a1161321167d224b1dea3d *libcxxabi_headers.zip cf42b5f0e4e6500b89ab8313267a459584be8a175cc6c7e20c1fee50277c65f4 *mksnapshot-v25.9.4-darwin-arm64.zip 6f1b74306d691214218e2894f813af1d0fde5e6ded31ad94c1ad4f44b4582b29 *mksnapshot-v25.9.4-darwin-x64.zip 9a0e09332db556357288b46738a409269cc4c83816396c70fd5b518548eb884d *mksnapshot-v25.9.4-linux-arm64-x64.zip 80692a923553ae0172f5a981ff44d7194a307d826be5c39473f2555c1af4a025 *mksnapshot-v25.9.4-linux-armv7l-x64.zip 6dfb2d094b96f8507b4984ad8dcb14c56a8df5cd5bf89533ff6c7714009da4a0 *mksnapshot-v25.9.4-linux-x64.zip 50c800e3aa75997ec377e3d91682f9f4b49dd4e95555dd9acbbdd083d73718ac *mksnapshot-v25.9.4-mas-arm64.zip 81ea7704f3453c6d8e55525dd7e2999664e45002dab70dd250b2194b6ddccc7c *mksnapshot-v25.9.4-mas-x64.zip e817d7637498531c4de3bcbdfbd45a6255f04e349b2aa8ffdf454817f2c78b54 *mksnapshot-v25.9.4-win32-arm64-x64.zip f61be226a7c303d1b2502561de5093b0a9d364ae6d0a3b51d9c1d8b793ac97ef *mksnapshot-v25.9.4-win32-ia32.zip 73c65b7356aa3d703ca8ca43ec2436ee9c9475ce8b27b71b4313c0b3d4d76e10 *mksnapshot-v25.9.4-win32-x64.zip </ins>  No newline at end of file


Question:
Workaround This is an issue in Chromium itself. For now there are the following two workarounds: ### <blockQuote</blockQuote1. ### <blockQuote</blockQuote## Bug <!-- 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. -- <!-- 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. --1. ### VS Code Version Per: affected version is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.82.0-insider Commit | Date | 2023-08-11T17:10:45.392Z Electron | 25.4.0 ElectronBuildId | Chromium | 114.0.5735.248 | 18.15.0 V8 | 11.4.183.27-electron.0 OS | Linux x64 6.4.9-1-default </blockQuoteHowever, per: that , that is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.81.1 Commit | Date | 2023-08-09T22:18:39.991Z Electron | 22.3.18 ElectronBuildId | Chromium | 108.0.5359.215 | 16.17.1 V8 | 10.8.168.25-electron.0 OS | Linux x64 6.4.9-1-default snap ### OS Version <blockQuote</blockQuote</details## Steps to Reproduce 1. The GUI is invisible: the menubar continues to operate correctly.
82 updated to Electron 25 and doesn't work on older OS.
I'm using cpe:/o:opensuse:tumbleweed:, which updated 2600 packages yesterday (which I have installed) yet this problem remains. Nobody in their right mind would consider that to be old. Additionally, I am using which means that no independent part of the OS should be considered old. This is the most bleeding edge system for miles. Regardless, should I perhaps open a linked issue at
Oh, sorry, I thought it's an old OS issue. Before reporting in the electron repo, what is Help Toggle Developer Tools bringing up? Have you tried to do a clean reinstall of VSCode Insider? Perhaps it was just a bad build. Or, alternatively, you could try to download the latest Insider installer and install over your existing broken version (which I assume it's 3-4 days older than what you'd get right now) - that should effectively update it.
No problem. Thanks. Apologies for being curt. ! ! Appears that it's reproducible.
Very strange, indeed. I'm out of ideas. Would be interesting to be able to test with a previous Insider version, but for that you would need to have the old package and disable automatic updates. Electron was updated from 22 to 25 on August 8, so the last version with Electron 22 is the Insider from August 7, which is also the last version that I've tested and still working on Windows 7. Anything after that doesn't start anymore on Win 7. I'm not sure whether the Electron update on August 8 is causing your issue, though...
does the log file explain anything? To me, it seemed a little too verbose to be of much use. I can try other methods to get relevant diagnostic data if you are able to instruct me.
I see many GPU-related errors, such as: Errors: link failed but did not provide an info log [(48)] (checkLinkStatus): Program link or binary loading failed with no info log. [(81)] Skia shader compilation error Found these: So it's definitely something related to the new Chromium included in Electron 25 and these issues seem relatively recent. The first link recommends to disable hardware acceleration, you could try searching how to do that from command line in the new Insider. Unfortunately, I don't have the time to dig deeper right now.
per , do you know whether VSCode contains a directory? I haven't been able to locate it.
remediates the problem. Because indeed this issue is dependent upon , before this update is rolled out, there needs to be remediating measures (or the update needs to be temporarily halted) lest it break a great many peoples' installations.
Can you please take a look at this? It's Chromium/Electron 25 related, so I immediately thought of you. Please see the response just above for a possible solution. Thanks!
Thanks for investigating the issue, given there are workarounds in place this is not necessarily a release blocker. I will wait for chromium to address this issue and backport the fix to Electron 25.
could a patch at least be to the affected releases to delete the relevant directory? Surely users shall be affected otherwise? I doubt we can expect them to diagnose a known issue if the solution is so simple.
We don't want to delete the GPUCache for all users and the affected scenario described in is not possible to detect from the application layer. I think the best I can do is to add this issue to the release notes and document the workarounds for visibility.
Why?
It will have impact on startup performance, for now I would wait to see the impact of this issue across our users and decide on a fix forward. The upstream issue has also been open for a while now, signifying its low impact.
Just happened again. !
This is mentioned in the 1.82 release notes I guess the issue remains in 1.83-insiders, haven't tried it yet.
It appears weird to me that solely VSCode appears to be affected by this (on my system) because Discord has been very happily updating frequently, and obviously has its own Electron-provided directory. !
Related on Stack Overflow: Related on Reddit: ,
Got this installed via fedora yesterday This wasted quiet some time on my end, as I first went searching for changes to fedora itself and finding this issue on vscode wasn't trivial.
Leaving this here for future me, as I now have that problem on a different PC
This also happens for other Electron based programs like Element and also chromium and firefox. see
I'd disagree, . It doesn't read like pragmatism - more like "didn't want to do a good fix". Startup time after the workaround felt normal. Super aggravating that this wasn't resolved with a one-time installation task to clear the GPU cache. Hard to know the aggregate cost incurred by people encountering this issue, but "not small" is probably an underestimation. Linked-issue count wouldn't be a good proxy for that metric, in that product-support's practice as shown in seems to be linking to the known-issue buried in the release notes, not to this issue. Sorry for the flames, but there you have it. When one's coding environment gets fsck'd, it's no fun, and erodes trust. Please consider.
I, for one, find great enjoyment in my coding environments.
This issue has reemerged with the latest version 1.82.3 for Ubuntu 20.04.1: Removing after the upgrade still works to get vscode running
It occurs for me almost every update of the package. It's ridiculous.
Same.
As mentioned before, this is caused by the new update in VSCode I have personally reverted to until this issue is properly solved
I was under the impression from the chromium bug that this is one time change and not required for every startup. I see that you are using snap version of VSCode, can you check if you are required to delete the cache for every start using the instead ?
I must rectify my comment: with the snap of version v1.82.1, it was required to clear the cache every startup, with v1.82.2 I don't remember having to do it, while with v1.82.3 it was needed only once on upgrade. I will edit my previous comment to fix it.
We had a runtime version bump between to , which seems like a trigger in the snap case. Can you setup deb package, we will have release this week. It would be good to confirm if updating requires to clear the cache in the deb package as well.
For what it's worth, I haven't encountered it on the rpm again
I've tried the following: removing v1.82.3 (snap) and installing v1.82.3 (deb) did require clearing the cache. removing v1.82.3 (deb) and installing v1.82.2 (deb) did not require removing the GPUCache. upgrading v1.82.2 (deb) to v1.82.3 (deb) using apt did not require removing the GPUCache. hope it helps
I'm not using the snap any more. I use the package provided directly by Microsoft from
Encountered this problem on Fedora 39, probably after upgrading my vscode rpm which is currently on version 1.82.3. Problem disappeared after running .
Not with VSCode specifically: but when updating to electron v28 alpha, had this issue. Also solved with (or just deleting the entire Electron dir within ).
Also ran into this, thanks for this workaround, it worked.
I also ran into the issue in VSCodium (which is a special build script for this source code) after an upgrade to 1.83.1 on Debian Trixie and XFCE 4.18. The worked like a charm (which is the equivalent folder on Debian for VSCodium). I did find that I only ran into the issue on my RX 550 (Lexa) and not my Radeon RX 580 (Polaris); I found that the bug disappeared when running the program with appended to it to run it on the latter graphics card.
This has happened a second time in 1.83.1.
Got it again on fedora using the rpm on a system, where I already dropped the cache once Version 1.83.1
Just installed an update with no vscode update but had a mesa update. VSCode broke again. I assume this is going to happen every time a mesa update is installed (I'm assuming because of what others are stating, could be something other than mesa but seems to be the biggest suspect).
Getting it after every mesa update. But may be "GPUCache" need some harder refresh or detection of brockage?
This issue has been fixed upstream via . It might take a while before it trickles downstream though, since it needs to be picked up by Electron first before it can go into VSCode. I did attempt cherry-picking the commit and generating a local build and it seemed to fix the issue.
The commit is fairly trivial and can probably be safely backported to all supported Electron trees. This is a very widespread issue, affecting virtually every Electron app running on Linux. It would be great to get the fix as widely disseminated as possible considering how slow the app ecosystem is to update versions. Is there a linked Electron issue for this? Do we need to create one if not or does the Electron project accept drive-by backport PRs?
I haven't found any linked Electron issues yet. Based on , since the patch is temporary, has been committed upstream, and will eventually be removed, I think the Electron folks will accept the patch. However, do take note that the commit has dependencies on previous commits. On my working local build, I have these 3 commits cherry-picked in chronological order: Therefore, if anyone is going to bring this up to the Electron team, all 3 patches would need to be merged. Add the patch files to the and append the filenames of said patch files to the . Depending on the Electron build version, there might also be some merge conflicts. Based on my experience, those conflicts should be resolvable, but I did not test all of the older Electron major version release branches. For each branch, we would need to double-check if the 2 dependency commits are already included in their respective Chromium version or not.
Thank you for the backporting work to Electron versions 25-28 over the past few days. Downstream applications should now be able to pick those fixes up. Once VSCode picks up the fix, we should be able to close this issue.
<!-- 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!
I'll verify when the next release reaches me on openSUSE.
by chance, were you able to verify the fix for the issue yet?
the time period hasn't been quite long enough to be certain. This usually occurs on an update or after approximately two months. However, VSCode did update recently, and this didn't occur (not that it was guaranteed). Consequently, if upstream has fixed the issue, and we're using the patched version, because it hasn't appeared yet, I'll keep this completed until it occurs (and we can reasonably consider this complete).
Considering the issue as verified on 1.85.x. 1.86.0 will go out in around a week. Feel free to comment on this issue thread if the issue comes up again after that.

"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "468c4af6611c88762b7ba6c4400c5022895457c2" </del> <ins> "commitHash": "bb6a7d443b4f00680d05cc703b4d7ae180fdde03" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "25.9.2" </del> <ins> "version": "25.9.4" </ins> }, { "component": {