Question: return; } <ins> if (ref !== undefined && typeof ref !== 'string') { console.warn('Failed to open URI:', uri); return; } </ins> let cloneUri: Uri; try { let rawUri = Array.isArray(data.url) ? data.url[0] : data.url;

<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --vscode- a directory to clone your repo into cloned repo :bug: branch context is not preserved This impacts Continue Working On--branch context is preserved for Clone in Container and Create New Codespace. I propose adding a new optional query parameter to the uri handler here: and passing that to the command as an optional argument here Then after cloning here: and before opening the repo in a new window, we would perform the ref checkout:
will you create a test plan item/verification steps for this feature?
yes I will!


Question: import { ParsedArgs } from 'vs/platform/environment/common/environment'; import product from 'vs/platform/node/product'; import pkg from 'vs/platform/node/package'; import * as paths from 'path'; import * as os from 'os'; <ins> import * as fs from 'fs'; </ins> import { whenDeleted } from 'vs/base/node/pfs'; <del> import { writeFileAndFlushSync } from 'vs/base/node/extfs'; </del> import { findFreePort } from 'vs/base/node/ports'; function shouldSpawnCliProcess(argv: ParsedArgs): boolean {

This is very useful when working with the commandline, and to pass the result directly into the editor. It's especially useful for getting a file out of git's history, eg: FWIW, this works in Sublime.
+1
Here is my workaround (I'm on OSX so might need to adjust accordingly): create ~/bin/codestdin: Then run: Now git log, git show, git diff pipe correctly into vscode
Similar to approach, I've this to my bash profile to wrap the command... definitely not flawless, but it works for my use cases (so far). e.g.
For you have to modify the function a bit and use , because is a BUILTIN in and will return the function itself: What does not work is something like
Hello, For using the redirect, does this express the intent of getting of copy of the file contents assigned to an anonymous file buffer? Would that be similar to for intents sake? I wonder if are the only thing to care for that scenario? Thank you. Good day.
hello yes this should be equivalent as as I know.
Can we get some priority for this issue? It's been open since 2016 (that's 552 days!) and it's a bit ridiculous that VSCode still doesn't provide this extremely rudimentary shell interoperability.
+1
Pushed a change to feed the contents of stdin to a file and have it open in VS Code ( is implied when doing so): ! This currently works by or not, which is a bit brittle. If someone spawns VS Code without terminal emulation we might wrongly assume that data is coming in via stdin and open a tmp file. If it turns out that there are too many regressions, I might have to add a startup argument (, ) to explicitly enable this. If someone has a better idea how to detect if data is flowing in via stdin let me know.
This is great to see! Thanks so much! Is Atom's implementation the same?
as far as I know, Atom does not support this.
huh, I really thought it did, but local tests (and ) suggest not. Anyway, thanks again!
Hello, would you be kind enough to update your OP to note that Atom did and does not as of writing actively support this (probably just taking it out).


Question: import { ParsedArgs } from 'vs/platform/environment/common/environment'; import product from 'vs/platform/node/product'; import pkg from 'vs/platform/node/package'; import * as paths from 'path'; import * as os from 'os'; <ins> import * as fs from 'fs'; </ins> import { whenDeleted } from 'vs/base/node/pfs'; <del> import { writeFileAndFlushSync } from 'vs/base/node/extfs'; </del> import { findFreePort } from 'vs/base/node/ports'; function shouldSpawnCliProcess(argv: ParsedArgs): boolean {

There is the PR for them, but it is nice to have the proper perspective that VSCode is in the forefront of this kind of feature. Its no harm to stay, just misleading. Thank you. Good day.
done
Thanks for the feature, very nice. Just my 2 cents on feedback, the implied seems unnecessary. EG: when I pipe to TextMate it gives me my prompt back. There might be other reasons though for having the wait that I'm not thinking about though. Regardless, cheers and thanks for the work!
the calling process is waiting because it is not clear how long data is being sent to . It could be that the editor is already opened but data is still flowing. A workaround on your side would probably to send the command to the background by appending "" at the end?
Hrm, wasn't aware that was even possible. I feel like most commands I pipe complete then output is sent to the editor.
A terminal can have a specific encoding set which my solution did not yet account for. I pushed a change to try a little bit of terminal encoding guessing but I think the solution is not ideal. If someone has a better idea ( ?), let me know: Linux/macOS: use the output of running as encoding Windows: use by default any OS: if you specify an environment variable it will always win over the guessing This will not help if you change the encoding of the terminal ad-hoc as that does not seem to cause any configuration change that the command would detect. On Windows I see the  command but the output of that command seems to be intertwined with human readable text and not just the encoding. If someone has a better idea for Windows, please speak up.


Question: this.menuDisposables = []; <ins> addDisposableListener(menuElement, EventType.KEY_DOWN, (e) => { const event = new StandardKeyboardEvent(e); // Stop tab navigation of menus if (event.equals(KeyCode.Tab)) { EventHelper.stop(e, true); } }); </ins> if (options.enableMnemonics) { this.menuDisposables.push(addDisposableListener(menuElement, EventType.KEY_DOWN, (e) => { const key = e.key.toLocaleLowerCase();

Issue Type: <bBug</bthe refactoring window over any element with many available refactoring options (e.g.: a widget in Flutter) tab selection won't move BUT if you hit enter it will choose an option other than the highlighted one VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
Assigning because this only happens when using custom title bars. Repo Windows with custom title bar enabled the ts file: code actions and press tab once or twice, then enter The second or third code action ends up being applied even though the visible selection never changes


Question: firstPageIndex = this.view.indexAfter(scrollTop - 1); } <del> const firstPageElement = this.view.element(firstPageIndex); </del> const currentlyFocusedElementIndex = this.getFocus()[0]; <del> const currentlyFocusedElement = this.view.element(currentlyFocusedElementIndex); if (currentlyFocusedElement !== firstPageElement && currentlyFocusedElementIndex >= firstPageIndex) { </del> <ins> if (currentlyFocusedElementIndex !== firstPageIndex && (currentlyFocusedElementIndex === undefined || currentlyFocusedElementIndex >= firstPageIndex)) { </ins> const firstGoodPageIndex = this.findNextIndex(firstPageIndex, false, filter); <del> if (firstGoodPageIndex > -1 && currentlyFocusedElement !== this.view.element(firstGoodPageIndex)) { </del> <ins> if (firstGoodPageIndex > -1 && currentlyFocusedElementIndex !== firstGoodPageIndex) { </ins> this.setFocus([firstGoodPageIndex], browserEvent); } else { this.setFocus([firstPageIndex], browserEvent);

Open Select the top cell and page down a few times Focus hits a cell that is longer than the viewport, which is maybe important, then the next page down moves to a higher cell
When a list item is larger than the viewport, and it's also the only element in the viewport, pressing page down will reveal to the previous element, this is because we did a here (the catch is, the last page element is also the first page element)


Question: <del> 197a62bdc616148537af5c8f1256563a27a733cae0d41b9a42e9e9f2901cc9ae *electron-v25.8.1-darwin-arm64-symbols.zip 985f4beee009ef6dbe7af75009a1b281aff591b989ee544bd4d2c814f9c4428d *electron-v25.8.1-darwin-arm64.zip 56209b302eb30bff3727dbb74467cb2e6e93e5a99d6939d1c3a7c8320fa26d72 *electron-v25.8.1-darwin-x64-symbols.zip fe61a3221d4c5dc9415dc2cce81010db61bb4a5ab5021d1023f48786dbaf0b28 *electron-v25.8.1-darwin-x64.zip 1b52beba5b1b133cccd253c32648cdfa51659e5db2f20441baafd6a3c8fcb56a *electron-v25.8.1-linux-arm64-symbols.zip 931208419f859f528e19805ae14b5b075213bc40dd20da9e03d8b71d849c147d *electron-v25.8.1-linux-arm64.zip 61929b61541f23b75cca6b1a6764c219499a9799376298cc9061fc1a8716d1e1 *electron-v25.8.1-linux-armv7l-symbols.zip dd3390de2426a1cea9d3176e404b8fb250844a9b0e48cf01822fa66f3c3c4a48 *electron-v25.8.1-linux-armv7l.zip 1812459d2bd0440e35134ddb3f56e8e173a8791db888756d22080ace244248ba *electron-v25.8.1-linux-x64-symbols.zip de556aef0a80a8fe7b2b39d74ab0bdecc65d72bba3b7349460d18ef2a22fa323 *electron-v25.8.1-linux-x64.zip baa1bb8985b09100b1b2b710cea2c3f8e72a7f5d0e3421cbf675c25e732b0d9f *electron-v25.8.1-win32-arm64-pdb.zip 4a22945c2584677a822d8f9eb6cb23e5607b985f85ec7523ab977b73dd6487c2 *electron-v25.8.1-win32-arm64-symbols.zip 567d3188f86176a875fb6562040a3767c638814cf06073e7131495ec681b3957 *electron-v25.8.1-win32-arm64.zip 148589f41cd4175b85138450a0a0e32eef1a519d5cb5f471374e167518a2ed47 *electron-v25.8.1-win32-ia32-pdb.zip f284ac337a8d5e564081fee6d26c2b2f782feed0bcbe29b7507f749da36b6e5c *electron-v25.8.1-win32-ia32-symbols.zip 6737e56588a2707534979e5dcfbf68399971a5e98d4848fa29fb43b7ae1dc378 *electron-v25.8.1-win32-ia32.zip 23c6ef26f7e1914149def7525b728212340fc6befa6bac30eafec8f8229f9e67 *electron-v25.8.1-win32-x64-pdb.zip 3eb3b87587b136e636d82fa4d28015d8ef6709468b3bb33eddae80d83076a053 *electron-v25.8.1-win32-x64-symbols.zip 963c05266bf83bc77f690b75a76855d7b7bc0be9bac4973292f3e7d506fd2c94 *electron-v25.8.1-win32-x64.zip ab608119c4bb4ebcefede6afdd911ef8ea007465ab7d2093a091bdb9ff466236 *ffmpeg-v25.8.1-darwin-arm64.zip 5abaf6356bb40fdfcaf88177e13c50447a48fe7fc6c1c3869cf4536148eb60d4 *ffmpeg-v25.8.1-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.8.1-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.8.1-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.8.1-linux-x64.zip 6b2494dd5bf7f17eec800f41d232506007b36c7cae6f885565e035d3168a0c64 *ffmpeg-v25.8.1-win32-arm64.zip 8b57594cd2065437cf3378e845bae4de3501ebff7f1f1f516fc0aaf09c311c2b *ffmpeg-v25.8.1-win32-ia32.zip 95bb8e167e96bb4f902e6238312e245ed0acfae45eeda471e0f8ad0f0baaac2f *ffmpeg-v25.8.1-win32-x64.zip </del> <ins> 990cfa83850fc2934ddf435737ea16c68e222136107aba177d961af839a61765 *electron-v25.8.2-darwin-arm64-symbols.zip f6ab7cd71e50fae41cae0192108df98afc0a30583d945d3e673d8483d4dddefe *electron-v25.8.2-darwin-arm64.zip 2feec213e4b2a4728ef5f5ec833ee8663d801a06b7ed1f172eee4ba3f9f51339 *electron-v25.8.2-darwin-x64-symbols.zip 04027c3ecb90d8252f1adbd887d9567d5f16eee126f8df753a29fa79d9b61d6b *electron-v25.8.2-darwin-x64.zip 4a9a49d6003ac86ccba5495ff782f584215cee36f9335772cdc0581911f5f6a1 *electron-v25.8.2-linux-arm64-symbols.zip 1b15ad0e26785850f9ab2112d3183669aac4b702c474ab7ad31954c649b3351f *electron-v25.8.2-linux-arm64.zip 4bdd180dff11013d6c2d25c578e5398ac9c7dd3b6255080836868e1cd55e4c13 *electron-v25.8.2-linux-armv7l-symbols.zip db4271335284d2d327130063cca6a4adee0678504098c0347e2cb89c4ddefd7a *electron-v25.8.2-linux-armv7l.zip ab9c35e7a6df6b2335f273711cc16c94f982f4d55b2c0bba554187f43864242e *electron-v25.8.2-linux-x64-symbols.zip 08c211d4199096d0ff9c475720f25ff5c089d624660b4c1f1970a413e20312b7 *electron-v25.8.2-linux-x64.zip d3bd6ab0be3c4d93a7a19f9da0c391c1ef8daa85027bf00f9ac75a97e7027fcf *electron-v25.8.2-win32-arm64-pdb.zip cc6c369bd9d2fc7664bbd5138be5527432e17ec6eb7c7b5405e641e0468dc280 *electron-v25.8.2-win32-arm64-symbols.zip d4083f48cc1f7bb311a4a53814e2cd7c343c159f4bcd4ee368d20564e1d34a36 *electron-v25.8.2-win32-arm64.zip 276b0ba63d6dbb78f99caf2c58213415f22cb4f90ec6e6485214f3174482458c *electron-v25.8.2-win32-ia32-pdb.zip 45551352678e250c7970c6258d55e1c6451131d1e5f1ea053390bd9d9364d33c *electron-v25.8.2-win32-ia32-symbols.zip fc9798e973b6a872d7250754b29caa48b0f0ad7c33f39ab61008525b29111049 *electron-v25.8.2-win32-ia32.zip 491795df7e70effeae68a11e39675ca32677b44865d10151a2eea71dad2c2815 *electron-v25.8.2-win32-x64-pdb.zip fa5962a52022c16fb59d79c7528d50ab314b6a8d1e6b90f4c940bb3a0f061923 *electron-v25.8.2-win32-x64-symbols.zip fb5786dc18a10cc29b4d765f34af2f9f9d9866f82007468b55d800dd43feb196 *electron-v25.8.2-win32-x64.zip b1ad00396c949d0f37fe3920eb4f667663d7453dce4f141bcbfc560140a85d84 *ffmpeg-v25.8.2-darwin-arm64.zip 81a3dff9b95d294a7955d67e013ecf65b0c1b929104cea82fcf22774c067d457 *ffmpeg-v25.8.2-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.8.2-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.8.2-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.8.2-linux-x64.zip aacd68ce8a56e707e20fdcf08ea66348dbb1717b87f9c7e3d80da106fa5aa45b *ffmpeg-v25.8.2-win32-arm64.zip 29411956a1ab20f63926a764893effd113c0ef0349cbaa355a95c1c1046d5d8d *ffmpeg-v25.8.2-win32-ia32.zip 80ccd09de3a73e1a3b27ad2aa2a8a3eb5753290b7eee3d2e5ea08837876c3f66 *ffmpeg-v25.8.2-win32-x64.zip </ins>

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --<!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Something has changed in the latest Insiders so our CI started to fail with errors (any branch but here is an ): Do you have any idea what might cause it so we can make changes on our side? Might it be something with your dependencies?
Runtime has no changes with insiders, this seems like a regression from the recent http proxy changes based on in upstream. Passing onto From a quick look the extension relies on package which makes network connection. it would be great if you can reduce the test case to a minimal extension sample for us to debug this issue further. Thanks!
Unfortunately, we haven't been able to isolate the issue for a minimal extension sample so far. To reproduce the problem, you can follow these steps: the and install the extension. the following commands in the terminal: When running all tests, you may observe multiple failures with the . However, when running the failed tests separately, they randomly may or may not fail again, which makes it hard to identify the cause of the issue. It is possible that your proxy patches might be the right place to look for further investigation.
Maybe a related discussion:
Found it. The place in our code that fails with the latest Insiders is . I created a so you can try it, but here is the code snippet for a quick look:
Thanks for putting together this test! My investigation so far: is called with resulting in the reported error when it calls here: The check at would prevent from being called when , but that is only with in 19.0.0.


Question: <del> 197a62bdc616148537af5c8f1256563a27a733cae0d41b9a42e9e9f2901cc9ae *electron-v25.8.1-darwin-arm64-symbols.zip 985f4beee009ef6dbe7af75009a1b281aff591b989ee544bd4d2c814f9c4428d *electron-v25.8.1-darwin-arm64.zip 56209b302eb30bff3727dbb74467cb2e6e93e5a99d6939d1c3a7c8320fa26d72 *electron-v25.8.1-darwin-x64-symbols.zip fe61a3221d4c5dc9415dc2cce81010db61bb4a5ab5021d1023f48786dbaf0b28 *electron-v25.8.1-darwin-x64.zip 1b52beba5b1b133cccd253c32648cdfa51659e5db2f20441baafd6a3c8fcb56a *electron-v25.8.1-linux-arm64-symbols.zip 931208419f859f528e19805ae14b5b075213bc40dd20da9e03d8b71d849c147d *electron-v25.8.1-linux-arm64.zip 61929b61541f23b75cca6b1a6764c219499a9799376298cc9061fc1a8716d1e1 *electron-v25.8.1-linux-armv7l-symbols.zip dd3390de2426a1cea9d3176e404b8fb250844a9b0e48cf01822fa66f3c3c4a48 *electron-v25.8.1-linux-armv7l.zip 1812459d2bd0440e35134ddb3f56e8e173a8791db888756d22080ace244248ba *electron-v25.8.1-linux-x64-symbols.zip de556aef0a80a8fe7b2b39d74ab0bdecc65d72bba3b7349460d18ef2a22fa323 *electron-v25.8.1-linux-x64.zip baa1bb8985b09100b1b2b710cea2c3f8e72a7f5d0e3421cbf675c25e732b0d9f *electron-v25.8.1-win32-arm64-pdb.zip 4a22945c2584677a822d8f9eb6cb23e5607b985f85ec7523ab977b73dd6487c2 *electron-v25.8.1-win32-arm64-symbols.zip 567d3188f86176a875fb6562040a3767c638814cf06073e7131495ec681b3957 *electron-v25.8.1-win32-arm64.zip 148589f41cd4175b85138450a0a0e32eef1a519d5cb5f471374e167518a2ed47 *electron-v25.8.1-win32-ia32-pdb.zip f284ac337a8d5e564081fee6d26c2b2f782feed0bcbe29b7507f749da36b6e5c *electron-v25.8.1-win32-ia32-symbols.zip 6737e56588a2707534979e5dcfbf68399971a5e98d4848fa29fb43b7ae1dc378 *electron-v25.8.1-win32-ia32.zip 23c6ef26f7e1914149def7525b728212340fc6befa6bac30eafec8f8229f9e67 *electron-v25.8.1-win32-x64-pdb.zip 3eb3b87587b136e636d82fa4d28015d8ef6709468b3bb33eddae80d83076a053 *electron-v25.8.1-win32-x64-symbols.zip 963c05266bf83bc77f690b75a76855d7b7bc0be9bac4973292f3e7d506fd2c94 *electron-v25.8.1-win32-x64.zip ab608119c4bb4ebcefede6afdd911ef8ea007465ab7d2093a091bdb9ff466236 *ffmpeg-v25.8.1-darwin-arm64.zip 5abaf6356bb40fdfcaf88177e13c50447a48fe7fc6c1c3869cf4536148eb60d4 *ffmpeg-v25.8.1-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.8.1-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.8.1-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.8.1-linux-x64.zip 6b2494dd5bf7f17eec800f41d232506007b36c7cae6f885565e035d3168a0c64 *ffmpeg-v25.8.1-win32-arm64.zip 8b57594cd2065437cf3378e845bae4de3501ebff7f1f1f516fc0aaf09c311c2b *ffmpeg-v25.8.1-win32-ia32.zip 95bb8e167e96bb4f902e6238312e245ed0acfae45eeda471e0f8ad0f0baaac2f *ffmpeg-v25.8.1-win32-x64.zip </del> <ins> 990cfa83850fc2934ddf435737ea16c68e222136107aba177d961af839a61765 *electron-v25.8.2-darwin-arm64-symbols.zip f6ab7cd71e50fae41cae0192108df98afc0a30583d945d3e673d8483d4dddefe *electron-v25.8.2-darwin-arm64.zip 2feec213e4b2a4728ef5f5ec833ee8663d801a06b7ed1f172eee4ba3f9f51339 *electron-v25.8.2-darwin-x64-symbols.zip 04027c3ecb90d8252f1adbd887d9567d5f16eee126f8df753a29fa79d9b61d6b *electron-v25.8.2-darwin-x64.zip 4a9a49d6003ac86ccba5495ff782f584215cee36f9335772cdc0581911f5f6a1 *electron-v25.8.2-linux-arm64-symbols.zip 1b15ad0e26785850f9ab2112d3183669aac4b702c474ab7ad31954c649b3351f *electron-v25.8.2-linux-arm64.zip 4bdd180dff11013d6c2d25c578e5398ac9c7dd3b6255080836868e1cd55e4c13 *electron-v25.8.2-linux-armv7l-symbols.zip db4271335284d2d327130063cca6a4adee0678504098c0347e2cb89c4ddefd7a *electron-v25.8.2-linux-armv7l.zip ab9c35e7a6df6b2335f273711cc16c94f982f4d55b2c0bba554187f43864242e *electron-v25.8.2-linux-x64-symbols.zip 08c211d4199096d0ff9c475720f25ff5c089d624660b4c1f1970a413e20312b7 *electron-v25.8.2-linux-x64.zip d3bd6ab0be3c4d93a7a19f9da0c391c1ef8daa85027bf00f9ac75a97e7027fcf *electron-v25.8.2-win32-arm64-pdb.zip cc6c369bd9d2fc7664bbd5138be5527432e17ec6eb7c7b5405e641e0468dc280 *electron-v25.8.2-win32-arm64-symbols.zip d4083f48cc1f7bb311a4a53814e2cd7c343c159f4bcd4ee368d20564e1d34a36 *electron-v25.8.2-win32-arm64.zip 276b0ba63d6dbb78f99caf2c58213415f22cb4f90ec6e6485214f3174482458c *electron-v25.8.2-win32-ia32-pdb.zip 45551352678e250c7970c6258d55e1c6451131d1e5f1ea053390bd9d9364d33c *electron-v25.8.2-win32-ia32-symbols.zip fc9798e973b6a872d7250754b29caa48b0f0ad7c33f39ab61008525b29111049 *electron-v25.8.2-win32-ia32.zip 491795df7e70effeae68a11e39675ca32677b44865d10151a2eea71dad2c2815 *electron-v25.8.2-win32-x64-pdb.zip fa5962a52022c16fb59d79c7528d50ab314b6a8d1e6b90f4c940bb3a0f061923 *electron-v25.8.2-win32-x64-symbols.zip fb5786dc18a10cc29b4d765f34af2f9f9d9866f82007468b55d800dd43feb196 *electron-v25.8.2-win32-x64.zip b1ad00396c949d0f37fe3920eb4f667663d7453dce4f141bcbfc560140a85d84 *ffmpeg-v25.8.2-darwin-arm64.zip 81a3dff9b95d294a7955d67e013ecf65b0c1b929104cea82fcf22774c067d457 *ffmpeg-v25.8.2-darwin-x64.zip bd52d57ff97fb56ac01a3482af905d04f0d4e9c13c53858c6d9f99957eca82da *ffmpeg-v25.8.2-linux-arm64.zip 9b3d09177fa1e63e2a6beecfa70aeec30aeb5c1873ff21128a68051c4e23f95d *ffmpeg-v25.8.2-linux-armv7l.zip edc7b1c9f1a0733f109a2c0375a4e40c5bfe0bf28b7f06dcc76e1ada0aa2f125 *ffmpeg-v25.8.2-linux-x64.zip aacd68ce8a56e707e20fdcf08ea66348dbb1717b87f9c7e3d80da106fa5aa45b *ffmpeg-v25.8.2-win32-arm64.zip 29411956a1ab20f63926a764893effd113c0ef0349cbaa355a95c1c1046d5d8d *ffmpeg-v25.8.2-win32-ia32.zip 80ccd09de3a73e1a3b27ad2aa2a8a3eb5753290b7eee3d2e5ea08837876c3f66 *ffmpeg-v25.8.2-win32-x64.zip </ins>

Still need to check older versions to see if that check was backported and see if there is a way to test this assessment.
is available in 18.8.0 and 16.18.0, our exploration builds based on Node v18 has this change, you can use the builds from to verify the assessment.
The test does not reproduce the issue in the exploration build. Still trying to understand what is happening (please ignore the above code pointers) by looking at the code at the tag. I see the failing call to being triggered in : What I don't quite understand is that the callstack to with comes from : But at that line is supposed to call not as it appear in the callstack: Could you point me at the source that went into Electron? I believe that is not the exact same as that at
Electron pulls source from when building, what you are looking at is the correct one. I think the async stack is missing a trampoline calll, but you are seeing a write after shutdown stack same as
Thanks This looks like an upstream issue to me, should not be called when is already . I don't see the change in 18.15.0 (the version the exploration build is using) yet that might have fixed it.
We have reverted to the previous way of loading certificates as we are getting close to a release ().
We're seeing this again in our macos and Windows CI jobs for VSCode "Insiders" (not current VSCode stable version 1.82.2). Was node or electron updated in the last 2 days on VSCode Insiders?
There is fix in upstream for the above scenario, I will backport it to relevant release lines.
Could you confirm that todays Insiders build fixes the problem? Thanks!
Confirmed, thanks!


Question: "continueEditSession": [ { "command": "github.openOnVscodeDev", <del> "when": "github.hasGitHubRepo" </del> <ins> "when": "github.hasGitHubRepo", "qualifiedName": "Continue Working in VS Code for the Web" </ins> } ], "menus": {

Testing If I run "Continue working on...," I get many development environments to target, but I only see one Continue Working in command for the codespace option.
Verified from the remote repositories options. Looks like 1 and 2 (local folder and local container) still need to add entries to be consistent. <img width="355" alt="image" src="https://user-"
who should add the built-in command?


Question: readonly _serviceBrand: undefined; readonly terminalProfiles: ReadonlyArray<IExtensionTerminalProfile>; <del> readonly quickFixes: Array<ITerminalCommandSelector>; </del> <ins> readonly quickFixes: Promise<Array<ITerminalCommandSelector>>; </ins> } export const ITerminalContributionService = createDecorator<ITerminalContributionService>('terminalContributionsService');

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


Question: private _state?: vscode.CommentThreadState; get state(): vscode.CommentThreadState { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> return this._state!; } set state(newState: vscode.CommentThreadState) { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> this._state = newState; this.modifications.state = newState; this._onDidUpdateCommentThread.fire();

<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The comments API doesn't have the concept of resolved/unresolved threads, although most code review tools distinguish them. The current API allows us to surface this to the users, see However, this seems pretty limited. I find it difficult to identify all my unresolved comments. It's very easy to miss some of them. If the API had a boolean for unresolved comments, we could surface them in multiple ways: In the Comments panel, surface the number of unresolved comments, similar to what is done with Problems: ! In the Comments panel, highlight the unresolved comments (or put them in bold), so that it's obvious to the user what comments they still have to go through. In the Comments panel, have a way to hide/filter the resolved comments. In the Editor, consider consider using a different background color for unresolved comments. I currently use a different label for unresolved comments, but this is very subtle. In the gutter, use a different symbol for unresolved comments (e.g. or a diamond of another color). In the Editor, provide a way to go to the next unresolved comment (an alternative to ).
Let's discuss the API change. IMO, the information should be part of a . On many levels, Comments seem similar to s. A diagnostic is a comment provided by a tool such as a compiler. A comment is typically provided by a human. Diagnostics have a severity field, which indicates how important is the problem. We need an equivalent for Comments, something that tells the user if an action is expected (e.g. they need to resolve it) or not. Once the user addresses the comment, the importance is reduced. simplistic solution is to add a boolean, e.g. . to , we can go for a two-state enum instead: to be more general: . We might consider having more fields here. In a code review, multiple users interact with the comments. The current VSCode user is not necessarily the person who needs to do something. For example, the user has just updated the comment and they wait for a response.


Question: private _state?: vscode.CommentThreadState; get state(): vscode.CommentThreadState { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> return this._state!; } set state(newState: vscode.CommentThreadState) { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> this._state = newState; this.modifications.state = newState; this._onDidUpdateCommentThread.fire();

So the third value could be used to mean "it's not my turn" or "acknowledged, I'll come back later". The benefit is that the user can use the list of "unresolved" issues as a TODO-list and publish the comments once it's empty.
Thank you very much for your proposal. and me have quickly discussed this and we believe this proposal makes good sense. We plan to start looking into it next milestone. Though no promises yet when this will land, we will know more in December when we start our investigation.
All of the proposals in have merit. In a perfect world I would choose one of options 2 or 4; however, we have users of the comments API who's comments don't have a resolved/unresolved state. Option 3 circumvents that, but then we have the issue of what to show in the UI: a GitHub PR comment isn't high or low priority. Another proposal, similar to how comment reactions work:
I see than left comments on the commit (). I like the approach of having an object for the state (instead of the proposed boolean/enum), it gives more flexibility and lets user create their own states. In my proposal, the information was attached to a thread, not to a single comment. Do we have use-cases where we want this information per comment? We might also want to control the gutter icon:
GitHub comments are resolved per-thread, so no, no cases were we want it per comment. I'll move it to the thread.
After much discussion, we have decided to proceed with the following: The main reasoning behind this is that resolved vs. unresolved comments should look the same to the user across a GitHub PR extension, an Azure Dev Ops PR extensions, and any other PR extension. There original concern around using "resolved" and "unresolved" is that maybe not all comment provider have those states (maybe they have "viewed" and "unviewed" states for example). To alleviate this, we'll see if we can avoid using "resolved"/"unresolved" language in the UI. If additional states are needed later, we can always add more to the API.
I have a basic implementation of this working, with and themable colors. Before I finish up the pull request to send it out, I was wondering what the best practice is for providing defaults for these colors?


Question: private _state?: vscode.CommentThreadState; get state(): vscode.CommentThreadState { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> return this._state!; } set state(newState: vscode.CommentThreadState) { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> this._state = newState; this.modifications.state = newState; this._onDidUpdateCommentThread.fire();

In the mocks from we use a yellow for unresolved comments that is inspired by visuals of our internal tool. I am not sure if they match an established VS Code palette.
awesome, looking forward to reviewing it! Generally, we try to avoid introducing a new color entirely for something like this. The best practice would be to look through the existing color values where we use yellow then use the same yellow, just like is done here where uses the same color as : We'll also do a UX review of this, so the color may end up changing anyway.
I went for new colors as the comments are conceptually something different than e.g. editor warnings. Currently the comments in the editor use (default blue), so a theme, an extension, or the users themselves would not be able to style comments independently of peek views. I think it makes sense to base the default on another color like as in your example, so that themes which omit the new colors receive a reasonable default, but it seems like we would give up a lot of flexibility and also clarity if comment widget colors directly used something like internally?
Yes, basing the color on another is what I meant! I agree that we don't want to directly use another theme color.
If anyone is eager for this API to be finalized then please comment and let me know how it's working for you. Otherwise, I will plan to finalize later in 2022.
This would be very nice to have. We are using Github and especially larger PRs are hard to manage, if there are many comments (in Github as well as in VSCode)
So is there currently a way to filter resolved/unresolved comments in the sidebar? If not what can I modify currently to provide a visual distinction between resolved/unresolved?
there's a color difference on the icon, but that's currently it. This is the feature request you're looking for


Question: position: relative; } <del> .monaco-workbench .panel.integrated-terminal .xterm:focus { </del> <ins> .monaco-workbench .panel.integrated-terminal .xterm.focus { </ins> outline: none; } <del> .hc-black .monaco-workbench .panel.integrated-terminal .xterm:focus { </del> <ins> .hc-black .monaco-workbench .panel.integrated-terminal .xterm.focus { </ins> outline: 2px solid #f38518; } <ins> .monaco-workbench .panel.integrated-terminal .xterm .xterm-helpers { position: absolute; top: 0; } .monaco-workbench .panel.integrated-terminal .xterm .xterm-helper-textarea { position: absolute; /* * HACK: to fix IE's blinking cursor * Move textarea out of the screen to the far left, so that the cursor is not visible. */ left: -9999em; opacity: 0; width: 0; height: 0; z-index: -10; } </ins> .monaco-workbench .panel.integrated-terminal .reverse-video { color: #1e1e1e; } .vs-dark .monaco-workbench .panel.integrated-terminal .reverse-video { color: #CCC; } .hc-black .monaco-workbench .panel.integrated-terminal .reverse-video { color: #FFF; } <del> .monaco-workbench .panel.integrated-terminal .xterm:focus .terminal-cursor { background-color: #333; } .vs-dark .monaco-workbench .panel.integrated-terminal .xterm:focus .terminal-cursor { background-color: #CCC; } .hc-black .monaco-workbench .panel.integrated-terminal .xterm:focus .terminal-cursor { background-color: #FFF; } </del> <ins> .monaco-workbench .panel.integrated-terminal .xterm.focus .terminal-cursor { background-color: #333; } .vs-dark .monaco-workbench .panel.integrated-terminal .xterm.focus .terminal-cursor { background-color: #CCC; } .hc-black .monaco-workbench .panel.integrated-terminal .xterm.focus .terminal-cursor { background-color: #FFF; } </ins> <del> .monaco-workbench .panel.integrated-terminal .xterm:not(:focus) .terminal-cursor { </del> <ins> .monaco-workbench .panel.integrated-terminal .xterm:not(.focus) .terminal-cursor { </ins> background-color: transparent; outline: 1px solid #333; outline-offset: -1px; } <del> .vs-dark .monaco-workbench .panel.integrated-terminal .xterm:not(:focus) .terminal-cursor { </del> <ins> .vs-dark .monaco-workbench .panel.integrated-terminal .xterm:not(.focus) .terminal-cursor { </ins> background-color: transparent; outline: 1px solid #CCC; outline-offset: -1px; } <del> .hc-black .monaco-workbench .panel.integrated-terminal .xterm:not(:focus) .terminal-cursor { </del> <ins> .hc-black .monaco-workbench .panel.integrated-terminal .xterm:not(.focus) .terminal-cursor { </ins> background-color: transparent; outline: 1px solid #FFF; outline-offset: -1px; } <del> .monaco-workbench .panel.integrated-terminal .xterm:focus .terminal-cursor.blinking { animation: blink-cursor 1.2s infinite step-end; } .vs-dark .monaco-workbench .panel.integrated-terminal .xterm:focus .terminal-cursor.blinking { animation: blink-cursor-dark 1.2s infinite step-end; } .hc-black .monaco-workbench .panel.integrated-terminal .xterm:focus .terminal-cursor.blinking { animation: blink-cursor-hc-black 1.2s infinite step-end; } </del> <ins> .monaco-workbench .panel.integrated-terminal .xterm.focus .terminal-cursor.blinking { animation: blink-cursor 1.2s infinite step-end; } .vs-dark .monaco-workbench .panel.integrated-terminal .xterm.focus .terminal-cursor.blinking { animation: blink-cursor-dark 1.2s infinite step-end; } .hc-black .monaco-workbench .panel.integrated-terminal .xterm.focus .terminal-cursor.blinking { animation: blink-cursor-hc-black 1.2s infinite step-end; } </ins> @keyframes blink-cursor { 0% {

VSCode Version: 1.2.0-insider OS Version: OS X El Capitan 10.11.5 Steps to Reproduce: by default settings !
Cannot type cyrillic as well
Upstream issue
This is one of the issues I want to focus on for v1.4


Question: export namespace CommentAccessibilityHelpNLS { <del> export const escape = nls.localize('escape', "Dismiss the comment widget via Escape."); export const nextRange = nls.localize('next', "Navigate to the next commenting range via ({0})."); export const nextRangeNoKb = nls.localize('nextNoKb', "Run the command: Go to Next Commenting Range, which is currently not triggerable via keybinding."); export const previousRange = nls.localize('previous', "Navigate to the previous comment range via ({0})."); </del> <ins> export const intro = nls.localize('intro', "The editor contains a commentable range. Some useful commands include:"); export const introWidget = nls.localize('introWidget', "Some useful comment commands include:"); export const escape = nls.localize('escape', "- Dismiss Comment (Escape)"); export const nextRange = nls.localize('next', "- Navigate to the next commenting range ({0})"); export const nextRangeNoKb = nls.localize('nextNoKb', "- Go to Next Commenting Range, which is currently not triggerable via keybinding."); export const previousRange = nls.localize('previous', "- Navigate to the previous commenting range ({0})"); </ins> export const previousRangeNoKb = nls.localize('previousNoKb', "Run the command: Go to Previous Commenting Range, which is currently not triggerable via keybinding."); <del> export const nextCommentThreadKb = nls.localize('nextCommentThreadKb', "Navigate to the next comment thread via ({0})."); export const nextCommentThreadNoKb = nls.localize('nextCommentThreadNoKb', "Run the command: Go to Next Comment Thread, which is currently not triggerable via keybinding."); export const previousCommentThreadKb = nls.localize('previousCommentThreadKb', "Navigate to the previous comment thread via ({0})."); export const previousCommentThreadNoKb = nls.localize('previousCommentThreadNoKb', "Run the command: Go to Previous Comment Thread, which is currently not triggerable via keybinding."); export const addComment = nls.localize('addComment', "Add a comment via ({0})."); export const addCommentNoKb = nls.localize('addCommentNoKb', "Add a comment via the command: Add Comment on Current Selection, which is currently not triggerable via keybinding."); export const submitComment = nls.localize('submitComment', "Submit the comment via ({0})."); export const submitCommentNoKb = nls.localize('submitCommentNoKb', "Submit the comment by navigating with tab to the button, as it's currently not triggerable via keybinding."); </del> <ins> export const nextCommentThreadKb = nls.localize('nextCommentThreadKb', "- Navigate to the next comment thread ({0})"); export const nextCommentThreadNoKb = nls.localize('nextCommentThreadNoKb', "- Run the command: Go to Next Comment Thread, which is currently not triggerable via keybinding."); export const previousCommentThreadKb = nls.localize('previousCommentThreadKb', "- Navigate to the previous comment thread ({0})"); export const previousCommentThreadNoKb = nls.localize('previousCommentThreadNoKb', "- Run the command: Go to Previous Comment Thread, which is currently not triggerable via keybinding."); export const addComment = nls.localize('addComment', "- Add Comment ({0})"); export const addCommentNoKb = nls.localize('addCommentNoKb', "- Add Comment on Current Selection, which is currently not triggerable via keybinding."); export const submitComment = nls.localize('submitComment', "- Submit Comment ({0})"); export const submitCommentNoKb = nls.localize('submitCommentNoKb', "- Submit Comment, accessible via tabbing, as it's currently not triggerable with a keybinding."); </ins> } export class CommentsAccessibilityHelpContribution extends Disposable {

As a result of the discussion in , we should format each command, description, and keybinding more consistently and limit redundancy.
/closedWith though still need to do the same for the chat help dialogs


Question: import { Range } from 'vs/editor/common/core/range'; import { registerAction2 } from 'vs/platform/actions/common/actions'; import { assertIsDefined } from 'vs/base/common/types'; <ins> import { ActionBar } from 'vs/base/browser/ui/actionbar/actionbar'; import { toAction } from 'vs/base/common/actions'; import { ThemeIcon } from 'vs/base/common/themables'; </ins> const EDITOR_DICTATION_IN_PROGRESS = new RawContextKey<boolean>('editorDictation.inProgress', false); const VOICE_CATEGORY = localize2('voiceCategory', "Voice");

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: if (restoreFocus) { this.explorerViewer.setFocus(modelElement); } <ins> //Expand the element again if (isExpanded) { this.explorerViewer.expand(modelElement); } </ins> }, errors.onUnexpectedError); }); }

Issue Type: Bug folder ! VS Code version: Code - Insiders 1.21.0-insider (, 2018-02-21T09:22:14.399Z) OS version: Windows_NT x64 10.0. Reproduces without extensions <!-- generated by issue reporter --
Code pointer
does it mean that this is the expected behavior?
I m on it.
it is always debatable if something is a feature-request or a bug. I guess this is more of a bug, but I took the artistic freedom and assigned feature-request.
it does not seem to restore the full expansion state, only the first level is that true?
yes, only the first level. could improve the PR and try to restore more.
Yes, i can do that.
great, tree should have api to get the exapnsion state. And once the pr is ready just ping me on it.
Should i make a new method to return all the expanded children as array on treeModel?
Is this ready for verification?
ben already verified and can add a verified label. There are some limitation which will tackle in a pr for next milestone


Question: private _hoverClicked: boolean; private _isHoverEnabled!: boolean; private _isHoverSticky!: boolean; <ins> private _hidingDelay!: number; </ins> private _hoverActivatedByColorDecoratorClick: boolean = false; <ins> private _mouseWasOverWidget: boolean = false; private _hideWidgetsTimeout: NodeJS.Timeout | undefined; </ins> static get(editor: ICodeEditor): ModesHoverController | null { return editor.getContribution<ModesHoverController>(ModesHoverController.ID);

Currently the hover disappear as soon as the mouse leaves the content hover. Sometimes the user leaves briefly the content hover. The ask is to wait until some times (ex. 500 ms) has passed before measuring whether the mouse is within the hover or not, then make the hover disappear or not.
This would be quite helpful in resizing the hover (because it's easy to go out of the hover when aiming for the angle to hover with a mouse). But I would think 500 ms is too much for that use case


Question: *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { ChildProcess, ChildProcessWithoutNullStreams, spawn, SpawnOptions } from 'child_process'; </del> <ins> import { ChildProcess, spawn, SpawnOptions, StdioOptions } from 'child_process'; </ins> import { chmodSync, existsSync, readFileSync, statSync, truncateSync, unlinkSync } from 'fs'; import { homedir, release, tmpdir } from 'os'; import type { ProfilingSession, Target } from 'v8-inspect-profiler';

Version: 1.78.0-insider (user setup) Commit: Date: 2023-04-04T09:32:52.453Z Electron: 22.4.3 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes run from a Windows command prompt The tunnel starts and prints open VS Code, and open the output Note that the output is stuck at Missing are the message and the info that the tunnel is attached The UI thinks the tunnel is still connecting. Sometimes this also works, but when I try it, most of the time it is stuck
Can you please enable trace logging and share the output?
Nothing extra messages shown when the Desktop tunnel attaches:
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Still a problem in Version: 1.78.0-insider (user setup) Commit: Date: 2023-04-12T05:19:38.288Z Reproduces every time I try it
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!


Question: import { NotebookDiffViewModel } from './notebookDiffViewModel.js'; import { INotebookService } from '../../common/notebookService.js'; import { DiffEditorHeightCalculatorService, IDiffEditorHeightCalculatorService } from './editorHeightCalculator.js'; <ins> import { IEditorService } from '../../../../services/editor/common/editorService.js'; </ins> const $ = DOM.$;

Testing For this issue I used a notebook with one cell that contains the following code: <details<summaryfile </summarydata= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) </details- Stage this code Make a change Open the diff view in the SCM pane Open the metadata view Type into the metadata view The metadata view closes before anything can be typed Is this expected?


Question: export namespace AccessibilityHelpNLS { export const accessibilityHelpTitle = nls.localize('accessibilityHelpTitle', "Accessibility Help"); <del> export const openingDocs = nls.localize("openingDocs", "Now opening the Accessibility documentation page."); </del> <ins> export const openingDocs = nls.localize("openingDocs", "Opening the Accessibility documentation page."); </ins> export const readonlyDiffEditor = nls.localize("readonlyDiffEditor", "You are in a read-only pane of a diff editor."); export const editableDiffEditor = nls.localize("editableDiffEditor", "You are in a pane of a diff editor."); export const readonlyEditor = nls.localize("readonlyEditor", "You are in a read-only code editor."); export const editableEditor = nls.localize("editableEditor", "You are in a code editor."); <del> export const changeConfigToOnMac = nls.localize("changeConfigToOnMac", "To configure the application to be optimized for usage with a Screen Reader press Command+E now."); export const changeConfigToOnWinLinux = nls.localize("changeConfigToOnWinLinux", "To configure the application to be optimized for usage with a Screen Reader press Control+E now."); </del> <ins> export const changeConfigToOnMac = nls.localize("changeConfigToOnMac", "Configure the application to be optimized for usage with a Screen Reader (Command+E)."); export const changeConfigToOnWinLinux = nls.localize("changeConfigToOnWinLinux", "Configure the application to be optimized for usage with a Screen Reader (Control+E)."); </ins> export const auto_on = nls.localize("auto_on", "The application is configured to be optimized for usage with a Screen Reader."); export const auto_off = nls.localize("auto_off", "The application is configured to never be optimized for usage with a Screen Reader."); export const screenReaderModeEnabled = nls.localize("screenReaderModeEnabled", "Screen Reader Optimized Mode enabled."); export const screenReaderModeDisabled = nls.localize("screenReaderModeDisabled", "Screen Reader Optimized Mode disabled."); <del> export const tabFocusModeOnMsg = nls.localize("tabFocusModeOnMsg", "Pressing Tab in the current editor will move focus to the next focusable element. Toggle this behavior by pressing {0}."); </del> <ins> export const tabFocusModeOnMsg = nls.localize("tabFocusModeOnMsg", "Pressing Tab in the current editor will move focus to the next focusable element. Toggle this behavior {0}."); </ins> export const tabFocusModeOnMsgNoKb = nls.localize("tabFocusModeOnMsgNoKb", "Pressing Tab in the current editor will move focus to the next focusable element. The command {0} is currently not triggerable by a keybinding."); export const stickScrollKb = nls.localize("stickScrollKb", "Run the command: Focus Sticky Scroll ({0}) to focus the currently nested scopes."); export const stickScrollNoKb = nls.localize("stickScrollNoKb", "Run the command: Focus Sticky Scroll to focus the currently nested scopes. It is currently not triggerable by a keybinding."); <del> export const tabFocusModeOffMsg = nls.localize("tabFocusModeOffMsg", "Pressing Tab in the current editor will insert the tab character. Toggle this behavior by pressing {0}."); </del> <ins> export const tabFocusModeOffMsg = nls.localize("tabFocusModeOffMsg", "Pressing Tab in the current editor will insert the tab character. Toggle this behavior {0}."); </ins> export const tabFocusModeOffMsgNoKb = nls.localize("tabFocusModeOffMsgNoKb", "Pressing Tab in the current editor will insert the tab character. The command {0} is currently not triggerable by a keybinding."); export const showAccessibilityHelpAction = nls.localize("showAccessibilityHelpAction", "Show Accessibility Help"); }


Question: override async run(accessor: ServicesAccessor): Promise<void> { const nativeHostService = accessor.get(INativeHostService); <ins> const window = getActiveWindow(); if (isAuxiliaryWindow(window)) { return nativeHostService.closeWindowById(await window.vscodeWindowId); } </ins> return nativeHostService.closeWindow(); } }

<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Version: 1.84.0-insider (user setup) Commit: Date: 2023-10-23T05:34:05.496Z Electron: 25.9.1 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: two workspaces a couple of files Active Editor into a New Window on the new window and Press Alt+F4 : aux window closes. Actual: VS Code closes the workspace and both windows associated with it.
Can you see if is assigned as keybinding? I assume this goes through our global window close handler that has not yet adopted aux windows.
I have default keybindings { "key": "alt+f4", "command": "" },


Question: .panel > .title .monaco-action-bar .action-item.viewpane-filter-container { max-width: 400px; <del> min-width: 300px; </del> <ins> min-width: 150px; </ins> margin-right: 10px; }

Issue Type: <bBug</bthe integrated console viewlets to a vertical layout the viewlet narrow When wide enough: ! Once narrowed: ! Expected result: Debug Console search bar shrinks/hides itself in order to show other tabs first (like in the first screenshot). The 3 dots "works", but is, at least in my opinion, more annoying than not being able to search in the Debug Console when the viewlet is narrow. VS Code version: Code 1.63.2 (, 2021-12-15T09:40:02.816Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<!-- generated by issue reporter --
The min width is 300, I think that can be narrower. The problems view filter input goes into the body when the view is too narrow, which is sorta cool <img width="571" alt="image" src="https://user-"but I won't implement that right now
Actually it was easy to opt into that. I tweaked the min widths and also when the pane is narrow, the filter box will move down into the body
Holy, I forgot about this issue! Love the idea of copying the behaviour of the Problems tab! Excited to try it on Insiders :) Thanks !


Question: ['.xhtml', 'application/xhtml+xml'], ['.oft', 'font/otf'], ['.xml', 'application/xml'], <ins> ['.wasm', 'application/wasm'], </ins> ]); export function getWebviewContentMimeType(resource: URI): string {

To load local resources (for example ones bundled with an extension), the  method must be used. As far as I can tell, when a URI produced in this way is requested by a webview, VSCode serves it via something like a local webserver. But there is no way to configure the MIME type that the URI gets served with. This request is to add a way to set the MIME type. This is important for extensions which want to load WebAssembly resources in the webview. The most efficient method to do so is , but this only works if the WASM blob is served as . So currently it doesn't seem possible to load WASM in a webview in this way. Since fallback methods may fail to cache WASM compilation results, I've measured that for a large WASM blob it's actually more efficient to load it from the internet via , as then subsequent loads reuse WASM compilation results, than it is to load it from a local resource.
/verified


Question: } } <del> return undefined; </del> <ins> return null; </ins> } private hasSelectedMarkerFor(resource: ResourceMarkers): boolean {

Testing Not sure if this lack of functionality blocks anything truly useful, but at least in the treeview, you can multi-select problems and copy them to the clipboard. In the table view you can't.
This also has the side effect of losing a multi-select that you may have had in the treeview.
what was the thinking for enabling multi-select in the problems treeview? Was there a particular scenario or this is what the default behaviour is for a treeview? If there is a real scenario, than we should enable multi-select in the table as well.
You can copy multiple problems is the primary use case.
that makes sense. Thanks!


Question: if (!resolveResult.bubble) { shouldPreventDefault = true; } <ins> this._log(`+ Invoking command ${resolveResult.commandId}.`); </ins> if (typeof resolveResult.commandArgs === 'undefined') { this._commandService.executeCommand(resolveResult.commandId).then(undefined, err => this._notificationService.warn(err)); } else {

Issue Type: <bBug</bI remapped command to [Alt + V]. And such keybinding doesn't work. KeybindingService log is as follows. Keybinding seems to pass through vscode to terminal since when I run in terminal it registers keypresses. VS Code version: Code 1.67.2 (, 2022-05-17T18:23:40.286Z) OS version: Linux x64 5.15.41-1-MANJARO Restricted Mode: No Remote OS version: Linux x64 4.19.119-30.2 <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This is working fine for me, I do see the warning that I don't understand though. any insights into what could be happening here? Could the soft dispatch teh terminal does be causing problems with this ignore single modifier thing?
Yes, I think is not dispatched through the keybinding service in this case. Looking again at the OP log: And comparing it with the output I see when binding to : Notice how the OP's log does not contain the keydown event for (i.e. this line ), but there are logs about being dispatched. I think the logs about being dispatched relate to the call the terminal does, but it looks to me that the keybinding service doesn't really get to dispatch the keyboard event, so it doesn't execute the command. I see how is making the log confusing so I will push a change to improve logging to better distinguish between and the real dispatch.
do you have or set in your
Yes I have enabled, but I didn't override . As far as I understand is included in by default.
It is but when is set to true it overrides as a convenience setting for users who use a lot of shell-based keybindings. If you're getting into needing to customize , I'd recommend setting back to false and tweaking instead. I checked the docs and it looks like this is already explained so I don't think there's anything we need to do on our end: !
ok, thanks a lot for your help


Question: args.push(`--author="${options.author}"`); } <ins> if (typeof options?.maxParents === 'number') { args.push(`--max-parents=${options.maxParents}`); } </ins> if (options?.refNames) { args.push('--topo-order'); args.push('--decorate=full');

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


Question: testIds: string[]; } <del> export const isStartControllerTests = (t: ICallProfileRunHandler | IStartControllerTests): t is IStartControllerTests => 'runIn' in t; </del> <ins> export const isStartControllerTests = (t: ICallProfileRunHandler | IStartControllerTests): t is IStartControllerTests => ('runId' as keyof IStartControllerTests) in t; </ins> /** * Request from the main thread to run tests for a single controller.

When I run all tests, the label resets back to after all tests were run. This is very confusing. !
This was a result of a bad filter function that caused all test runs to be treated extension-triggered. The "real" test run would then never have results, or get any output. More importantly, this results in "show test output" usually showing nothing. Taking this as a candidate. Essentially the sequence is: is triggered from the UI, so we prepare TestResults for incoming data and send the TestRunRequest precursor over to the EH EH doesn't associate that request with the existing run calls from its , which gets treated as a brand new run, so we make new TestResults for that run run and states get updated... 's resolves automatically marks the UI-triggered run as complete since the runHandler returned and there are no ongoing TestRuns latest completed TestResults is now the empty one that core created and was never updated so things that use the last result, like "show test output", are empty The code path in is meant to only be taken by the new Continuous Test runs, where the request is long-lived and doesn't have a single associated set of TestResults.


Question: async getExtensions(extensionInfos: ReadonlyArray<IExtensionInfo>, arg1: any, arg2?: any): Promise<IGalleryExtension[]> { const options = CancellationToken.isCancellationToken(arg1) ? {} : arg1 as IExtensionQueryOptions; const token = CancellationToken.isCancellationToken(arg1) ? arg1 : arg2 as CancellationToken; <ins> const result = await this.doGetExtensions(extensionInfos, options, token); const uuids = result.map(r => r.identifier.uuid); const extensionInfosByName: IExtensionInfo[] = []; for (const e of extensionInfos) { if (e.uuid && !uuids.includes(e.uuid)) { extensionInfosByName.push({ ...e, uuid: undefined }); } } if (extensionInfosByName.length) { // report telemetry data for additional query this.telemetryService.publicLog2< { count: number }, { owner: 'sandy081'; comment: 'Report the query to the the Marketplace for fetching extensions by name'; readonly count: { classification: 'SystemMetaData'; purpose: 'FeatureInsight'; comment: 'Number of extensions to fetch' }; }>('galleryService:additionalQueryByName', { count: extensionInfosByName.length }); const extensions = await this.doGetExtensions(extensionInfosByName, options, token); result.push(...extensions); } return result; } private async doGetExtensions(extensionInfos: ReadonlyArray<IExtensionInfo>, options: IExtensionQueryOptions, token: CancellationToken): Promise<IGalleryExtension[]> { </ins> const names: string[] = []; const ids: string[] = [], includePreReleases: (IExtensionIdentifier & { includePreRelease: boolean })[] = [], versions: (IExtensionIdentifier & { version: string })[] = []; let isQueryForReleaseVersionFromPreReleaseVersion = true; for (const extensionInfo of extensionInfos) {

Type: <bBug</bThis issue was supposed to be fixed in , but we have recently received complaints from some users regarding this. I counted the first 50 issues with Vue extension installed in , and 25 users are using 1.8.27 ~ 2.0.10 (2.0.10 was released 4 months ago ), only 19 users are using the latest version (2.0.22 ~ 2.0.28). Numbers: 2.0.10: 13 (Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue ) 2.0.8: 6 (Issue , Issue , Issue , Issue , Issue , Issue ) 2.0.7: 2 (Issue , Issue ) 2.0.6: 2 (Issue , Issue ) 1.8.27: 2 (Issue , Issue ) 2.0.22~2.0.28: 19 Since some versions in 2.0.0~2.0.10 may have serious problems, this is probably the reason why the Vue extension has continued to receive negative reviews on the Marketplace and VSCode has continued to receive bug reports about the Vue extension for several months. I found a Windows computer with 2.0.7 installed and was able to reproduce the issue of not being able to update the version. The following is the content of . (Formatted for easier reading) And I can reproduce the problem of not being able to update by overwriting the above metadata to the file of another macbook. is installed, uninstall it and then close VSCode and reopen it. 2.0.7 from https://open- and install it to VSCode, VSCode can normally prompt that Vue extension needs to be updated. and modify the metadata of the last extension to: VSCode will find that the Vue extension cannot detect newer versions. VS Code version: Code 1.92.1 (, 2024-08-07T20:16:39.455Z) OS version: Darwin arm64 23.1.0 Modes: <!-- generated by issue reporter --
cc
I just checked our telemetry for the most popular combinations of VS Code version and Vue extension version and here's what I see.


Question: async getExtensions(extensionInfos: ReadonlyArray<IExtensionInfo>, arg1: any, arg2?: any): Promise<IGalleryExtension[]> { const options = CancellationToken.isCancellationToken(arg1) ? {} : arg1 as IExtensionQueryOptions; const token = CancellationToken.isCancellationToken(arg1) ? arg1 : arg2 as CancellationToken; <ins> const result = await this.doGetExtensions(extensionInfos, options, token); const uuids = result.map(r => r.identifier.uuid); const extensionInfosByName: IExtensionInfo[] = []; for (const e of extensionInfos) { if (e.uuid && !uuids.includes(e.uuid)) { extensionInfosByName.push({ ...e, uuid: undefined }); } } if (extensionInfosByName.length) { // report telemetry data for additional query this.telemetryService.publicLog2< { count: number }, { owner: 'sandy081'; comment: 'Report the query to the the Marketplace for fetching extensions by name'; readonly count: { classification: 'SystemMetaData'; purpose: 'FeatureInsight'; comment: 'Number of extensions to fetch' }; }>('galleryService:additionalQueryByName', { count: extensionInfosByName.length }); const extensions = await this.doGetExtensions(extensionInfosByName, options, token); result.push(...extensions); } return result; } private async doGetExtensions(extensionInfos: ReadonlyArray<IExtensionInfo>, options: IExtensionQueryOptions, token: CancellationToken): Promise<IGalleryExtension[]> { </ins> const names: string[] = []; const ids: string[] = [], includePreReleases: (IExtensionIdentifier & { includePreRelease: boolean })[] = [], versions: (IExtensionIdentifier & { version: string })[] = []; let isQueryForReleaseVersionFromPreReleaseVersion = true; for (const extensionInfo of extensionInfos) {

This proves that vue version and are indeed not getting properly updated. The root cause of this is the fact the vue extension, unpublished from the Marketplace and published again the same name (thus exposing a bug in the Marketplace) as explained here We still want to help transition your users, and I will go ahead and move this issue to the VS Code repo and Sandeep will investigate next week once he is back from vacation. Thank you !
Update is not detected automatically. It is detected only when user is searching for the extension.
Sorry about this inconvenience caused. Fixed it - We will now detect the update automatically.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
I just tested it and confirmed it's fixed in the latest insiders version, thanks a lot!
Adding label based on above comment


Question: if (!this._loadEstimator.hasHighLoad()) { // Trash the socket this._lastSocketTimeoutTime = Date.now(); <del> this._onSocketTimeout.fire(undefined); </del> <ins> this._onSocketTimeout.fire({ unacknowledgedMsgCount: this._outgoingUnackMsg.length(), timeSinceOldestUnacknowledgedMsg, timeSinceLastReceivedSomeData }); </ins> return; } }

I've had an SSH window open in the background and noticed that it keeps going through reconnection. Looking at the logs, it looks like vscode is often triggering reconnection, even though nothing strange is going on with my network, as far as I know. Noticed this at home and also the office network. This is the log from vscode. The SSH log doesn't show anything unusual before the resolver is invoked again. Has anything changed here lately?
Sorry this issue fell through the cracks. Are you still running into this?
Yes
Do you perhaps have a log with tracing enabled? The reason in the original log appears to be timeout. That is triggered here -- So the conditions are: a message was written to the socket 20 seconds ago and the server side didn't acknowledge it (and) no data was received from the server within the past 20 seconds (and) no previous timeout event was fired within the past 20 seconds (this just avoid sending many timeout events) (and) the renderer process appears responsive (Just speculating) I think we have fixed something in the terminal land and we now no longer send any data in an idle window. Could it be that your window becomes idle and the connection is dropped by SSH? (I believe due to some terminal heartbeat mechanism there was always data being written every 5 seconds, but now that is no longer happening).
Well, now I can't repro it.
I've more logging via . Please keep an eye out. In case you hit this again, the logging will have more data.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Finally got it
It seems like the log message you touch didn't show up there. But, it does show up in an earlier reconnection in this window (before I enabled trace logging). So I'll just share the full logs This shows a window that was mostly idle with 2 reconnections, the second one had logging at the trace level enabled
Here's my interpretation: the management connection timed out at due to our own timeout logic. We wrote one message and that message didn't get acknowledged within 20s by the server. As an observation, the connection didn't receive any bytes from the server within 320s (5 minutes).


Question: if (!this._loadEstimator.hasHighLoad()) { // Trash the socket this._lastSocketTimeoutTime = Date.now(); <del> this._onSocketTimeout.fire(undefined); </del> <ins> this._onSocketTimeout.fire({ unacknowledgedMsgCount: this._outgoingUnackMsg.length(), timeSinceOldestUnacknowledgedMsg, timeSinceLastReceivedSomeData }); </ins> return; } }

this resulted in the core invoking on the SSH extension and the SSH extension replied with a new port i.e. instead of the previous . the extension host connection immediately closed at with code , indicating that perhaps the previous tunnel at was killed as part of invoking . Precisely 20 minutes later, at , both management and extension host connections receive a event from Chromium. I can't quite explain the first timeout, why would the server not acknowledge a message within 20 seconds? But the timing of the second disconnection seems to indicate to me that after 20 min of idleness, the underlying connection is closed. Anyone could be closing it: either on the client side by Chromium or the OS, either on the server side by nodejs or the OS, either by the SSH tunnel timing out. For the second disconnection I think we might need to do something to tackle . For a long time the terminal was doing a heartbeat mechanism which resulted in data being sent over the wire (and that would not make the connection idle), but that was fixed via Right now, if you are really idle in a window, the underlying connection will be idle too and I think the OS or someone closes it as idle after 20 minutes.
My best guess is some other weird optimization where network requests don't even get delivered when an app is in the background. I've noticed this in windows that are not focused
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!


Question: sbomBuildDropPath: $(Agent.BuildDirectory)/vscode-server-win32-$(VSCODE_ARCH) sbomPackageName: "VS Code Windows $(VSCODE_ARCH) Server" sbomPackageVersion: $(Build.SourceVersion) <del> condition: and(succeededOrFailed(), ne(variables['SERVER_PATH'], ''), ne(variables['VSCODE_ARCH'], 'arm64')) </del> <ins> condition: and(succeededOrFailed(), ne(variables['SERVER_PATH'], '')) </ins> displayName: Publish server archive - task: 1ES.PublishPipelineArtifact@1

It appears that this is possible now, and we should consider adopting this in VS Code ()
There is community interest:
Please add this!
Steps for verification: Connect to Windows arm64 using the latest pre-release of SSH extension () Verify that connection is successful Use or similar tool to confirm that executable is of architecture.


Question: } widget.focus(focusedItem); <del> const responseContent = isResponseVM(focusedItem) ? focusedItem.response.value : undefined; </del> <ins> const isWelcome = focusedItem instanceof ChatWelcomeMessageModel; let responseContent = isResponseVM(focusedItem) ? focusedItem.response.value : undefined; if (isWelcome) { const welcomeReplyContents = []; for (const content of focusedItem.content) { if (Array.isArray(content)) { welcomeReplyContents.push(...content.map(m => m.message)); } else { welcomeReplyContents.push((content as IMarkdownString).value); } } responseContent = welcomeReplyContents.join('n'); } </ins> if (!responseContent) { return false; }

One way of resolving this would be repeating the position information when I press any of the commands, even if there is no change. Another possibility would be to prevent the widget from refocusing when I am in the first / last element, and I try to move beyond that element. In that way pressing the next command will not produce any feedback if I am in the last one, and the previous will not produce any feedback if I am in the first one. Does it make sense? In any case, this would be a refinement, not something that would prevent someone from using the feature. Originally posted by in
Something else to consider when fine tuning the responses. Right now, position information is announced using an alert in macOS, and a status message in Windows. This is a situation where it makes sense to use an alert in all platforms so that screen readers prioritize this over other events. For example, right now JAWS is announcing position information after reannouncing the widget.
Huh, I'm using for all platforms here which appears to be platform agnostic I think it might just be a JAWS issue - does this repro when using NVDA?
It doesn't, but NVDA handles aria-live differently. You may be right dough. I'll debug NVDA on Monday and we'll know for sure which event it is seeing. JAWS may be simply prioritizing the focus event.
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Focus an accessible view for which there are several elements (like chat responses or notifications). Verify that if you are on the first or last element, pressing next or previous does not result in repeated alerts. it should not notify the screen reader user as nothing has changed.
Note to verifier there's an issue to disable these actions when they cannot be taken, which is the better fix.
Verified. With NVDA, if I press enter on the Next button while on the last chat response, the focus goes back to the response text instead of staying on the button, though that might be by design.


Question: private getItemIndexFromEventTarget(target: EventTarget | null): number | undefined { const scrollableElement = this.scrollableElement.getDomNode(); <del> let element: HTMLElement | null = target as (HTMLElement | null); </del> <ins> let element: HTMLElement | SVGElement | null = target as (HTMLElement | SVGElement | null); </ins> <del> while (isHTMLElement(element) && element !== this.rowsContainer && scrollableElement.contains(element)) { </del> <ins> while ((isHTMLElement(element) || isSVGElement(element)) && element !== this.rowsContainer && scrollableElement.contains(element)) { </ins> const rawIndex = element.getAttribute('data-index'); if (rawIndex) {

Testing <img width="290" alt="image" src=""I feel like this context menu should not show up in this case - and in fact, it doesn't if you right click on the commit message to the right... it just repros when you right click on the graph part (the dots, or the lines)


Question: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import 'mocha'; import { ExtensionContext, extensions } from 'vscode'; suite('vscode API - globalState / workspaceState', () => { let extensionContext: ExtensionContext; suiteSetup(async () => { // Trigger extension activation and grab the context as some tests depend on it await extensions.getExtension('vscode.vscode-api-tests')?.activate(); extensionContext = (global as any).testExtensionContext; }); test.only('state', async () => { for (const state of [extensionContext.globalState, extensionContext.workspaceState]) { let keys = state.keys(); assert.strictEqual(keys.length, 0); let res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'default'); await state.update('state.test.get', 'testvalue'); keys = state.keys(); assert.strictEqual(keys.length, 1); assert.strictEqual(keys[0], 'state.test.get'); res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'testvalue'); await state.update('state.test.get', undefined); keys = state.keys(); assert.strictEqual(keys.length, 0); res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'default'); } }); }); </ins>

<!-- Please search existing issues to avoid creating duplicates. --- VS Code version: 1.59.1 Extension version (available under the Extensions sidebar): v2021.8. OS and version: Linux x64 5.13.11-1-MANJARO Python version (& distribution if applicable, e.g. Anaconda): 3.9 Type of virtual environment used (N/A ...): virtualenvwrapper Relevant/affected Python-related VS Code extensions and their versions: pylance v2021.8.3, jupyter v2021.8., Visual Studio IntelliCode v1.2.14 Value of the setting: Pylance from the VS Code marketplace to see if that fixes your issue] Extension loads successfuly Extension does not load, console reports "Unexpected token ' in JSON at position " [NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue] the extension by clicking a .py file <!-- Note: If you think a GIF of what is happening would be helpful, consider tools like , or . --<details<summaryOutput for <codePython</codein the <codeOutput</codepanel (<codeView</code→<codeOutput</code, change the drop-down the upper-right of the <codeOutput</codepanel to <codePython</code) </summary<p</p</details
Looks like you might have a bad update. Do the following to remove stale versions of the extension: Python extension (if you have pylance uninstall it first). all instances of VS Code. to, (on windows) or on Linux/Mac. any folder with the name starting with VS Code, and install Python extension (also pylance if you uninstalled it in step 1).
I followed all steps, but nothing changed. should I try to install older version of python ext?
Hi Can you try installing an older version of the Python extension, and if it doesn't work can you try a different version of VS Code (either an old one or the Insiders build)?
I've installed python extension , jupyter and no pylance. here's the log: As you said I'm going to install older version of vscode
Hi Did you try installing an older version of VS Code?
FYI - This looks like some JSON stored via the became corrupt.


Question: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import 'mocha'; import { ExtensionContext, extensions } from 'vscode'; suite('vscode API - globalState / workspaceState', () => { let extensionContext: ExtensionContext; suiteSetup(async () => { // Trigger extension activation and grab the context as some tests depend on it await extensions.getExtension('vscode.vscode-api-tests')?.activate(); extensionContext = (global as any).testExtensionContext; }); test.only('state', async () => { for (const state of [extensionContext.globalState, extensionContext.workspaceState]) { let keys = state.keys(); assert.strictEqual(keys.length, 0); let res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'default'); await state.update('state.test.get', 'testvalue'); keys = state.keys(); assert.strictEqual(keys.length, 1); assert.strictEqual(keys[0], 'state.test.get'); res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'testvalue'); await state.update('state.test.get', undefined); keys = state.keys(); assert.strictEqual(keys.length, 0); res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'default'); } }); }); </ins>

The JSON is written a few lines lower, so it is unexpected that the value is corrupted. This might indicate some kind of bug in the storage layer. I don't remember writing that code, did you perhaps write that? Do you think it is so important such to fail extension activation when the JSON is corrupt, or should we catch that exception and return ?
I would suggest to be more resilient in extension activation as you suggest and fallback to an empty object here if any error rises from but log it as error: This is the first time I hear about a problem with persisting data into SQLite. However, seeing makes me think that this is not an officially supported Linux distribution.
curious if you could share the following 2 files with me (via e-mail is fine: find it on ). Steps: open the VSCode window where this issue happens View Command Palette =Log Storage Database Contents Help Toggle Dev Tools Find the 2 paths for the DBs send both files to me
I can still see the original issue in vscode-insiders v1.61.0-insider
whats the exact version you are on? And is it the issue that the extension fails to activate?
Version: 1.61.0-insider (user setup) Commit: Date: 2021-09-16T08:31:28.161Z Electron: 13.4.0 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: WindowsNT x64 10.0. python extension: v2021.9. Error 2021-09-16 17:51:12: Error discovering pytest tests: [SyntaxError: Unexpected token S in JSON at position at (<anonymous) at a.runTestDiscovery (PATH.vscode-insidersextensionsms-outclient) at runMicrotasks (<anonymous) at processTicksAndRejections () at async (index 0) at async _.refreshTestData (PATH.vscode-insidersextensionsms-outclient) at async v.refreshTestDataInternal (PATH.vscode-insidersextensionsms-outclient)] { stdout: '[{"rootid": ".", "root": "...
I fixed the issue as reported in that extensions fail to activate when the contents in storage fail to get parsed.


Question: <ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ import * as assert from 'assert'; import 'mocha'; import { ExtensionContext, extensions } from 'vscode'; suite('vscode API - globalState / workspaceState', () => { let extensionContext: ExtensionContext; suiteSetup(async () => { // Trigger extension activation and grab the context as some tests depend on it await extensions.getExtension('vscode.vscode-api-tests')?.activate(); extensionContext = (global as any).testExtensionContext; }); test.only('state', async () => { for (const state of [extensionContext.globalState, extensionContext.workspaceState]) { let keys = state.keys(); assert.strictEqual(keys.length, 0); let res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'default'); await state.update('state.test.get', 'testvalue'); keys = state.keys(); assert.strictEqual(keys.length, 1); assert.strictEqual(keys[0], 'state.test.get'); res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'testvalue'); await state.update('state.test.get', undefined); keys = state.keys(); assert.strictEqual(keys.length, 0); res = state.get('state.test.get', 'default'); assert.strictEqual(res, 'default'); } }); }); </ins>

What you report here seems different to me. Looks like the python extension is calling on something that is not valid JSON? Have you asked the Python extension what this could be?
I see, I'll create a new issue. thanks


Question: dependencies: object-keys "~0.4.0" <del> xterm-addon-canvas@0.4.0-beta.9: version "0.4.0-beta.9" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.4.0-beta.9.tgz#e570fa4592890f92cc86706f2bba0dd128a8641d" integrity sha512-BWRVWyUW7NY2g4BBMm3ecPQvbdyKXFgABnpmh4m0TVHqFJMNeXdNuTc94KiDbE+cvw8jtAY9NC/OIM4HcgjAIQ== </del> <ins> xterm-addon-canvas@0.4.0-beta.11: version "0.4.0-beta.11" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.4.0-beta.11.tgz#d627050d7e2290ae804c0ec730d5bfc5861afd78" integrity sha512-yfkx0R7wB3L+fWf1doDmEfwYIeNMVq4uXlq7sCvfPQAVA2H4eOH/s+SS1mhyy0A6DDEbM4eEQ7CroRZIsnVtMA== </ins> xterm-addon-search@0.11.0: version "0.11.0"

Does this issue occur when all extensions are disabled?: Yes VS Code Version: OS Version: Steps to Reproduce: a terminal window within vscode and run this command: vscode hangs indefinitely, using 100% CPU on one core. It would be nice if that didn't happen.
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'm using web version (Vscode Server) and this code snippet cause the entirely browser tab to crash: ! Wanted to provide profiling info but profiler hanged too
I can reproduce
Nice find
Upstream:


Question: } private async checkAndGetCompatible(extension: IGalleryExtension, includePreRelease: boolean): Promise<IGalleryExtension> { <del> const compatible = await this.galleryService.getCompatibleExtension(extension, includePreRelease, await this.getTargetPlatform()); if (compatible) { if (includePreRelease && !compatible.properties.isPreReleaseVersion && extension.hasPreReleaseVersion) { </del> <ins> const targetPlatform = await this.getTargetPlatform(); let compatibleExtension: IGalleryExtension | null = null; if (extension.hasPreReleaseVersion && extension.properties.isPreReleaseVersion !== includePreRelease) { compatibleExtension = (await this.galleryService.getExtensions([{ ...extension.identifier, preRelease: includePreRelease }], { targetPlatform, compatible: true }, CancellationToken.None))[0] || null; } if (!compatibleExtension && await this.galleryService.isExtensionCompatible(extension, includePreRelease, targetPlatform)) { compatibleExtension = extension; } if (!compatibleExtension) { compatibleExtension = await this.galleryService.getCompatibleExtension(extension, includePreRelease, targetPlatform); } if (compatibleExtension) { if (includePreRelease && !compatibleExtension.properties.isPreReleaseVersion && extension.hasPreReleaseVersion) { </ins> throw new ExtensionManagementError(localize('notFoundCompatiblePrereleaseDependency', "Can't install pre-release version of '{0}' extension because it is not compatible with the current version of {1} (version {2}).", extension.identifier.id, this.productService.nameLong, this.productService.version), ExtensionManagementErrorCode.IncompatiblePreRelease); } } else {

VSCode Version: Version: 1.67.0-insider (Universal) Commit: Date: 2022-04-06T05:15:27.397Z (8 hrs ago) Local OS Version: macOs 12.3.1 / arm Remote OS Version: Centos 7 Remote Extension/Connection Type: SSH Logs: Steps to Reproduce: SSH Session the popup, hey Python and Jupyter extensions have pre-release versions or install / switch to pre-release on the extension page Error (but the extensions shows the pre-release state), but afaik that's not the case Note: I removed the vs code server on the remote host and did a new installation (starting from locally with the remote extensions versions), but it actually just installs the stable version on the remote and then the switch is not possible. It should actually consider and install the same version that is used locally, shouldn't it? Can't install pre-release version of 'ms-toolsai.jupyter' extension because it is not compatible with the current version of Visual Studio Code - Insiders (version 1.67.0-insider). Does this issue occur when you try this locally?: No Does this issue occur when you try this locally and all extensions are disabled?:No logs: [2022-04-06 15:51:45.599] [renderer1] [info] Downloading the 'ms-toolsai.jupyter' extension locally and install [2022-04-06 15:51:45.626] [renderer1] [error] Can't install pre-release version of 'ms-toolsai.jupyter' extension because it is not compatible with the current version of Visual Studio Code - Insiders (version 1.67.0-insider).: IncompatiblePreRelease: Can't install pre-release version of 'ms-toolsai.jupyter' extension because it is not compatible with the current version of Visual Studio Code - Insiders (version 1.67.0-insider).


Question: } private async checkAndGetCompatible(extension: IGalleryExtension, includePreRelease: boolean): Promise<IGalleryExtension> { <del> const compatible = await this.galleryService.getCompatibleExtension(extension, includePreRelease, await this.getTargetPlatform()); if (compatible) { if (includePreRelease && !compatible.properties.isPreReleaseVersion && extension.hasPreReleaseVersion) { </del> <ins> const targetPlatform = await this.getTargetPlatform(); let compatibleExtension: IGalleryExtension | null = null; if (extension.hasPreReleaseVersion && extension.properties.isPreReleaseVersion !== includePreRelease) { compatibleExtension = (await this.galleryService.getExtensions([{ ...extension.identifier, preRelease: includePreRelease }], { targetPlatform, compatible: true }, CancellationToken.None))[0] || null; } if (!compatibleExtension && await this.galleryService.isExtensionCompatible(extension, includePreRelease, targetPlatform)) { compatibleExtension = extension; } if (!compatibleExtension) { compatibleExtension = await this.galleryService.getCompatibleExtension(extension, includePreRelease, targetPlatform); } if (compatibleExtension) { if (includePreRelease && !compatibleExtension.properties.isPreReleaseVersion && extension.hasPreReleaseVersion) { </ins> throw new ExtensionManagementError(localize('notFoundCompatiblePrereleaseDependency', "Can't install pre-release version of '{0}' extension because it is not compatible with the current version of {1} (version {2}).", extension.identifier.id, this.productService.nameLong, this.productService.version), ExtensionManagementErrorCode.IncompatiblePreRelease); } } else {

at l.checkAndGetCompatible (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async l.downloadAndInstall (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async l.installFromGallery (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async (index 0) at async Object.j [as settled] (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async Ms.installFromGallery (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-)
Would you mind sharing your Remote SSH logs as well? And if you have any gifs or videos of what you're seeing?
! ! And this - but it's just a "refresh" problem, once I switch between extensions it shows the old and unfortunately correct version again: ! And logs...
Your SSH connection looks successful. I'll transfer this issue to the Python extension team to see if they have ideas why this state is happening
This is an error thrown by VS Code, not sure what an extension can do about this as installing extensions is completely managed by VS Code. I'm transferring this back to VS Code.
Same issue happends to me.
I was able to install this manually (remote) by downloading the new extension that I got from this link: By this, you'll switch to the pre-release version. After installing it once manually, all updates work as usual.
Can you please try our latest insiders and see if you can reproduce this issue still?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Sorry, I had it already solved and thought it wouldn't occur again + I moved away from using Remote SSH whenever I could. I am now on the latest 1.68 insiders and for whatever reason the jupyter extension reverted to "non pre-release" and the same issue still exists - same error. Same workaround as above fixed the issue for me.
Were you using any remote set up when this happened again? Are you still able to repro it?
Yeah, it's exactly the same setup, just updated (yesterday's) insider build.


Question: } private async checkAndGetCompatible(extension: IGalleryExtension, includePreRelease: boolean): Promise<IGalleryExtension> { <del> const compatible = await this.galleryService.getCompatibleExtension(extension, includePreRelease, await this.getTargetPlatform()); if (compatible) { if (includePreRelease && !compatible.properties.isPreReleaseVersion && extension.hasPreReleaseVersion) { </del> <ins> const targetPlatform = await this.getTargetPlatform(); let compatibleExtension: IGalleryExtension | null = null; if (extension.hasPreReleaseVersion && extension.properties.isPreReleaseVersion !== includePreRelease) { compatibleExtension = (await this.galleryService.getExtensions([{ ...extension.identifier, preRelease: includePreRelease }], { targetPlatform, compatible: true }, CancellationToken.None))[0] || null; } if (!compatibleExtension && await this.galleryService.isExtensionCompatible(extension, includePreRelease, targetPlatform)) { compatibleExtension = extension; } if (!compatibleExtension) { compatibleExtension = await this.galleryService.getCompatibleExtension(extension, includePreRelease, targetPlatform); } if (compatibleExtension) { if (includePreRelease && !compatibleExtension.properties.isPreReleaseVersion && extension.hasPreReleaseVersion) { </ins> throw new ExtensionManagementError(localize('notFoundCompatiblePrereleaseDependency', "Can't install pre-release version of '{0}' extension because it is not compatible with the current version of {1} (version {2}).", extension.identifier.id, this.productService.nameLong, this.productService.version), ExtensionManagementErrorCode.IncompatiblePreRelease); } } else {

And yes, if I uninstall the extension, install release, try to switch, the same happens over and over again. I discovered another bug: switch back to stable is not possible [2022-05-24 12:03:11.208] [remoteagent] [warning] Overwriting user extension with It always pushes me back to the pre-release. I think this may be related to keep local/remote on the same version/track. EDIT: Okay, actually this blocks everyone using insiders with the jupyter and/or other plugins in combination with remote ssh. Since insiders are updated daily, the "vs code server" is updated daily and the plugin is revert/installed again in the non preview version. So my hotfix has to applied daily which is really annoying. EDIT 2: I realised that the current (release today) stable "jupyter" version also has the latest insiders api implemented. So for now and for me that is solved - but the actual bug is still there, I can't switch to pre-release versions in a remote ssh setup.
Sorry that you are having this annoying issue and glad that you are able to reproduce it so that we can investigate. If you don't mind, can you please summarise your repro steps?
So, I now understand why it's a bit complex to reproduce this - I guess... I was even confused myself. So, currently the only way to reproduce it was for me: 1) deinstall the server (rm -rf .vscode-insiders-server) 2) connect/install + install jupyter extensions (local: pre-release) -pre-release installation successful 3) switch to release on remote 4) reload window -I am then on release try to switch to pre-release -issue appears. And now the important part: I realised that I still had the setting because within our company we had restrictions before... setting this to false also fixes the issue - even when it appeared before.
Thanks for the steps. I can reproduce it now and fixed. To verify: Open a remote window and set setting Install pre-release of ESLint extension Reload window Switch to release version of ESLint extension Reload window Switch to pre-release version of ESLint extension Make sure switch happens


Question: i = wrappedLineEnd; lines.push(getXtermLineContent(buffer, wrappedLineStart, wrappedLineEnd, cols)); if (!match) { <del> match = lines.join('n').match(matcher); </del> <ins> match = lines[lines.length - 1].match(matcher); </ins> } <del> if (wrappedLines >= linesToCheck) { </del> <ins> if (lines.length >= linesToCheck) { </ins> break; } }

going to keep track of examples here to see if there's a pattern <img width="1112" alt="Screenshot 2023-01-23 at 2 12 18 PM" src="https://user-"
far right terminal <img width="1120" alt="Screenshot 2023-01-23 at 3 07 17 PM" src="https://user-"
middle terminal !
far right terminal !
far right terminal <img width="1076" alt="Screenshot 2023-01-24 at 1 59 40 PM" src="https://user-"
right terminal <img width="1644" alt="Screenshot 2023-01-24 at 2 22 27 PM" src="https://user-"
right terminal !
here are the lines when there's not a quick fix result - it contains after which we don't account for here !
Seeing this frequently: <img width="726" alt="image" src="https://user-"
I think we just need to include the to fix this
or better yet, remove and just look for the link
ok I see the issue. when lines are wrapped a lot, we need to search more lines - setting the length to 10/15 fixes it even when the terminal is quite narrow
I see it on non-wrapped lines, I'm not sure I understand what you mean with the To?
The to comment above was actually wrong. What's happened in the screen shot above is we abort the search early - after looking at only 5 lines. When it's actually on line 9
this goes wrong when we break before reaching the content IE when line count length
I tried pushing up a new branch using pwsh in the integrated terminal on Windows, and the lightbulb did not show. !
you have shell integration disabled, it won't work at all there.
also make sure to not move issues to the next milestone, this one was marked important
Working much better now, but just reproduced !
Just happened and captured the trace log (escape sequence log would be better): <img width="806" alt="image" src="https://user-"
I've seen this not work twice today already for create PR !
even though the lightbulb didn't appear here, there was a match found !


Question: i = wrappedLineEnd; lines.push(getXtermLineContent(buffer, wrappedLineStart, wrappedLineEnd, cols)); if (!match) { <del> match = lines.join('n').match(matcher); </del> <ins> match = lines[lines.length - 1].match(matcher); </ins> } <del> if (wrappedLines >= linesToCheck) { </del> <ins> if (lines.length >= linesToCheck) { </ins> break; } }

the match always happens, the lightbulb doesn't show up though until I resize the terminal
this happens when the have not yet been resolved by the time occurs ! !
I think we should be calling at the end of
have seen the create PR not show up 3 times today. resizing doesn't cause it to show up, which means our match range is wrong/ there isn't a match
this says unreleased, but was merged before the current version of insider's (5 hours ago) was released. create with PR still failing !
insider's is based on the release branch, so I was confused
<!-- UNABLETOLOCATECOMMITMESSAGE issue --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased