Question: <ins> [ { "c": "// from https://flutter.dev/", "t": "source.dart comment.line.double-slash.dart", "r": { "dark_plus": "comment: #6A9955", "light_plus": "comment: #008000", "dark_vs": "comment: #6A9955", "light_vs": "comment: #008000", "hc_black": "comment: #7CA668" } }, { "c": "import", "t": "source.dart meta.declaration.dart keyword.other.import.dart", "r": { "dark_plus": "keyword: #569CD6", "light_plus": "keyword: #0000FF", "dark_vs": "keyword: #569CD6", "light_vs": "keyword: #0000FF", "hc_black": "keyword: #569CD6" } }, { "c": " ", "t": "source.dart meta.declaration.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "'package:flutter/material.dart'", "t": "source.dart meta.declaration.dart string.interpolated.single.dart", "r": { "dark_plus": "string: #CE9178", "light_plus": "string: #A31515", "dark_vs": "string: #CE9178", "light_vs": "string: #A31515", "hc_black": "string: #CE9178" } }, { "c": ";", "t": "source.dart meta.declaration.dart punctuation.terminator.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "void", "t": "source.dart storage.type.primitive.dart", "r": { "dark_plus": "storage.type: #569CD6", "light_plus": "storage.type: #0000FF", "dark_vs": "storage.type: #569CD6", "light_vs": "storage.type: #0000FF", "hc_black": "storage.type: #569CD6" } }, { "c": " ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "main", "t": "source.dart entity.name.function.dart", "r": { "dark_plus": "entity.name.function: #DCDCAA", "light_plus": "entity.name.function: #795E26", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "entity.name.function: #DCDCAA" } }, { "c": "() ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "async", "t": "source.dart keyword.control.dart", "r": { "dark_plus": "keyword.control: #C586C0", "light_plus": "keyword.control: #AF00DB", "dark_vs": "keyword.control: #569CD6", "light_vs": "keyword.control: #0000FF", "hc_black": "keyword.control: #C586C0" } }, { "c": " {", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "  ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "runApp", "t": "source.dart entity.name.function.dart", "r": { "dark_plus": "entity.name.function: #DCDCAA", "light_plus": "entity.name.function: #795E26", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "entity.name.function: #DCDCAA" } }, { "c": "(", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "    ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "MaterialApp", "t": "source.dart support.class.dart", "r": { "dark_plus": "support.class: #4EC9B0", "light_plus": "support.class: #267F99", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "support.class: #4EC9B0" } }, { "c": "(", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "      debugShowCheckedModeBanner", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": ":", "t": "source.dart keyword.operator.ternary.dart", "r": { "dark_plus": "keyword.operator: #D4D4D4", "light_plus": "keyword.operator: #000000", "dark_vs": "keyword.operator: #D4D4D4", "light_vs": "keyword.operator: #000000", "hc_black": "keyword.operator: #D4D4D4" } }, { "c": " ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "false", "t": "source.dart constant.language.dart", "r": { "dark_plus": "constant.language: #569CD6", "light_plus": "constant.language: #0000FF", "dark_vs": "constant.language: #569CD6", "light_vs": "constant.language: #0000FF", "hc_black": "constant.language: #569CD6" } }, { "c": ",", "t": "source.dart punctuation.comma.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "      home", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": ":", "t": "source.dart keyword.operator.ternary.dart", "r": { "dark_plus": "keyword.operator: #D4D4D4", "light_plus": "keyword.operator: #000000", "dark_vs": "keyword.operator: #D4D4D4", "light_vs": "keyword.operator: #000000", "hc_black": "keyword.operator: #D4D4D4" } }, { "c": " ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "Scaffold", "t": "source.dart support.class.dart", "r": { "dark_plus": "support.class: #4EC9B0", "light_plus": "support.class: #267F99", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "support.class: #4EC9B0" } }, { "c": "(", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "        body", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": ":", "t": "source.dart keyword.operator.ternary.dart", "r": { "dark_plus": "keyword.operator: #D4D4D4", "light_plus": "keyword.operator: #000000", "dark_vs": "keyword.operator: #D4D4D4", "light_vs": "keyword.operator: #000000", "hc_black": "keyword.operator: #D4D4D4" } }, { "c": " ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "MyApp", "t": "source.dart support.class.dart", "r": { "dark_plus": "support.class: #4EC9B0", "light_plus": "support.class: #267F99", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "support.class: #4EC9B0" } }, { "c": "()", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": ",", "t": "source.dart punctuation.comma.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "      )", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": ",", "t": "source.dart punctuation.comma.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "    )", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": ",", "t": "source.dart punctuation.comma.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "  )", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": ";", "t": "source.dart punctuation.terminator.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "}", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "class", "t": "source.dart keyword.declaration.dart", "r": { "dark_plus": "keyword: #569CD6", "light_plus": "keyword: #0000FF", "dark_vs": "keyword: #569CD6", "light_vs": "keyword: #0000FF", "hc_black": "keyword: #569CD6" } }, { "c": " ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "MyApp", "t": "source.dart support.class.dart", "r": { "dark_plus": "support.class: #4EC9B0", "light_plus": "support.class: #267F99", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "support.class: #4EC9B0" } }, { "c": " ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "extends", "t": "source.dart keyword.declaration.dart", "r": { "dark_plus": "keyword: #569CD6", "light_plus": "keyword: #0000FF", "dark_vs": "keyword: #569CD6", "light_vs": "keyword: #0000FF", "hc_black": "keyword: #569CD6" } }, { "c": " ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "StatefulWidget", "t": "source.dart support.class.dart", "r": { "dark_plus": "support.class: #4EC9B0", "light_plus": "support.class: #267F99", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "support.class: #4EC9B0" } }, { "c": " {", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "  ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "@override", "t": "source.dart storage.type.annotation.dart", "r": { "dark_plus": "storage.type: #569CD6", "light_plus": "storage.type: #0000FF", "dark_vs": "storage.type: #569CD6", "light_vs": "storage.type: #0000FF", "hc_black": "storage.type: #569CD6" } }, { "c": "  ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "_MyAppState", "t": "source.dart support.class.dart", "r": { "dark_plus": "support.class: #4EC9B0", "light_plus": "support.class: #267F99", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "support.class: #4EC9B0" } }, { "c": " ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "createState", "t": "source.dart entity.name.function.dart", "r": { "dark_plus": "entity.name.function: #DCDCAA", "light_plus": "entity.name.function: #795E26", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "entity.name.function: #DCDCAA" } }, { "c": "() ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "=>", "t": "source.dart keyword.operator.closure.dart", "r": { "dark_plus": "keyword.operator: #D4D4D4", "light_plus": "keyword.operator: #000000", "dark_vs": "keyword.operator: #D4D4D4", "light_vs": "keyword.operator: #000000", "hc_black": "keyword.operator: #D4D4D4" } }, { "c": " ", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "_MyAppState", "t": "source.dart support.class.dart", "r": { "dark_plus": "support.class: #4EC9B0", "light_plus": "support.class: #267F99", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "support.class: #4EC9B0" } }, { "c": "()", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": ";", "t": "source.dart punctuation.terminator.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } }, { "c": "}", "t": "source.dart", "r": { "dark_plus": "default: #D4D4D4", "light_plus": "default: #000000", "dark_vs": "default: #D4D4D4", "light_vs": "default: #000000", "hc_black": "default: #FFFFFF" } } ] </ins>  No newline at end of file

An easy way to test it's working is to disable the Dart/Flutter extensions (accept the prompt to reload), then open a Dart file. You'll now still get syntax highlighting (note: you won't get analysis or much other editor functionality, that requires the Dart extension). <img width="650" alt="Screenshot 2021-06-14 at 15 52 25" src="https://user-"
Yeah I just did, and it works great :-)


Question: } public get lineNumbers(): number[] { return this._lineNumbers; }

VSCode Version: Code 1.7.2 (, 2016-11-21T22:14:18.217Z) OS Version: Linux x64 4.8.0-26-generic Focus on debug: ! Focus on extensions: ! Can the bright one be on debug as well?
For me all viewlets show the same feedback once focussed: ! Please clarify the issue you see.
Oh I mean via tab focus.
! still they all look the same to me?
I see what you mean, when you focus into the current active viewlet, the orange bar to the left shows up stronger. I am not sure who this, I think might be the one?
This issue has been closed automatically because it needs more information and has not had recent activity. Please refer to our for filing issues. Thank you for your contributions.
Closing as designed, no plans to change it currently.


Question: this.editor.updateOptions({ padding: { top: defaultCodeblockPadding, bottom: bottomPadding } }); } <ins> private _configureForScreenReader(): void { const toolbarElt = this.toolbar.getElement(); if (this._accessibilityService.isScreenReaderOptimized()) { toolbarElt.style.display = 'block'; toolbarElt.ariaLabel = this._configurationService.getValue(AccessibilityVerbositySettingId.Chat) ? localize('chat.codeBlock.toolbarVerbose', 'Toolbar for code block which can be reached via tab') : localize('chat.codeBlock.toolbar', 'Code block toolbar'); } else { toolbarElt.style.display = ''; } } </ins> private getEditorOptionsFromConfig(): IEditorOptions { return { wordWrap: this.options.configuration.resultEditor.wordWrap,

We should not translate the PHP parser error messages, but we should localize the strings that appear in the Code UI. !


Question: "less.lint.emptyRules.desc": "Do not use empty rulesets.", "less.lint.float.desc": "Avoid using `float`. Floats lead to fragile CSS that is easy to break if one aspect of the layout changes.", "less.lint.fontFaceProperties.desc": "`@font-face` rule must define `src` and `font-family` properties.", <del> "less.lint.hexColorLength.desc": "Hex colors must consist of three or six hex numbers.", </del> <ins> "less.lint.hexColorLength.desc": "Hex colors must consist of 3, 4, 6 or 8 hex numbers.", </ins> "less.lint.idSelector.desc": "Selectors should not contain IDs because these rules are too tightly coupled with the HTML.", "less.lint.ieHack.desc": "IE hacks are only necessary when supporting IE7 and older.", "less.lint.important.desc": "Avoid using `!important`. It is an indication that the specificity of the entire CSS has gotten out of control and needs to be refactored.",

<!-- 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.86.2 (system setup) OS Version: Windows 11 (Windows_NT x64 10.0.) Steps to Reproduce: the built-in extension "CSS Language Features", which has an identifier of settings, search for "hex color length" See that it says "Hex colors must consist of three or six hex numbers." when it should say "Hex colors must consist of three, four, six, or eight hex numbers." to accommodate the alpha channel. The extension already allows for all four lengths, but the setting description is wrong.


Question: disturl "https://electronjs.org/headers" <del> target "19.1.8" </del> <ins> target "19.1.9" </ins> runtime "electron" build_from_source "true"

Type: <bBug</bwhen I do a ctrl-f and run search replace. When I put in a & to search for and a & with a new line it crashes visual studio code and once and a while my whole os VS Code version: Code 1.74.0 (, 2022-12-05T16:47:18.476Z) OS version: Linux x64 6.0.6--generic Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (41)</summaryExtensionVersion ------ language-x86-64-assembly3.0.0 vscode-intelephense-client1.8.2 compare-view0.10.0 vscode-eslint2.2.6 prettier-vscode9.10.3 theme-editor1.9.0 vscode-docker1.23.2 isort2022.8.0 python2022.20.1 vscode-pylance2022.12.20 jupyter2022.11.


Question: disturl "https://electronjs.org/headers" <del> target "19.1.8" </del> <ins> target "19.1.9" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.1.8" </del> <ins> target "19.1.9" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.1.8" </del> <ins> target "19.1.9" </ins> runtime "electron" build_from_source "true"

<!-- 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: disturl "https://electronjs.org/headers" <del> target "19.1.8" </del> <ins> target "19.1.9" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.1.8" </del> <ins> target "19.1.9" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.1.8" </del> <ins> target "19.1.9" </ins> runtime "electron" build_from_source "true"

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: disturl "https://electronjs.org/headers" <del> target "19.1.8" </del> <ins> target "19.1.9" </ins> runtime "electron" build_from_source "true"

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: } } <del> private async getWebiewContents(): Promise<string> { </del> <ins> private async getWebviewContents(): Promise<string> { </ins> const version = Date.now().toString(); const settings = { isMac: process.platform === 'darwin',

Issue Type: <bBug</bIf I try to open an image with a name such as 'test-' it says 'An error occurred while loading the image'. In the developer console, the following error is shown: VS Code version: Code 1.44.2 (, 2020-04-16T17:07:18.473Z) OS version: Darwin x64 19.4.0 <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
Looks like the problem is on the , line 22 We got , which is a string looks like it is correct. Next, when we do it becomes an object and the paths are not correct here. Going down into the () i found that the string is being processed inside the by the This piece of code takes the string, and tries to decode any part started from %, thats why %41 becomes A
I don't think the decoding process is faulty, but the encoding part. Every browser will interpret as . ! So the url should escape in the first place. !
You're right. The percent ("%") character is missed in the encodeTable, and in the encodeURIComponentMinimal() 562 line.


Question: logMessage: l.logMessage } ); <del> this.debugService.addBreakpoints(uri.revive(dto.uri), rawbps); </del> <ins> this.debugService.addBreakpoints(uri.revive(dto.uri), rawbps, 'extension'); </ins> } else if (dto.type === 'function') { this.debugService.addFunctionBreakpoint(dto.functionName, dto.id); }

When going over our telemetry for debug actions we have the ability to track usage counts of debug actions triggered from keyboard shortcuts and commands, as they execute commands which we emit telemetry for, but we don't seem to have telemetry in place for breakpoints set in the gutter (click or context menu). This is unfortunate as my hypothesis is that the majority of breakpoints are set this way. Ask Add ability to track breakpoint toggles (add/remove/change) from Gutter click Add ability to track breakpoint toggles from gutter context menu
would you like to contribute a PR for this? It shuold be fairly simple and you already have the nice code pointers.
I'd be happy too, but we should land on an agreement on how to implement it. What's the best approach? 1) Add telemetry directly to the gutter actions 2) Re-wire the gutter actions to execute a command instead?
for the best approach let's first see what you want to get exactly? total amount of all breakpoints set (including the gutter) grained events for breakpoint setting based on the way the user initated that aciton In case of 1 we should just add a telemetry ping in the  since everyone should go through there In case of 2 depends on how fine grained you want it, if for every place then we should add an argument or something like that in the addBreakpoints method and then also report that to telemetry.
I'd like us to be able to contribute a source/initiator to given breakpoint, so we can get an UI usage distributions, etc.
I suggest the following Add a third argument In the implementation of that method use the telemetry service to report the appropriate event with the context. And you should nicely get all the errors of all the callers of , simply pass different string context for each caller and you shuold be good to go. Let me know if you have any questions
Cool, I'l see what I can get cooking!
Removing my assignment for this. feel free to assign me back if you do not have time to tackle this and if we need this for August
hey, would you still like this? If yes I can also look into it in October
I'd still like to do this to get my hands dirty.
cool, unasigning myself and let's leave it for October
Verified by code review, adding verified label


Question: currentHistoryItemRemoteRef?: ISCMHistoryItemRef, currentHistoryItemBaseRef?: ISCMHistoryItemRef ): number { <del> const getHistoryItemRefPriority = (ref: ISCMHistoryItemRef) => { </del> <ins> const getHistoryItemRefOrder = (ref: ISCMHistoryItemRef) => { </ins> if (ref.id === currentHistoryItemRef?.id) { return 1; } else if (ref.id === currentHistoryItemRemoteRef?.id) {

Testing I wonder how well it scales to show multiple tag icons, why not find a new icon that resembles multiple tags: !
I like that. Adding as that would require a new Codicon...
!
Or just show one tag in the row, but show all of them on hover like you do now.
How about showing one badge pert type (ex: branch, remote branch, tag) and a number indicating how many they are. That way there is no need create new icons that would cause further confusion.
I am actually not entirely sure what value there is to distinguish 1 tag from N tags? I would just show 1 icon if there is any tag.
Seems reasonable. Let's start with that and see how things go.


Question: } public unhide() { <del> this.element.style.visibility = 'visible'; </del> <ins> this.element.style.visibility = ''; </ins> this.updateMarkupDimensions(); }

Collapse an output, it is not hidden in the webview <img width="596" alt="image" src="https://user-"
maybe ?


Question: import { ICommentThreadChangedEvent } from 'vs/workbench/contrib/comments/common/commentModel'; import { CommentMenus } from 'vs/workbench/contrib/comments/browser/commentMenus'; import { ICellRange } from 'vs/workbench/contrib/notebook/common/notebookRange'; <ins> import { IWorkbenchLayoutService } from 'vs/workbench/services/layout/browser/layoutService'; </ins> export const ICommentService = createDecorator<ICommentService>('commentService');

Issue Type: <bBug</bI am not sure if this was something I accidentally enabled, but it looks like it appeared with the latest VSCode version. Hovering over lines now shows a + symbol in the gutter, and it's highly distracting. Is this a bug, or can it be disabled? VS Code version: Code 1.67.0 (, 2022-05-04T12:06:02.889Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ vsc-material-theme33.2.0 vsc-material-theme-icons1.2.2 prettier-vscode9.5.0 copilot1.19.5865 gc-excelviewer4.2.54 vsliveshare1.0.5561 material-theme3.13.25 (5 theme extensions excluded) </details<!-- generated by issue reporter --
https://user-
The "+" on line hover indicates that you can leave an extension comment on that line. We used to only show the "+" when you hovered over the gutter itself, but now we show it over the whole line so that it's easier to find. This means that you have an extension installed that let's you leave comments in files. The extension might have a way for you to disable this. I would like to add a feature to VS Code that just disables all commenting. Assigning to June to work on this.
great to know, thank you. i'll see if I can figure out what the extension is and will disable it in the meantime. it's very distracting - can you consider an option that preserves the old symbol behavior where it is only displayed when hovering in the gutter? comments are useful but there is now too much distracting movement on screen. it also shows in Zen mode which I believe is counter productive.
Good point, this should be disabled in Zen mode.
Bit more thoughts on this: Maybe a setting wouldn't be the right fit for this, since a user might forget that it set it and forget about it... or worse, it could be set at workspace level and the user never even knew it was set. Maybe runtime UI state would work best since it isn't as sticky.


Question: import { ICommentThreadChangedEvent } from 'vs/workbench/contrib/comments/common/commentModel'; import { CommentMenus } from 'vs/workbench/contrib/comments/browser/commentMenus'; import { ICellRange } from 'vs/workbench/contrib/notebook/common/notebookRange'; <ins> import { IWorkbenchLayoutService } from 'vs/workbench/services/layout/browser/layoutService'; </ins> export const ICommentService = createDecorator<ICommentService>('commentService');

Additionally, it would be great if there is some indication that comments are indeed hidden as opposed to the current file not having any comments at all. What do you think?
Having some indication that there are comments, they're just hidden, makes sense. We should do this. We can start with some runtime UI state and add a setting later if there's a desire for it.


Question: } } <del> private _getPicksFromMatches(matches: FileMatch[], limit: number): (IQuickPickSeparator | ITextSearchQuickAccessItem)[] { </del> <ins> private _getPicksFromMatches(matches: FileMatch[], limit: number): (IPickerQuickAccessSeparator | ITextSearchQuickAccessItem)[] { </ins> matches = matches.sort(searchComparer); const files = matches.length > limit ? matches.slice(0, limit) : matches; <del> const picks: Array<ITextSearchQuickAccessItem | IQuickPickSeparator> = []; </del> <ins> const picks: Array<ITextSearchQuickAccessItem | IPickerQuickAccessSeparator> = []; </ins> for (let fileIndex = 0; fileIndex < matches.length; fileIndex++) { if (fileIndex === limit) {

! quick search. over a file name pick item and click the button to open the file. happens :bug:


Question: // --- from extension host process $tryShowTextDocument(resource: URI, options: ITextDocumentShowOptions): TPromise<string> { <del> const editorOptions: IEditorOptions = { </del> <ins> const editorOptions: ITextEditorOptions = { </ins> preserveFocus: options.preserveFocus, <del> pinned: options.pinned </del> <ins> pinned: options.pinned, selection: options.selection </ins> }; const input = {

For
Verify: write an extension that exercises the following APIs by passing in a selection as option and verify the selection is revealed and showing up in the opened editor: command API Provide a property of type to get it. !


Question: this._labelElement = document.createElement('div'); this._labelElement.classList.add('monaco-button-label'); <del> this._labelElement.tabIndex = -1; </del> this._element.appendChild(this._labelElement); this._descriptionElement = document.createElement('div'); this._descriptionElement.classList.add('monaco-button-description'); <del> this._descriptionElement.tabIndex = -1; </del> this._element.appendChild(this._descriptionElement); }

down in the button, then move outside the button and mouse up You get this border: ! Weirdly enough that's not the same border you get when tabbing onto the button: !
Weird, by performing this gesture you get to focus the inside the button itself. Will see what the best fix is.
It's a bug in the as it does not happen with the "Publish Branch" or "Commit" buttons.


Question: <key>list_paragraph</key> <dict> <key>begin</key> <del> <string>(^|G)(?=S)(?![*+-]s|[0-9]+.s)</string> </del> <ins> <string>(^|G)(?=S)(?![*+->]s|[0-9]+.s)</string> </ins> <key>name</key> <string>meta.paragraph.markdown</string> <key>patterns</key>

VSCode Version: Code 1.18.0 (, 2017-11-08T21:19:36.079Z) OS Version: Windows_NT ia32 6.1.7601 Lists shift the indentation by the level of depth in the list hierarchy. This is just a very minor thing, but the is no longer syntax highlighted when a quote is part of a list item and thus indented. ! Steps to Reproduce: markdown file. a list. a quote to one of the items by indenting the quote. Reproduces without extensions: Yes


Question: resetStateMachine:boolean, hasOpenParens:boolean, hasOpenSquareBracket:boolean, <del> hasOpenCurlyBracket:boolean; </del> <ins> hasOpenCurlyBracket:boolean, characterClassifier:CharacterClassifier = new CharacterClassifier(); </ins> for (i = 1, lineCount = model.getLineCount(); i <= lineCount; i++) { line = model.getLineContent(i);

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: const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

Issue Type: <bBug</bLike what the heading says, inserting a code snippet anywhere in the code file causes an autoscroll. This is a slight inconvenience, as while inserting snippets, viewing code above it is desirable, causing us to rescroll into view. So adding an option to revert to the functionality in the stable release would be preferred VS Code version: Code - Insiders 1.46.0-insider (, 2020-05-07T16:36:39.681Z) OS version: Linux x64 5.4.38-1-MANJARO <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ cpptools0.27.1 Go0.14.1 material-icon-theme4.1.0 material-theme3.5.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
Yeah - that's a regression from a recent change to keep the position stable when additional edits are inserted...
is the item that caused this regression.
fixed via
Yep, it works fine now. Thanks a lot!
This bug has been fixed in to 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 pallette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


Question: const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

This is somewhat the opposite of and the acknowledgement that computing additional text edits for all items upfront is too demanding. This issue is only about and the goal is a pragmatic solution, similar to the one that we have for . Idea accept an unresolved completion proceed with insertion as usual set up a content change listener resolve the items once resolved check if additional edits overlap with "concurrent" changes. when they overlap, do nothing otherwise proceed
The first version for this is now merged to master, it's a pragmatic approach that's better then not resolving but worst than (costly) upfront resolving. Items to followup on [ ] telemetry and follow up issues [ ] - TS issue for having incomplete items [ ] [ ] java for returning very few (resolved) completions, e.g doing the right thing
/cc - My understanding is that Java resolves all items upfront, e.g compute additional text edits during "provide", and that it is quite expensive and therefore Java only returns a small amount of items. Is that correct? Could Java return results faster when additional text edits are computed during resolve (and therefore only for selected items)?
Yes. I think so! is the dev who was working on Java completion. I believe he can provide more insights toward this topic. // cc
this is exactly the behavior that used to have, ie compute all the completion items first (fast), then the text edits were computed during resolveCompletion. We were asked to not do that as and changed to return a small subset of completion items (with incomplete=true), with full text edits computed upfront. The user experience is definitely not as good as with our initial implementation.
To be clear, computing any Java textedit upfront is costly when returning 100+ items (and we can return several thousands items). We'd prefer if the async insertion of textedits covered all textedits, not just the additional ones.
The requirements discussed in are still true and there are no plans to change that. There is (which might be derived from ) and . The former () is inserted at the cursor and must be inserted synchronous to accepting a completion (we cannot block typing while waiting for that). The latter () is meant for things like import-statements and we now want to relax that, e.g it can come late and we try to apply those edits despite the user having typed more.


Question: const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

When exactly does run, is it only when an item gets highlighted in the menu? Can't tell from the docs. I only need to generate for the completion item the user ends up applying -- doing it for other items is unnecessary work that's bogging down the extension host, and I will have to implement yielding. I assume no one would need to generate before a completion item is applied? Is there any kind of completion applied event we can hook into to work around this for the time being?
That's exactly what is about . Today, there is no guarantee that is ever called because its original design is to provide data for the suggest details widget. However, we see that (amongst other things) are computed during resolve and leads to subtle bugs (because don't always call resolve or always await it) Well, is the problem if you do not generate them upfront. select suggestion synchronously inserts the string starts for additional text edits continues to type quickly and all over the place -call eventually returns but it is unclear if the edits are still valid because the state changed many types in-between Solutions: Won't work because in JS you cannot wait for another "thread" or "process", the world always keeps turning Implement a full -solution because this is two entities "typing" concurrently in the same document. However, it will feel awkward because the user doesn't expect to be such a scenario. approach that tries to apply additional edits if possible but inserts the "main edit" (insertText) always synchronously. () "if possible" is currently defined as "no edit has occurred before the first additional edit". That works well if you use additional edits for things like imports or prefixes (which is the indented use-case) but won't work if additional text edits change the main edit, like appending a call-operators with arguments etc
I mean JS can't block but ignoring typing while awaiting is possible -- I was imagining that VSCode would keep the completions menu open and ignore any typing until is resolved and all text edits applied for the accepted item. Obviously this would be bad if resolving takes a long time, but the API has cancelation tokens already, so the UI would just need to show a spinner/cancel icon, and also cancel if the user presses ESC or navigates to a different editor, for a decent UX.


Question: const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

I think this would be less confusing for users too; it's the only way it would be clear when VSCode is completely done applying the completion. I think many users would be confused if imports usually get but not when they resume typing too soon. FWIW I can syncronously generate the additional text edits I need, so I'd be happy if there were an API to synchronously generate them when the completion item is accepted. I know not everyone would be able to generate them sync though.
Also I know my questions may have seemed redundant, but I hadn't seen anyone on this thread point out that it would be ideal to avoid ever computing additional text edits (or even the primary insert text) for unselected completions. Since can get called before any item is accepted (I assume, since it seems to be for showing additional details in the menu), I'd think any solution via could still result in unnecessarily generating additional edits that are ultimately discarded.
The golden rule is that "you can always type inside the editor". Ignoring typing is not a good solution and will bug users. Just think of quick suggest and auto accept characters - you don't want the editor to stop typing just because an extension is taking a little longer (+50ms). To be precise you should have written "typing at or before the offset at which additional edits are going to happen" I honestly think the majority can generate them synchronously but this happens in the extension host process or the language server process, and all of that might happen on a different machine and there is no way to synchronously transport that into the UI.
re with the current changes you should be able to have a "simple insert text", say , and compute an additional text edit, like , that goes in front of it so that you eventually have . Right? Or am I missing something?
that might actually be a good idea ;-) In practice though, we might need to revisit the way the principal TextEdit is computed (i.e rewrite a bunch of stuff from upstream JDT)
I get the desire to be able to always be able to type inside the editor and agree that's an important principle. The only reason I think this case is an exception is that: The user would probably want to wait for all edits to get applied anyway.


Question: const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

Seems unlikely that people would want to get the main edit without the additional edits By making the operation cancelable, you can still go back to typing immediately if you so desire. I certainly wouldn't want to block the user from typing without recourse (as you know, I feel frustrated that happens currently when using Vim extensions) On the other hand, I guess it's unlikely that the additional text edits would overlap whatever the user continues typing...
I hadn't thought about auto accept characters though, that's a good point. That's something I don't have experience with. Also considering that VSCode could pop up a warning if it has to bail on inserting additional edits, it's not a big deal if it ever happens
I remember that we have some new data points regarding the time consumption in different stages of code completion in Can you share that data and see how we can tune it with this change?
For Java language server, below is a sample of call tree when triggering completion. (time value is larger than expected because of extra overhead from JProfiler) ! Total time of completion stage mainly consists of three parts: competion candidates in JDT to CompletionItems (calc textEdits, additionalTextEdits, etc.) --- calc an incomplete list of only 50 items by default (the full list can contain thousands) --- here calculating import statements costs a lot of time server-side code snippets (not much related to this topic) I did a simple experiment on java language server, with vscode-insider built on 2020-5-15. I was using spring-petclinic, which is not a big one, but with some dependencies. Type a initial letter, e.g. "O", and observe perf of completion and resolve. Do multiple times for statistics. Calculating additionalTextEdits async in resolve stage does decrease the time cost a lot. textEdits and additionalTextEdits are calculated during completion stage. completion: ~150 ms resolve(avg of top 10 items): ~10 ms Now I simply move a bunch of textedit calculation from "completion" stage into "resolve" stage. completion: ~100 ms resolve(avg of top 10 items): ~17 ms !
I just realized that can return a thenable, but I assume that would delay the appearance of the entire menu?
Closing as we haven't seen issues with the new pragmatic approach and the plan is to stick with it.


Question: const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

so how do servers know that clients support lazy-loading of additional textedits? Surely this should be a client capability advertised by vscode (that needs to be specced in the LSP)
is the right person for that and you should probably create a follow up issue in the LSP land
corresponding LSP feature request created here please add more details if I miss anything.
Thanks
To verify: use TypeScript have a suggestion that will import a symbol make sure that suggestion isn't first or focused in the UI use the mouse(!) to select the suggestion make sure the import is there make sure undo, redo works as expected


Question: pick: async () => { // Do a late 'onDebugDynamicConfigurationsName' activation so extensions are not activated too early #108578 await this.adapterManager.activateDebuggers(onDebugDynamicConfigurationsName, type); <del> const disposables = new DisposableStore(); const input = disposables.add(this.quickInputService.createQuickPick<IDynamicPickItem>()); input.busy = true; input.placeholder = nls.localize('selectConfiguration', "Select Launch Configuration"); input.show(); const chosenPromise = new Promise<IDynamicPickItem | undefined>(resolve => { disposables.add(input.onDidAccept(() => resolve(input.activeItems[0]))); disposables.add(input.onDidTriggerItemButton(async (context) => { resolve(undefined); const { launch, config } = context.item; await launch.openConfigFile({ preserveFocus: false, type: config.type, suppressInitialConfigs: true }); // Only Launch have a pin trigger button await (launch as Launch).writeConfiguration(config); await this.selectConfiguration(launch, config.name); this.removeRecentDynamicConfigurations(config.name, config.type); })); }); </del> const token = new CancellationTokenSource(); const picks: Promise<IDynamicPickItem[]>[] = [];

Type: <bBug</bHow to reproduce the issue: and Run the Extension the , and then the pane. Use the dropdown and select the Dynamic Configuration Provider . With the checked out branch, it will show the quick pick options for Option 1 - 3, but will not show a quick pick for the resolved configurations. This seems to work for , but not Expected: ! Actual: ! VS Code version: Code 1.77.3 (, 2023-04-12T09:16:02.548Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No <details<summarySystem Info</summary </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.78.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I've updated to: and it still reproduces.
for prioritization help as per email thread
Sent a PR for this. But what is the inner quickpick? I'm a little unsure about the approach, I don't think we expect a provider to include some UI. Your extension doesn't own the UI in this flow- you are just implementing a provider method which will be invoked at different times, expected to return a list of configs. It might make sense in one situation to show the quick pick, but we could make changes in vscode to call your provider at a different time where it would be unexpected to have a quick pick pop up. And, any extension can implement a config provider for your debug type. So for example, multiple extensions could all be showing their own UI in this scenario. However, from memory, I think the Python debug extension might already have a similar multi-step picker UI for a scenario like this.


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

Found this stack while scanning through some failing smoke test runs From Deepak:
What are some verification steps for this issue?
I did check logs last week and could no longer find this.


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

I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?


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

Type: <bBug</bIn the most recent insiders version, audio cues no longer play. I ensured that the audio cues I expect are enabled (e.g. error) and entered the following json as an example: I ensured that the error was reported when moving through errors with f8, yet the cue doesn't play when I come across the line with up/down arrow keys VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-05T07:36:58.753Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
cc
We didn't touch anything there the last months, maybe it is caused by an electron update. Will investigate for the next release.
I can reproduce this. Easy repros steps: 1 list audio cues command cues do not produce sound Works fine on latest stable. Does not work on Insiders. fyi since most likely caused by Electron update (thus adding label). Maybe our future planned ffmpeg change will fix this? thanks a lot for reporting this, and sorry about this breakage.
You're welcome, I'm running insiders for a reason Looking forward to a fix.
Let me also assign since we will now support would you like that all our audio cues are in format? If yes, would you like me to reach out to our sound designer for this? Thanks
can you track the conversion in a separate issue, this particular issue is a regression with the ffmpeg build shipped with internal builds. There was a recent build architecture change and it impacted this. I would like to close this issue as part of the next Electron version update :)
makes sense, thanks! There is actually already this one which we can use for the conversion
The same problem using code-insiders into a fedora workstation 36.
It is working again with orca.
lovely, thanks for confirming. Adding verified label.
For me it also works like a charm on Windows.
For some reason I can't explain, this issue seems to have returned on my fedora workstation. No sound is played when I move the cursor to lines that contain breakpoints, errors and etc. Version: 1.71.0-insider Commit:
Confirmed on Windows. Could tests for this be somehow?


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

Sorry for the regression, but this is a temporary expected breakage because we are updating our supported audio formats , audio cues will be updated to new format this iteration as part of /cc
Sorry about that We just pushed a fix, and the VS Code insiders from tomorrow will have the fix.
Thanks Given this feature turns out to be pretty important for us visually impaired users, would it be possible to create a system test for this? I assume it should be possible to throw a audio cue at FFMPEG and make it fail if the sound doesn't play?
that's a good idea. However I leave this up to since he is driving this from engineering and would have better ideas how we could test it exactly.
We would need a way to ask the OS if an application played some sound.
It works again, at least on my environment. Thanks.
awesome, thanks for letting us know.
I can confirm that it works here as well. Hopefully it stays that way


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

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR.


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

I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at .


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

I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up!


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

I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


Question: || installedExtension.preRelease !== e.preRelease // Install if the extension pre-release preference has changed ) { if (await this.extensionManagementService.canInstall(extension)) { <del> this.logService.trace(`${syncResourceLogLabel}: Installing extension...`, e.identifier.id, extension.version); await this.extensionManagementService.installFromGallery(extension, { isMachineScoped: false, donotIncludePackAndDependencies: true, installPreReleaseVersion: e.preRelease, profileLocation: profile.extensionsResource } /* set isMachineScoped value to prevent install and sync dialog in web */); this.logService.info(`${syncResourceLogLabel}: Installed extension.`, e.identifier.id, extension.version); removeFromSkipped.push(extension.identifier); </del> <ins> extensionsToInstall.push([e, extension]); </ins> } else { this.logService.info(`${syncResourceLogLabel}: Skipped synchronizing extension because it cannot be installed.`, extension.displayName || extension.identifier.id); addToSkipped.push(e);

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: } const cell = new MarkupCell(init.cellId, init.mime, init.content, top, init.metadata); <del> cell.element.style.visibility = visible ? 'visible' : 'hidden'; </del> <ins> cell.element.style.visibility = visible ? '' : 'hidden'; </ins> this._markupCells.set(init.cellId, cell); await cell.ready;

Collapse an output, it is not hidden in the webview <img width="596" alt="image" src="https://user-"
maybe ?


Question: dispose: () => combinedDisposable(disposables).dispose() }; <del> const cacheKey = descriptor.resource.toString(); </del> <ins> const cacheKey = `${descriptor.resource.toString()}:${descriptor.etag}`; </ins> let ctrlPressed = false; let altPressed = false;

Issue Type: <bBug</bIn VSC, load a small image, zoom in a lot, close the image. Resize the small image by 10 times. In VSC, load the resized image. VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ Bookmarks10.4.3 npm-intellisense1.3.0 vscode-eslint1.8.2 githistory0.4.6 EditorConfig0.13.0 rainbow-csv1.0.0 dotenv1.0.1 vscode-typescript-tslint-plugin1.0.0 vetur0.19.2 github-actions-vscode2.6.1 rust0.6.1 RustyCode0.19.1 vscode-hexdump1.7.2 sort-lines1.8.0 markdown-all-in-one2.3.1 (1 theme extensions excluded) </details<!-- generated by issue reporter --
I would like to take this. I think we can store more information in . In my opinion, we can add the size or add the SHA1 value of the image? Do you have any suggestions?
can i work on this?
i didn't know that already started working on this, both prs work. as far as mine considered, i'm resetting scale to 1.
I'm sorry that I didn't reply to you immediately. Do you reset the scale every time you close the image? It makes the editor cannot remember the scale and offset even the image isn't modified.
yes you are write. let me close mine. :+1:


Question: import { filter } from 'vs/base/common/objects'; import { assertType } from 'vs/base/common/types'; import { URI } from 'vs/base/common/uri'; <del> import { localize } from 'vs/nls'; </del> import { IRevertOptions, ISaveOptions, IUntypedEditorInput } from 'vs/workbench/common/editor'; import { EditorModel } from 'vs/workbench/common/editor/editorModel'; import { NotebookTextModel } from 'vs/workbench/contrib/notebook/common/model/notebookTextModel'; import { ICellDto2, INotebookEditorModel, INotebookLoadOptions, IResolvedNotebookEditorModel, NotebookCellsChangeType, NotebookData } from 'vs/workbench/contrib/notebook/common/notebookCommon'; import { INotebookSerializer, INotebookService, SimpleNotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookService'; <del> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; </del> import { IFilesConfigurationService } from 'vs/workbench/services/filesConfiguration/common/filesConfigurationService'; import { ILifecycleService } from 'vs/workbench/services/lifecycle/common/lifecycle'; import { IFileWorkingCopyManager } from 'vs/workbench/services/workingCopy/common/fileWorkingCopyManager';

Testing a new notebook and make an edit profiles to restart the EH the file when prompted and provide a file name: The untitled-n.ipynb tab remains open, rather than opening , :bug: The file is no longer marked dirty, even with futher edits and can be closed without prompting to save
can you maybe check from the notebook side?
Luna paint behaves similarly with one extra step: a new image and make an edit profiles to restart the EH the file when prompted and provide a file name: The untitled-n.ipynb tab remains open, rather than opening , (different) and the switch profile operation is blocked switch profiles again The file is no longer marked dirty, even with futher edits and can be closed without prompting to save
Somehow today I cannot reproduce an issue with insiders: ! Please give me more detailed steps and see if you still find this.
still seeing it. Did you try making edits after switching? that's when the dirty indicator doesn't show up anymore. ! I saved as a different filename in the gif, but keeping the untitled filename still doesn't show a dirty indicator, nor does it auto-save.
This seems to me like something notebooks need to handle better: if you enter an extension host that does not have the notebook extension and you make edits, the editor should probably not allow that. I.e. the editor should maybe turn readonly once the extension is disabled or not present.
- the notebook extension is built-in so it's still available in an empty profile. The repro steps can even start with an empty profile -and make an edit to the first cell profile to default and save as 1.ipynb when prompted an edit in the notebook :bug: file is not dirty
oh nice, sounds like an issue related to EH restart then, will update the title With your working copy knowledge you might be even able to figure this out ;)
It looks like the issue in the notebook scenario is that it's calling save directly on the workingCopy in the : In the untitled case, that will delegate to saveAs, which will dispose the untitled workingcopy without opening a new editor with the resulting . The editor is left open with its underlying WorkingCopy disposed. For non-built-in custom editors though, it seems like we should just close them if we don't know if they will be supported in the new profile.


Question: import { filter } from 'vs/base/common/objects'; import { assertType } from 'vs/base/common/types'; import { URI } from 'vs/base/common/uri'; <del> import { localize } from 'vs/nls'; </del> import { IRevertOptions, ISaveOptions, IUntypedEditorInput } from 'vs/workbench/common/editor'; import { EditorModel } from 'vs/workbench/common/editor/editorModel'; import { NotebookTextModel } from 'vs/workbench/contrib/notebook/common/model/notebookTextModel'; import { ICellDto2, INotebookEditorModel, INotebookLoadOptions, IResolvedNotebookEditorModel, NotebookCellsChangeType, NotebookData } from 'vs/workbench/contrib/notebook/common/notebookCommon'; import { INotebookSerializer, INotebookService, SimpleNotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookService'; <del> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; </del> import { IFilesConfigurationService } from 'vs/workbench/services/filesConfiguration/common/filesConfigurationService'; import { ILifecycleService } from 'vs/workbench/services/lifecycle/common/lifecycle'; import { IFileWorkingCopyManager } from 'vs/workbench/services/workingCopy/common/fileWorkingCopyManager';

I don't see how we can expect a custom editor to support a scenario where its source extension isn't installed - is that even possible? I went over the issue with and concluded that we can defer to next release since the previous stable version also didn't handle this scenario well.
fyi I just created which is a similar issue for custom editors. Here for notebooks I suggest the following: if the EH restarts and still has the notebook extension for the opened notebooks, reconnect to the EH and allow to further make edits on the editor (I actually thought this was already implemented based on the work did) if the EH restarts and there is no more extension for the notebook editor, turn the notebook readonly and inform the user somehow Does that make sense?
The previous change just doesn't account for untitled notebooks, but I think I can fix that. That makes sense, although I'm surprised that we would require all custom editors to handle this (asked about it in the other issue)


Question: } let index: number; <del> if (this.editor.hasModel() && (typeof lineNumber === 'number')) { </del> <ins> if (this.editor.hasModel() && (typeof lineNumber === 'number' || !this.widget.provider)) { </ins> index = this.model.findNextClosestChange(typeof lineNumber === 'number' ? lineNumber : this.editor.getPosition().lineNumber, true, this.widget.provider); } else { const providerChanges: number[] = this.model.mapChanges.get(this.widget.provider) ?? this.model.mapChanges.values().next().value;

Open a file with multiple changed regions in git Move cursor inside/next to some change Run "Show Next Change" (alt+f3) It reveals and shows a different change- I think it always shows the last one in the editor. It should show the next one after the cursor position I can press it multiple times to cycle through changes, and that's correct, but it always starts with the last change
I'd like to fix this for April, but it looks like the change could be risky. I will fix it for May.
Found a low risk fix.
This works, thanks! But one thing that my muscle memory is unsure about, did this command previously move the cursor? I'm noticing that if I press it multiple times, then press escape, the view moves back to the place where I started, when I'm expecting this to be like a "navigate" action. I can open a new issue, or if it's always worked like this, it's fine
I went back to 1.74 to check, and it didn't move the cursor there. "Go to Next Change" will move the cursor though.


Question: **/extensions/markdown-language-features/notebook-out/** **/extensions/typescript-basics/test/colorize-fixtures/** **/extensions/**/dist/** <ins> **/extensions/typescript-language-features/test-workspace/** </ins>

Currently, we have to add this copyright header manually to every new file: /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ An ES Lint rule that has an auto fix would be really nice. What are your thoughts ! (using )
I like. The closest that we have today is this snippet
Let's do it!


Question: updateOptions(newOptions: Partial<NotebookViewModelOptions>) { this._options = { ...this._options, ...newOptions }; <ins> this._viewCells.forEach(cell => cell.updateOptions({ readonly: this._options.isReadOnly })); </ins> this._onDidChangeOptions.fire(); }

Type: <bBug</bDelete a notebook file in a git repo Open it from the SCM view It's editable ;( VS Code version: Code - Insiders 1.94.0-insider (Universal) (, 2024-09-11T05:04:03.124Z) OS version: Darwin arm64 23.6.0 Modes: <!-- generated by issue reporter --
Fixed by


Question: dropdownActions.push(new SubmenuAction('split.profile', localize('splitTerminal', 'Split Terminal'), submenuActions)); dropdownActions.push(new Separator()); } <del> for (const [, configureActions] of dropdownMenu.getActions()) { for (const action of configureActions) { // make sure the action is a MenuItemAction if ('alt' in action) { dropdownActions.push(action); } } } </del> <ins> const actions = dropdownMenu.getActions(); dropdownActions.push(...Separator.join(...actions.map(a => a[1]))); </ins> const defaultSubmenuProfileAction = submenuActions.find(d => d.label.endsWith('(Default)')); if (defaultSubmenuProfileAction) {

Could look like this, but have and/or tasks entries as well as a one. Hiding it by default is a good way to avoid cluttering the action bar - so people only see it if they want to <img width="285" alt="Screen Shot 2022-09-30 at 12 56 57 PM" src="https://user-"
cc
Talked w Kai and we're thinking to instead add a action to the terminal dropdown which aligns with the menu and will aid in discoverability !


Question: "@vscode/vscode-languagedetection": "1.0.21", "@vscode/windows-process-tree": "^0.6.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/headless": "5.6.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/headless": "^5.6.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "cookie": "^0.4.0", "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.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. After updating to VS Code 1.92, I noticed several scroll-related issues with the integrated terminal: exiting a full screen CLI app ( or ), sometimes scroll up or down doesn't work anymore until I press cmd+c - at which point I am teleported back to the start of the cli log. See the below video: start scroll works (though way too sensitive - see issue 2) press scroll up down no longer works press as soon as I try to scroll again, I am teleported to the top of the cli log output (though, at least scroll works after that)Note, while the above triggers the issue, sometimes the issue also occurs even without that (at one point I just run and this bug was triggered) full-screen CLI apps (, , ), the scroll sensitivity is way higher than when scrolling in non-full-screen apps. This scroll sensitivity is uncomfortably high, way higher than it was before, and remains high even if I set to a very low value like 0.1. scrolling through full-screen CLI app ( or ), sometimes the terminal will not let me scroll up. If I try to scroll up, I am "teleported" back to previous position. As soon as I scroll down, I can't scroll back up to the previous text. <!-- 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. --Relevant information: VS Code Version: 1.92 OS Version: macOS 14.5 Issues are reproducible in ZSH.


Question: "@vscode/vscode-languagedetection": "1.0.21", "@vscode/windows-process-tree": "^0.6.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/headless": "5.6.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/headless": "^5.6.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "cookie": "^0.4.0", "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2",

I was also able to trigger issue 1 in BASH In ZSH, I am using oh-my-zsh and powerlevel19k, BUT I was able to reproduce the issues even after I temporary disabled oh-my-zsh and powerlevel19k in my Issues are reproducible even if I start VS Code with empty user dir and empty extensions dir. A few relevant settings: is off. Enabling it does not make things better N/A as I am not holding the key - I am just scrolling using the touchpad is off. Enabling it did not make things better I am sorry if some of the above reproduction steps a bit vague - some of these don't happen each time so it's hard to see what triggered it. But these all started happening as soon as VS Code got updated to 1.92. I will keep updating this issue if I have more details. <details<summarySystem info</summaryGeneral: System info: System Information | -- | -- CPUs | Apple M1 Pro (10 x 2400) GPU Status | 2dcanvas: enabled canvasooprasterization: enabledon directrenderingdisplaycompositor: disabledoffok gpucompositing: enabled multiplerasterthreads: enabledon opengl: enabledon rasterization: enabled rawdraw: disabledoffok skiagraphite: disabledoff videodecode: enabled videoencode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off Load (avg) | 2, 2, 3 Memory (System) | 32.00GB (6.06GB free) Process Argv | /Users/mak13180/site/esri/arcgis-web-components --crash-reporter-id -0746-4857-a17b- Screen Reader | no VM | 0% Enabled extensions (BUT, issues are reproducible with all extensions disabled): Extension Version -- -- vite 0.2.5 shell-syntax 1.0.5 vscode-tailwindcss 0.12.5 vscode-eslint 3.0.10 apc-extension 0.4.1 gitlens 15.2.3 vscode-html-css 2.0.10 prettier-vscode 10.4.0 lintlens 7.5.0 copilot 1.219.0 copilot-chat 0.18.1 vscode-github-actions 0.26.


Question: "@vscode/vscode-languagedetection": "1.0.21", "@vscode/windows-process-tree": "^0.6.0", "@vscode/windows-registry": "^1.1.0", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/headless": "5.6.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/headless": "^5.6.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "cookie": "^0.4.0", "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.2",

3 vscode-pull-request-github 0.92.0 gc-excelviewer 4.2.59 todo-tree 0.0.226 search-node-modules 1.3.0 nodejs-repl 0.5.15 rainbow-csv 3.12.0 remote-ssh 0.112.0 remote-ssh-edit 0.86.0 remote-explorer 0.4.3 vscode-css-peek 4.4.1 vscode-yaml 1.15.0 code-spell-checker 3.0.1 vscode-stylelint 1.4.0 vscode-mdx 1.8.9 vscodeintellicode 1.3.1 explorer 1.0.6 vim 1.27.3 pretty-ts-errors 0.6.0 markdown-all-in-one 3.6.2 A/B experiment info: My (BUT, issues are also reproducible when VS Code is started with empty user dir): The log when VS Code is started as : </details
Upstream PR fixing it


Question: readonly allowEditorOverflow = true; private readonly domNode = document.createElement('div'); <del> private readonly elements = h('.editor-dictation-widget@main', [h('span@mic')]); constructor(private readonly editor: ICodeEditor) { </del> <ins> constructor(private readonly editor: ICodeEditor, keybindingService: IKeybindingService) { </ins> super(); <del> this.domNode.appendChild(this.elements.root); this.domNode.style.zIndex = '1000'; reset(this.elements.mic, renderIcon(Codicon.micFilled)); </del> <ins> const actionBar = this._register(new ActionBar(this.domNode)); const stopActionKeybinding = keybindingService.lookupKeybinding(EditorDictationStopAction.ID)?.getLabel(); actionBar.push(toAction({ id: EditorDictationStopAction.ID, label: stopActionKeybinding ? localize('stopDictationShort1', "Stop Dictation ({0})", stopActionKeybinding) : localize('stopDictationShort2', "Stop Dictation"), class: ThemeIcon.asClassName(Codicon.micFilled), run: () => EditorDictation.get(editor)?.stop() }), { icon: true, label: false, keybinding: stopActionKeybinding }); this.domNode.classList.add('editor-dictation-widget'); this.domNode.appendChild(actionBar.domNode); </ins> } getId(): string {

Testing My first reaction for how to stop dictation in the editor was to click the flashing microphone. It would be cool if something happened when the flashing microphone is clicked.
I will turn this into a real with action and hover.


Question: setTimeout(() => { dom.addClass(this._innerDomNode, 'visible'); <ins> dom.addClass(this._innerDomNode, 'visible-transition'); </ins> this._innerDomNode.setAttribute('aria-hidden', 'false'); setTimeout(() => { this._findInput.select();

Microsoft/vscode Repro: PR ext description page something, shift+tab until you hit the start of the screen There are 4 focusable items, close, next match, previous match and the find input.
Would you like me to start on this?
Yes please. It is too late to get a fix in for the January VS Code release but you can submit a PR any time and we'll try to get this fixed for February
LOL ... my Dragon dictation did the equivalent of a butt dial , deleted assignments and pasted an eMoji sorry about that :-P
FYI: started on this and I can reproduce and see it. simpleFind transitions in and out with animation, hidden only because of z-index and/or overflow. The widget always has display type:flex , therefore the four tabs stops for the buttons and input are always in the tabIndex order fix should be simple, however, there is an interaction between the animation and the display mode such that simultaneously going from display:none =flex messes up the animation. I'm working on separating the display mode from the transition to see if that will work. I have to do more experiments , May have a question or two later...
See PR: Verification: Use a screen reader with screen output on so you can see and track each tab stop Open the new pull request extension page Click on the upper pane to begin focus there Tab through the various toolbar buttons , after dependencies the next tab SHOULD land on With the webview not the simpleFind widget. Verify showing and hiding simpleFind has smooth animation as before Note: When focuses on bottom for web view pane , screen readers output a bunch of base64 encoded text (see truncated output lines below). But I think this is an accessibility bug, if you guys agree I'll post an issue. NVDA Output: with visibility fix (correct output, no tab stops within the hidden simpleFind) NVDA Output: original scenario without fix (can see tabs stops in widget)


Question: } rawUpdate(data: IRawModelUpdate): void { <ins> const threadIds: number[] = []; </ins> data.threads.forEach(thread => { <ins> threadIds.push(thread.id); </ins> if (!this.threads.has(thread.id)) { // A new thread came in, initialize it. this.threads.set(thread.id, new Thread(this, thread.name, thread.id));

<!-- 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.35.1 (also tried current 1.36.0-insider) OS Version: Ubuntu 18.04 VSCode's view seems to show all threads that ever existed, not just the ones returned by latest request. Repro: and run mock-debug extension from this branch: the folder and start configuration. all threads in the thread list and start stepping line by line. After each step the adapter will reduce the number of active threads by one. requests for invalid thread ids will be failed. By line 5, there will be only one thread remaining, yet VSCode tries to display all 5.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.586 --- <!-- score: 0.462 --- <!-- score: 0.461 --- <!-- score: 0.461 --<!-- potentialduplicatescomment --
make sure that only the threads returned by the last thread request (plus additional threads coming reported via the "thread" event) are shown.
thanks for the nice repo steps. I have changed that we now always respect the request as the absolute truth. So if a thread is not returned as part of the response we will delete it. I have created a PR which tackles this and I will merge this PR in next week since now we are in endgame and I would like to get more insiders coverage so we catch potential extensions which might rely on the current bugy behavior.


Question: } } <del> private notifyOnAppRootEditors(appRootUri: URI): void { const resourceUri = EditorResourceAccessor.getOriginalUri(this.editorService.activeEditor, { supportSideBySide: SideBySideEditor.BOTH }); const isResourceAppRootedFn = (uri: URI): boolean => this.uriIdentityService.extUri.isEqualOrParent(uri, appRootUri); let isResourceAppRooted = false; if (URI.isUri(resourceUri)) { if (isResourceAppRootedFn(resourceUri)) { isResourceAppRooted = true; } } else if (resourceUri) { if (resourceUri.primary && isResourceAppRootedFn(resourceUri.primary)) { isResourceAppRooted = true; } else if (resourceUri.secondary && isResourceAppRootedFn(resourceUri.secondary)) { isResourceAppRooted = true; } } // It is dangerous to edit files in the installation directory of Code because // an update will remove all files and replace them with the new version. // As such, we notify the user whenever an editor opens that is located somewhere // in the installation directory. // https://github.com/microsoft/vscode/issues/138815 if (isResourceAppRooted) { this.notificationService.prompt( Severity.Warning, localize('notifyOnAppRootEditors', "Files within the installation folder of '{0}' ({1}) will be OVERWRITTEN or DELETED IRREVERSIBLY without warning during a future update.", this.productService.nameShort, this.environmentService.appRoot), [{ label: localize('understood', 'Understood'), run: async () => { // Nothing to do } }], { neverShowAgain: { id: 'window.notifyOnAppRootEditors', isSecondary: true }, sticky: true } ); } } </del> private onAddFoldersRequest(request: IAddFoldersRequest): void { // Buffer all pending requests

a JS file: to definition on Bug I see this scary notification: <img width="671" alt="Screen Shot 2022-07-26 at 2 31 10 PM" src="https://user-"In this case, the user was likely just trying to view the file Would it be possible to either: show this notification when saving? open these file as ?
This came in via from and I think is not good. This also reminds me that when debugging you may end up in a file from the installation dir. I think we should probably revert the change for now and think about a better solution unless there are objections.
I agree. Maybe pursue your earlier suggestion of opening all installation directory files in readonly mode. Perhaps combine with a scary warning if you save a new file in there.


Question: import { IStorageService, StorageScope, StorageTarget } from '../../../../platform/storage/common/storage.js'; import { INotificationService } from '../../../../platform/notification/common/notification.js'; import { IExtensionService } from '../../../services/extensions/common/extensions.js'; <ins> import { groupBy as groupBy2 } from '../../../../base/common/collections.js'; </ins> const PICK_REPOSITORY_ACTION_ID = 'workbench.scm.action.graph.pickRepository'; const PICK_HISTORY_ITEM_REFS_ACTION_ID = 'workbench.scm.action.graph.pickHistoryItemRefs';

Testing I wonder how well it scales to show multiple tag icons, why not find a new icon that resembles multiple tags: !
I like that. Adding as that would require a new Codicon...
!
Or just show one tag in the row, but show all of them on hover like you do now.
How about showing one badge pert type (ex: branch, remote branch, tag) and a number indicating how many they are. That way there is no need create new icons that would cause further confusion.
I am actually not entirely sure what value there is to distinguish 1 tag from N tags? I would just show 1 icon if there is any tag.
Seems reasonable. Let's start with that and see how things go.