jiebi/CodeConvo huggingface dataset:
Code change:
import { WorkbenchState, IWorkspaceContextService } from 'vs/platform/workspace/common/workspace'; import { coalesce } from 'vs/base/common/arrays'; import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; <ins> import { ITextFileService } from 'vs/workbench/services/textfile/common/textfiles'; import { isEqual } from 'vs/base/common/resources'; </ins> const TextInputActions: IAction[] = [ new Action('undo', nls.localize('undo', "Undo"), undefined, true, () => Promise.resolve(document.execCommand('undo'))),

Related discussion:
text: VSCode Version: 1.33.1 OS Version: 10.14.4 When editing and closing a git commit message file very quickly, the contents are not provided to git. Currently I manually save before closing any git commit file but it seems clear this should work properly - autosave should happen, then Code should inform Git that the commit file is ready. Currently it appears the two events are happening in reverse order, causing a bug. Steps to Reproduce: VS Code as editor () a git commit the commit message in Code close the commit message in Code, before autosave occurs Result: git complains about an empty commit message Expected: Autosave should happen before Code releases control back to git, resulting in a properly saved commit message Does this issue occur when all extensions are disabled?: Yes
Good catch. Extra points for using auto save in VSCode :+1:
via
Code change:
const CONFIG_HELP_TEXT_PRE = `// Links matching one or more entries in the list below can be opened without link protection. // The following examples show what entries can look like: // - "https://microsoft.com": Matches this specific domain using https <ins> // - "https://microsoft.com:8080": Matches this specific domain on this port using https // - "https://microsoft.com:*": Matches this specific domain on any port using https </ins> // - "https://microsoft.com/foo": Matches https://microsoft.com/foo and https://microsoft.com/foo/bar, //   but not https://microsoft.com/foobar or https://microsoft.com/bar // - "https://*.microsoft.com": Match all domains ending in "microsoft.com" using https // - "microsoft.com": Match this specific domain using either http or https // - "*.microsoft.com": Match all domains ending in "microsoft.com" using either http or https <ins> // - "http://192.168.0.1: Matches this specific IP using http // - "http://192.168.0.*: Matches all IP's with this prefix using http </ins> // - "*": Match all domains using either http or https // `;

Related discussion:
text: Issue Type: <bBug</bWrite http://192.168.1.7:3000/ into a text file. Command-click it to try to open the link. You will get an alert asking whether you want to open the external website. Click “Configure Trusted Domains”. <img width="1025" alt="link and dialog asking to confirm opening external website" src="https://user-"Look at the second option in the menu. It says “Trust 1.7:3000 and all its subdomains”. But 1.7:3000 is not a valid address. <img width="1024" alt="link and menu with buggy entry “Trust 1.7:3000 and all its subdomains”" src="https://user-"I can only guess that VS Code thinks that “7” is a TLD and “1.7” is a full domain name. What I actually want to do is whitelist opening all links to IP addresses like . In other words, white-list the subnet . At least, I think that makes sense. But I am not a network engineer, so if it makes more sense to recommend to the user whitelisting some other subnet such as , or whitelisting only the address but on any port, that would be fine too. VS Code version: Code 1.40.1 (, 2019-11-13T16:47:44.719Z) OS version: Darwin x64 18.7.0 <!-- generated by issue reporter --
Code change:
} getScopedEnvironmentVariableCollection(scope: vscode.EnvironmentVariableScope | undefined): IEnvironmentVariableCollection { <ins> if (this._extension && scope) { // TODO: This should be removed when the env var extension API(s) are stabilized checkProposedApiEnabled(this._extension, 'envCollectionWorkspace'); } </ins> const scopedCollectionKey = this.getScopeKey(scope); let scopedCollection = this.scopedCollections.get(scopedCollectionKey); if (!scopedCollection) {

Related discussion:
text: It's used in , this would be easiest after that's merged.
I wish instead of explicitly checking whether proposed API is enabled in in the implementation, we could check it when checking distro for whether an extension is allowed a proposal instead.
the list of allowed extensions is not available in code - oss though on local or in CI
That's fair but do we really need to check in code - oss when developing? I would think is being tested out in the final build that's published.
not my area but being strict is good for proposals and it's good to align oss with the product in areas like this. Consider a fork of VS Code that does not have the check, extensions could use the proposals without warning which could lead to easy breakages.
Code change:
}); } await this.storeForwarded(); <ins> this.checkExtensionActivationEvents(); </ins> this.remoteTunnels.set(key, tunnel); this._onForwardPort.fire(this.forwarded.get(key)!); })); this._register(this.tunnelService.onTunnelClosed(address => { return this.onTunnelClosed(address, TunnelCloseReason.Other); })); <del> this.checkExtensionActivationEvents(); </del> } private extensionHasActivationEvent() {

Related discussion:
text: Type: <bBug</bvscode with wsl: or similar tool to monitor CPU usage when vscode is idle or minimized to the taskbar. Expected: CPU usage for vscode's remote server should stay around 0% at idle conditions. Actual: CPU usage stays between 2-10 % VS Code version: Code 1.91.1 (, 2024-07-09T22:06:49.809Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 6.6.36.3-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (10)</summaryExtensionVersion ------ remote-wsl0.88.2 material-icon-theme5.6.0 vim1.27.3 markdown-checkbox0.4.0 gitlens15.2.0 prettier-vscode10.4.0 hexeditor1.10.0 advanced-new-file1.2.2 vscode-fileutils3.10.3 even-better-toml0.19.2 </details<!-- generated by issue reporter --
I had earlier opened the issue at where I provided more in-depth issue description. I'm just going to put the same description here. I recently noticed high CPU usage and faster battery drain (intel cpu) when working with any project under WSL. To find out what's taking so much cpu time (even when I'm doing nothing, apart from staring at the screen), I used to list processes in the order of cpu usage: ! Looked like vscode's remote server running inside wsl is taking CPU. So, I went a little further to profile the running instance of the remote server and I found: ! ! from is being called at a regular interval with a small delay (~1000ms). : ! I was able to trace back to : ! And I finally found where it is being called repeatedly: ! Now, why is it a bug? Because I've disabled all related settings in my config, yet the tunnel monitoring service is running in the background. I expect the service to not be running when or related configs are disabled. The service is currently always running.
Wow, great job, thanks for tracking down the problem!
I'm having trouble understanding this: Is WSL going to end up being a ?
Code change:
}); } await this.storeForwarded(); <ins> this.checkExtensionActivationEvents(); </ins> this.remoteTunnels.set(key, tunnel); this._onForwardPort.fire(this.forwarded.get(key)!); })); this._register(this.tunnelService.onTunnelClosed(address => { return this.onTunnelClosed(address, TunnelCloseReason.Other); })); <del> this.checkExtensionActivationEvents(); </del> } private extensionHasActivationEvent() {

Related discussion:
text: I don't think we actually want to show the ports view in WSL even if the Tunnels extension isn't installed.
I agree. For non-managed remote authorities created just via the in the workbench, how did we determine whether or not to show the ports view? We should apply the same logic here...
The ports view is controlled by a context key getting set. It gets set in two ways: an extension that wants the ports view. This is what dev containers does. a tunnel factory getting . Since the tunnel factory is always now, we're always enabling it. I should be able to add a check if the tunnel factory is coming from an extension and only do 2 if that's the case.
Looks like we also show the ports view when there's an extension with an actiation event: Is this perhaps no longer needed with the work you did for tunnels I don't remember exactly why I it.
I've moved the check to happen when there's been a port forwarded.
Looks like this was actually a feature: You can set to disable this. I'm also going to try to improve the description of and .
<!-- 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!
To verify: the descriptions of and . Verify that you can understand what the settings do and how they're related. (These settings may be a bit confusing. We should consider deprecating and only have ) . to or if it isn't already. the WSL extension, connect to a WSL remote. the log level to Trace for the Remote Extension Host. the output for the Remote Extension Host. Verify that you see a steady stream of log lines that say "candidate" coming in. This means that port discovery is on. to and to . Reload. sure that the log level of the Remote Extension Host is still set to Trace the output for the Remote Extension Host. Verify that you DO NOT see a steady stream of log lines that say "candidate" coming in.
Code change:
}); } await this.storeForwarded(); <ins> this.checkExtensionActivationEvents(); </ins> this.remoteTunnels.set(key, tunnel); this._onForwardPort.fire(this.forwarded.get(key)!); })); this._register(this.tunnelService.onTunnelClosed(address => { return this.onTunnelClosed(address, TunnelCloseReason.Other); })); <del> this.checkExtensionActivationEvents(); </del> } private extensionHasActivationEvent() {

Related discussion:
text: In the WSL workspace, I don't see any log lines that say "candidate" even after starting a Python HTTP server.
I can't repro this. Do you have an old version of WSL installed?
I verified that on my machine the work.
I haven't checked with Insider, but in stable I can confirm 'candidate' logs are not visible after Step 6 of the verification steps. Thanks. I also want to point out that it's not clear from the description that there's a process monitoring service running in the background, and that it can be disabled using . Should the default option be instead of ?
Thanks for trying it out If we set it to , then we might end up not showing any ports in the Ports view. In insiders, I updated the text of the setting: Sets the source from which ports are automatically forwarded when is true. When is false, will be used to find information about ports that have already been forwarded. On Windows and macOS remotes, the process and hybrid options have no effect and output will be used. It still doesn't explicitly say there will be process monitoring, but it should be clearer.
Code change:
*/ app.commandLine.appendSwitch('disable-features', 'CalculateNativeWinOcclusion'); <del> /* Following features are enabled from the runtime. * `AutoDisableAccessibility` - https://github.com/microsoft/vscode/issues/162331#issue-1390744354 */ app.commandLine.appendSwitch('enable-features', 'AutoDisableAccessibility'); </del> // Support JS Flags const jsFlags = getJSFlags(cliArgs); if (jsFlags) {

Related discussion:
text: Type: <bBug</bWindows 10, screen reader is NVDA, most recent insider build, as of December 13, 2022. The first time I start vscode for the day, after a short time (about 3 minutes), my screen reader stops speaking. If I press nvdaKey+tab (read current focus), it says "setup", but nothing else and I can't do anything. If I cancel out, I get back to vscode, but now every minute or so, my keyboard locks up, again with no speech. The only way now to get things going again is to switch away from vscode via alt+tab, then back again. I cannot see the screen, so cannot give any more info, but I'll bet whatever that setup window that came up first was, it's coming up again... Sorry I can't be more specific... VS Code version: Code - Insiders 1.75.0-insider (, 2022-12-13T05:22:12.417Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I cannot reproduce this. I am wondering if you are not in mode. Can you check the value of in your settings and make sure it's set to ?
I can verify this issue, also with NVDA on Windows 10. It occurs both with the latest insiders and with the production 1.74.0. And yes accessibility support is enabled. The symptom is usually that the screen reader simply stops reading anything after a period of time, and it can be temporarily fixed by minimizing the window or switching to another then going back to vscode. I've also had the symptom where it will keep reading the same line after consecutive down or up arrow presses even though the cursor is clearly moving to the next or previous line. cc:
Symptoms point to running with experiment as the cause. Can you try starting with and see if the issue persists ?
Disabling that feature seems to have no effect. The problem persists. I'm also noticing that I can get NVDA to start reading again if I switch context (e.g. stops reading in file editor, switch to terminal then back, reading usually resumes).
Code change:
*/ app.commandLine.appendSwitch('disable-features', 'CalculateNativeWinOcclusion'); <del> /* Following features are enabled from the runtime. * `AutoDisableAccessibility` - https://github.com/microsoft/vscode/issues/162331#issue-1390744354 */ app.commandLine.appendSwitch('enable-features', 'AutoDisableAccessibility'); </del> // Support JS Flags const jsFlags = getJSFlags(cliArgs); if (jsFlags) {

Related discussion:
text: I also have this problem in stable version 1.74. In many occasions I can't read the current line. In addition to losing focus, when returning from another window, the file browser and line navigation, when it works, becomes much slower. I have to restart NVDA every time that happens and it fixes it, but it is annoying and interrupts a lot of work. I would appreciate a quick solution please
Running new build with potential fix for testing, will update here once the builds are available.
Can you test if the issue persists with the following insiders build, please make sure turn off updates temporarily in your settings with
These are terrible bugs i've encountered on production 1.74. The most annoying one for me was NVDA were trying to read whole document from top to bottom when ever I press up or down arrow. With the given insider 1.75 link above, it looks fine for now. It also feels a bit faster than the usual vscode, out of topic.
Thanks for filling this issue. I tried to reproduce with latest Insiders, NVDA on my Win10 VM and I could not repro, here are my steps. on NVDA, VS Code insiders the repo in VS Code Insiders this file in VS Code Insiders up / down arrow for 7-8 minutes inside the file. Notice how NVDA reads everything even after all that time can you tell me what am I missing in this steps? Also can you try with the build provided . That would really help us to understand this better since we cannot yet reproduce the problem on our side.
I have not tested with insider, but in stable, if you press ctrl + shift + e to go to the file explorer, leave it still for a while, you can no longer do anything and it is necessary to change window. When I go back to the VS Code window, sometimes I can't read the lines, it reads the whole file from the beginning, and besides that, NVDA takes a long time to move through some controls. For example, when expanding a folder in the file explorer. All this is solved if I restart NVDA. But it is something I have to be doing very frequently to be able to work well. As I was saying, this happens to me in the latest stable version. I will try the above solution.
Code change:
*/ app.commandLine.appendSwitch('disable-features', 'CalculateNativeWinOcclusion'); <del> /* Following features are enabled from the runtime. * `AutoDisableAccessibility` - https://github.com/microsoft/vscode/issues/162331#issue-1390744354 */ app.commandLine.appendSwitch('enable-features', 'AutoDisableAccessibility'); </del> // Support JS Flags const jsFlags = getJSFlags(cliArgs); if (jsFlags) {

Related discussion:
text: Thanks
The above solution solves the performance problems I have been having for a long time when starting VS Code. It seems that the line reading problem has been solved as well. However, when I leave the focus on the file browser for a minute or so, the problem persists and nothing else can be done. If I press ctrl + shift + e and switch contexts, the focus returns, but now I have lower performance with NVDA, which causes me to have to restart the screen reader anyway. Thanks
After some time, I have been able to verify that it is still not resolved, but it does not happen in all cases. The performance issues in VS Code at startup seems to be the only thing that was fixed, apparently. I hope you can keep and merge the changes from the above proposed solution because now I don't have to restart the screen reader after starting VS Code, which is much nicer. However, the other two problems still persist. Standing still for about a minute in the file explorer results in not being able to focus on anything. The line problem I can now only reproduce with an extension, but it uses the same Monaco editor as VS Code. Install eamodio.gitlens extension. Now, focus the file explorer and look for a file with the arrows. Press shift f10 and scroll down to open file history. Then, choose any commit and press enter, then f6 to go to the editor that opened. There the lines do not read well. For example, given this file from a Ruby on Rails application: Pressing up arrow or down arrow always reads this, except in the last line that reads blank: Thanks
I just installed the build posted above: VSCodeUserSetup-x64-1.75.0- and now, everything works as expected. The screen reader no longer locks up on me every minute or so! This is great... Hopefully, this will give the team enough information to track down this bug! I will leave updateMode set to "none" until I hear that this bug has been squashed. Thanx for the fix! -- Rich
I investigated further and the problem was indeed solved. While changing "" to none VS Code downloaded the update. I uninstalled and reinstalled and everything is fine. Thank you very much!
Code change:
*/ app.commandLine.appendSwitch('disable-features', 'CalculateNativeWinOcclusion'); <del> /* Following features are enabled from the runtime. * `AutoDisableAccessibility` - https://github.com/microsoft/vscode/issues/162331#issue-1390744354 */ app.commandLine.appendSwitch('enable-features', 'AutoDisableAccessibility'); </del> // Support JS Flags const jsFlags = getJSFlags(cliArgs); if (jsFlags) {

Related discussion:
text: I hope you can release this solution quickly, as I can't use this specific code-insiders version with WSL. Try to install but I get 404 error.
I agree that your test build seems to have solved the issue and navigation feels crisper and more responsive. Please update insiders and also a patch release to 1.74 since this does not work with WSL or devContainers.
thanks for confirming the fix, it will be available in Insiders today. Can you also respond to comment in about any missing steps which will help us on our end to verify the fix. Thanks! We just had a patch release yesterday , you should be able to use the normal insiders with the fix on both WSL and devcontainers until we make a release. Also, we will need the steps to verify if we want to make a patch release to stable. I will update here again once the fix is available with Insiders.
Insiders has been released with the fix, you can get insiders from
the steps are in this , for the line reading and freezing problem Thanks for the solution!
FOr me, the problem would occur when I was simply navigating the interface. It was most apparent, and seemed to be triggered more quickly, when navigating a menu like view (alt+v, then up/down arrows). Question: I'm seeing behavior that I've never seen in other menus -- if I open view with alt+v, navigate via downArrow, escape out of the menu, then come back in with alt+v, it almost never focuses on the first menu item, but somewhere in the middle. Is this intentional? Thanx for all the work on this! -- Rich
I cannot say I noticed a repeatable pattern, but it was much more likely to occur when navigating around the UI in areas like the explorer, settings, extensions, menus, etc. than just staying within a single file. So it doesn't surprise me that steps did not reproduce the issue.
Closing since we have pushed a fix for this. Adding a verified label based on users confirming the issue is indeed fixed (since we can not reproduce ourselves). If some users can it would also be helpful to verify with the stable build that is about to come out in the next 24 hours.
Code change:
*/ app.commandLine.appendSwitch('disable-features', 'CalculateNativeWinOcclusion'); <del> /* Following features are enabled from the runtime. * `AutoDisableAccessibility` - https://github.com/microsoft/vscode/issues/162331#issue-1390744354 */ app.commandLine.appendSwitch('enable-features', 'AutoDisableAccessibility'); </del> // Support JS Flags const jsFlags = getJSFlags(cliArgs); if (jsFlags) {

Related discussion:
text: Here's the links to the build depending on your platform darwin: darwin-arm64: darwin-universal: linux-arm64: linux-armhf: linux-deb-arm64: linux-deb-armhf: linux-deb-x64: linux-rpm-arm64: linux-rpm-armhf: linux-rpm-x64: linux-snap-x64: linux-x64: win32: win32-archive: win32-arm64: win32-arm64-archive: win32-arm64-user: win32-user: win32-x64: win32-x64-archive: win32-x64-user:
Yes, it's also fixed in 1.74.2.