Testing ! Option + Down/Up arrow in terminal is not navigating between commands. These are working only in accessibility view. In terminal the keybindings are cmd + Down/Up arrow.
I'm experiencing the same issue testing on Windows 11.
This text should say in the accessible view - the keybinding is meant to work there, not in the terminal.
same issue! All the other commands work fine, arrows/screen reader work fine in the quick pick after command is run. I am wondering though if the keybinding for prev/next commands might be too generic?
Everyone, the prev/next commands must be run in the terminal's accessible view - not the terminal. Can you pls test that? I plan to make that clear by tweaking the dialog's text.
Yes, it worked in the terminal accessible view for me (as it sounds like it did for too).
Worked fine for me too! Sorry for the mixup
Thanks definitely see why you were confused though, so will fix that
to verify, open the accessibility help dialog by focusing a terminal and using . verify that the specify that they're to be applied in the terminal accessible view.


Testing Start from , on a repo: The git extension will associate as the most likely candidate for 's base. But since does have an upstream, , which, at the point was created, was pointing to the same commit as itself... wouldn't be a better base candidate instead?
I think that this makes sense to me however would you favour the remote branch (origin/foo) just because it points to the same commit as when was created or should it be a general rule that if a remote is present, we would favour it?
Will mark this and look out for additional feedback.
Though more about this and since we are adding and actions to the incoming node, it does make sense for it to be an upstream branch. Marking the issue as "bug" so that it gets verified during endgame.


Testing Testing on Windows 11. opens terminal accessibility help dialog correctly: ! Explore options, decide I want to try Run Recent Command () to open terminal accessible view, opens correctly: ! Try I don't observe anything happen - but maybe I'm misunderstanding what should happen or how I should set this command up?
Sorry this was not clear. Perhaps I should specify which commands only apply when focus is in the terminal? Perhaps that should also work when the focus is in the accessible view... I will think about that.
To verify, focus a terminal in screen reader mode. open the terminal accessibility help dialog with and check which keybinding to use for . open the terminal accessible view by focusing the terminal and using use that key binding. make sure it runs whichever command you select.
I think I'm still missing something in my understanding. Steps I took: Open VS Code repo in latest VS Code Insiders Toggle screen reader mode so that I'm Screen Reader Optimized Open and focus terminal , the terminal accessibility help dialog opens I note that will run recent command, and will get me to previous commands Open terminal accessible view by focusing terminal and using to get to a previous command (this worked well) Once I've gotten to a previous command I'd like to run, I try but again don't observe anything happened: !
Apologies, Brigit, it appears there's an old bug resurfacing in which the keybinding is not listed correctly in this dialog. On windows, run recent command is invoked with when in screen reader mode. On mac, with screen reader mode, it's .
Reopening to fix that
Ah yay, worked well for me, thank you! I'll hold off on labeling as if you'd also like to use this issue to track fixing the keybinding bug.
Actually, I think I'll reopen that other issue. Since the issue was the command not working, it would be great if you'd verify this and I'll link the other . Thanks
here's the issue where we're tracking that


When there are multiple debug sessions, the dropdown action item shows in the debug toolbar here as a button that doesn't do anything. You can see it in the gif in We could just hide that item when this setting is set
I believe it focuses the Call Stack view but only when paused and when having the view active. Tho, I do agree that we shouldn't have it there to begin with.


Type: <bBug</bclone repro from and open project folder run the repro extension from vscode open two folders in the workspace (these will not be touched by the repro code, the problem was encounterd in multi-folder workspace and this just reproduces that environment) run command after some time popup with error will appear Expected beahvior: the loop running the dummy task will keep running indefinitely This seems to be caused by using in combination with changes of the workspace folders. When the loop in the repro is changed to only keep writing the file and running the tasks the problem never appears VS Code version: Code - Insiders 1.82.0-insider (, 2023-09-01T11:05:38.381Z) OS version: Linux x64 4.19.0-18-amd64 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (0)</summaryExtensionVersion ------ </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I'm not seeing the task you said to run in that folder !
The repro steps say to run command , not a task. The command runs the task itself via the API. Here is the command in the command pallette ! And here is the error it produces ! Please try the repro steps again and let me know if you still can't see what I show in the screenshots
I get this error, which is interesting because the workspace contains two folders. !
From the screenshot it seems like you have one workspace folder containing two file system folders - that still means the workspace is a single root workspace You need to have a multi-root workspace by calling I hope the terminology I use is correct, it is taken from this doc
PR fixing it


I have a setting in my settings. Everytime I reload, I see a setting being . This keeps on happening, the old setting is never removed. ! Not sure if this should be a candidate. does this code look right to you? Or does migration also need to remove the old setting?
If you want to remove the old setting you should explicitly mention that in the migration like below
Can the migration function be made in a way that people do not forget this?


I'm pretty sure some of these keybindings aren't ever enabled with their context key requirements, e.g. I don't think the inline chat can be focused in a markdown cell that isn't in edit mode. Nor will cursor navigation mode be true while edit mode is false.


Type: <bBug</bCC Copilot inline suggestion Accessible View (alt+F2) for the suggestion : this opens a side-by-side copilot suggestion panel instead of accepting the suggestion. I think we need to go back to the original keybindings: for accepting suggestion; for submitting a request. VS Code version: Code - Insiders 1.84.0-insider (, 2023-10-12T05:37:35.298Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (92)</summaryExtensionVersion ------ android-dev-ext1.3.2 aiprm-lang0.0.2 Bookmarks13.4.2 openscad1.2.2 spellright3.0.118 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.52.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.26.0 gitlens14.3.0 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-google-translate1.4.13 codespaces1.15.4 copilot1.126.0 copilot-chat0.9. remotehub0.62.0 vscode-github-actions0.26.2 vscode-pull-request-github0.74.0 overleaf-workshop0.3.0 cslpreview0.2.2 easy-snippet0.6.3 path-autocomplete1.25.0 latex-workshop9.14.1 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 vscode-bard0.0.10 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.1 black-formatter2023.4.1 flake82023.8.0 isort2023.11. python2023.18.0 vscode-pylance2023.10.20 jupyter2023.9. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.318.0 remote-ssh0.106.5 remote-ssh-edit0.86.0 remote-wsl0.81.8 vscode-remote-extensionpack0.24.0 azure-repos0.38.0 cmake-tools1.15.31 cpptools1.17.5 cpptools-extension-pack1.3.0 js-debug-nightly2023.10.1117 powershell2023.9.5 remote-repositories0.40.0 vscode-github-issue-notebooks0.0.130 vscode-selfhost-test-provider0.3.19 vscode-serial-monitor0.10.0 vsliveshare1.0.5883 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.5 shinyuieditor0.5.0 quarto1.103.0 r-debugger0.5.4 java1.23.0 vscode-xml0.26.1 r2.8.2 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.7.0 latex-utilities0.4.10 cmake0.0.17 errorlens3.14.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.54.0 vscode-java-dependency0.23.1 vscode-java-pack0.25.14 vscode-java-test0.40.0 vscode-maven0.42.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Good catch. I couldn't test yesterday as inline completions weren't working for me. I think that we can just increase the weight of this keybinding rather than change it back.
That keybinding will still work when one is not in the accessible view. LMK if that sounds good to you.
-- We then reassign the default keybindings for the following: : This is currently . : This is currently .
We cannot change the extension contributed ones, so I was suggesting overriding it when in the accessible view. I cannot get inline completions to work in oss atm, so cannot test any of these changes until that works and am leaning toward just reverting the change.


<!-- 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: 1.83.1 OS Version: 12.6.9 Steps to Reproduce: or the Python and Black Vscode extensions a new notebook and execute any cell or save it You'll a "Formatting with autopep8" message in the status bar even though that formatter extension isn't installed! However manually triggering "Format Cell" does use black.


When using the new diff editor with enabled, I very rarely get to the right editor position whenever I click the top action, above the editor.
You mean go to reference is broken?
diff editors have an action to open the original file (I think contributed from SCM?). When clicking that, expectation is that the current view state of the diff editors right hand side applies to the opening editor so that you stay in exactly the same view state (for example: the selection and viewport). <img width="140" alt="image" src=""
I really like the collapsed diff editor but this is a very frustrating regression from it which makes me want to shut it off. The issue is 100% reproducible in my usual workflow and I encounter this issue many times per hour.
I can reproduce. The "Open File" command is a mystery to me. Debugging shows me that is called twice, but both times with unhelpful stack traces: ! ! The second invocation sets . However, there is no reveal mechanism.
Further investigation showed that the "Open File" action is actually implemented in the git extension (even when comparing two files on disk) :/ Which I think is very questionable design, as it should be a core diff editor feature.


From We should fix block styling in Markdown previews in main as well, from discussing with we want to make the styling consistent across chat, settings UI, and extension webviews
The three greys look different to me. I'm unsure whether those are the colours I should be comparing. !
To verify this you just need to confirm that there is a background for blocks, since it used to just be a brownish foreground color.


Type: <bBug</bWhat does this mean / do? ! VS Code version: Code 1.84.0 (, 2023-11-01T11:29:04.398Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
Apparently from by and present since 1.78.
this should only be showing up for the quick pick item hovers, not the actions which have a small amount of content.


<!-- 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. --<img src="" alt="drawing" width="600"/Currently, we can control when to show the inline suggestion toolbar by setting to "always" or "onHover", which are defined as follows: "always": show the inline suggestion toolbar whenever an inline suggestion is shown, and "onHover": show the inline suggestion toolbar when hovering over an inline suggestion. For the new feature, I suggest to add an option "never" as follows "never": do not show the inline suggestion toolbar.
I think this should be very easy to implement. Up for a PR?
I would like to take this.
Any ideas why this setting isn't in the Settings JSON file? .
Thank you so much for accepting the request and for the contribution!


<!-- 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. --extension is used to specify the syntax highlighting for popular languages, such as TypeScript: Currently, the workaround is to push the settings file to Git: In addition, extension is also . It would be nice if VSCode could support these aliases to YAML natively.
If you want to make a PR, that would be great!
I made a PR, I hope it's good, because I have no experience with the codebase:


open test explorer notice that the input has the wrong background color, e.g it has two background colors <img width="455" alt="Screenshot 2023-11-15 at 14 29 05" src=""
What theme are you using? I can see the slight difference in your screenshot, but inspecting things I'm not seeing any backgrounds being applied to that action / menu bar
Like, any light theme?
Still confused on the latest Insiders for me in e.g. solarized light: <img width="725" alt="image" src=""Does it reproduce on a fresh user-data-dir for you? If so, are you able to do a quick devtools inspect and give a hint as to what styling is being applied that makes monaco input have a different background color?
I see. It doesn't show with an empty profile but I also don't have any setting that screams test explorer background color
Could you bisect your user settings or share them so I can play around?
This seems to be because I have the test explorer in the secondary sidebar. There is some settings that controls this but I have no clue which one it is <img width="2188" alt="Screenshot 2023-12-12 at 18 02 53" src=""
CSS is fun


<!-- 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. --The direct symptom is in the site , but the investigation went through (which the site uses) and ends up here. Steps to Reproduce: to This shows the "LLVM Opt Pipeline Viewer" (1) which is a diff pane created by monaco's (2). It's contents change based on the user selection in from the 'passes' list (3). ! see normal operation in action: click in order the passes "SROAPass" (first one) and "Greedy Register Allocator". Diffs are shown properly: ! reproduce the bug, click in order the passes "SROAPass", then "Debug Variable Analysis" (one above Greedy) and finally "Greedy Register Allocator". First, text diffs are not being decorated despite being present: ! and second, a console shows the error: Preliminary investigation directs attention to these lines in 's : In the (not so rare) problematic scenario, and are non-empty but is, so the code enters the loop and crashes immediately. I suspect something broke in PR , but not sure.
A monaco-playground link with a small standalone repro for the problem: This creates a diffView and populates both sides with an offending text (specifically, one with non-empty "unchangedRegions"). After two seconds it sets the left pane to the same text as it currently has, but this time the decorations disappear and a console error message as above appears. Perhaps this tidbit would be helpful: It seems that upon entering , contains ids that were already invalidated - i.e., do not appear in : ! And so returns only nulls and the resulting array is empty. My current guess is these decoration-IDs invalidation is too early, and should be moved to after .
Thank you for the prompt fix!
Please, please, please, include inline diff view in your testing. I use inline view 99.9% of the time, side by side very rarely. Regardless, I hope this Thank you for your work.
I saw this problem again today.
Can you please share the output of the dev console? Thanks!


Initially noticed by : <img width="780" alt="Screenshot 2023-11-17 at 13 53 45" src=""


Type: <bBug</bWhen reviewing outgoing changes for my tracking fork of microsoft/vscode after merging upstream/main into my local copy today. ! Also, based on I was surprised to see the magnifying glass icon still being used for "View Changes". VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-22T05:35:23.085Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
/assign
I'm very sure this is a duplicate of
This sounds like there was no insiders for today. Can you check you are running the build from today? The PR just got merged yesterday.
Yes, this is today's. The new codicon appears in the Timeline view, just not in the incoming/outgoing party of Source Control view: !
It does for me: !
Ah, we're not talking about the same thing. My screenshot is of the feature recently by and controlled by the and settings. It comes from here:
are you able to reproduce this consistently? Could you provide steps that that I should use to try to reproduce the issue? Thanks!
in said it was probably a known issue. Ever since Insiders got that fix I haven't had any problems opening multi-diff for outgoing changes that get listed after I merge from upstream/main into my local main prior to pushing them to origin/main (my tracking repo). So I'm closing this one.
thanks for the update!
Hmm, just happened to me again with today's Insiders: ! Reopening. I'll hold back from pushing the local changes that I merged in from upstream/main in case there are places you'd like me to look for clues while I can repro it.
Devtools console:
It's this one: ! And specifically which is of course binary: ! I guess the multi diff editor needs to handle this case gracefully instead of failing to show the diffs for the other files.
thanks! could you please take a look? Thanks!
Ahh, because it is a binary file...


Type: <bBug</bA corrupted file is stored in CachedExtensionVSIXs and never re-downloaded, preventing extension from being installed until the file is manually deleted. Repro: Attempt to install an extension while the Azure DevOps service is not available and returning errors. Result in this comment: The corrupted vsix contains the following HTML instead of zipped data ! Shared Output: VS Code version: Code 1.84.2 (, 2023-11-09T10:52:57.054Z) OS version: Darwin arm64 23.1.0 Modes: Connection to 'SSH: ox' could not be established Canceled <details<summarySystem Info</summary Connection to 'SSH: ox' could not be established Canceled </details<details<summaryExtensions (31)</summaryExtensionVersion ------ vscode-ron0.11.0 vscode-eslint2.4.2 prettier-vscode10.1.0 kotlin0.2.32 copilot1.139.0 copilot-chat0.10.2 copilot-labs0.17.1121 vscode-github-actions0.26.2 better-cpp-syntax1.17.2 vscode-peacock4.2.2 vscode-clangd0.1.25 membrane1.6.1 vscode-dotnet-runtime2.0.0 vscode-postgresql0.3.0 remote-containers0.321.0 remote-ssh0.107.1 remote-ssh-edit0.86.0 cpptools-extension-pack1.3.0 hexeditor1.9.12 makefile-tools0.7.0 remote-explorer0.4.1 proto0.0.4 vscode-yaml1.14.0 vscode-gitweblinks2.9.3 rust-analyzer0.3.1748 even-better-toml0.19.2 shellcheck0.35.0 es6-string-html2.12.1 vscode-lldb1.10.0 vim1.27.1 clang-format1.9.0 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
cc who was looking into this in
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
bumping to see if this issue is still occurring and if the fix has been verified!
It's somewhat fixed. You can try again and the second time it will work. But the error message that appears doesn't indicate that. perhaps it should retry at least once if the zip is corrupted before showing this error? Note the bottom right popup asking to manually download where a retry could've sufficed. <img width="1304" alt="Screenshot 2023-12-06 at 6 14 41 PM" src=""
Thanks for the feedback. This bug is to fix not to cache corrupted VSIXs and please validate that. Regarding trying again, I do not think we should be showing this as this might be random.
Verifying with a code review


Repro: an editor to a new window (or as many as you want) the original window that still contains the editor that all windows with the copied editor have input lag ! Version: 1.85.0-insider (user setup) Commit: Date: 2023-12-01T19:00:37.339Z Electron: 25.9.6 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: WindowsNT x64 10.0.
A regression from


Type: <bFeature Request</bThe notification suggesting a plugin has a cog with an option "Don't show again". It's however not clear whether this suppresses suggesting the specific plugin, or any plugin. Either this message should be clarified ("Don't show this plugin again") or a second option should be . VS Code version: Code 1.84.2 (, 2023-11-09T10:51:52.184Z) OS version: Windows_NT x64 10.0. Modes:


or VS Code Desktop something to make the autocompletion menu appear. the dash key (-) multiple times to zoom in a lot. Only the text in the menu gets larger while the html elements stay the same size. ! The html should resize with the text appropriately. Zooming in first and then revealing the menu produces the correct sizes on everything. It's possible that "" is the incorrect command to call in this case. Perhaps a list of commands could be provided?
To verify bind a keybinding to Editor Zoom In/out trigger suggest while it shows, use the editor zoom keybindings


Type: <bBug</bWhen first opening vscode or reloading the window several context keys are set to incorrect values. These values may eventually be corrected when focusing another editor and returning to the original one. The keys I have noticed with this issue are: It can be a little tricky to catch some of them misbehaving. It depends on which editors you have open and how they are arranged. ! Steps to repro: Open 2 editors Focus the first editor Pin it Record context keys Reload window Record context keys Diff the two sets of context keys and notice they are not the same VS Code version: Code - Insiders 1.86.0-insider (, 2023-12-18T05:36:59.983Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Ben, maybe you could check for the ones in editor area since you recently fixed some issues there. Maybe its a regression?
The following context keys were not being updated on reload: Updating them now on reload
This seems to apply to a few additional context keys outside of . Just a heads up in case closing the issue was accidental.


Testing The setting says " speech recognized" which reads a bit weird. Maybe leave "speech" away or says "Controls whether the editor listens for the 'Hey Code' phrase and what to do with it"
Bonus points for mentioning that this happens all locally
Yeah, I think I will go with this:


]- Identify accessibility bugs before check-in and make bug fixing faster and easier. #A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #Win32; #Visual Studio Code Client; #BM-VisualStudioCodeClient-Win32-Jan2024; #WCAG1.4.3; #Color Contrast; Visual Studio Code insider version 1.86.0 Microsoft Windows 11 Enterprise 22H2 Build .3007 Visual Studio Code Insiders editor ctrl+P or Tab till go and press ENTER then TAB till Go to File. that Color contrast ratio of the "search files by name" placeholder text is "2.283:1" which is less than 4.5:1. Color contrast ratio of the "search files by name" placeholder text is "2.283:1" which is less than 4.5:1. Similar issue is also observed throughout the application. Color contrast ratio of the "search files by name" placeholder text should be greater than or equals to 4.5:1. Low vision users will not be able to see the placeholder text if color contrast ratio will be less than 4.5:1. ! !
I can't reproduce this one. With the Dark Modern theme I see a background value for inputs of which passes the 3:1 ratio with the placeholder foreground of .
Misread that the ratio should be 4.5:1. This I can fix.
Verified the issue in below environment: Visual Studio Code Insider Version: 1.87.0-insider (user setup) Issue is fixed. Hence Closing the bug. please find attachment for reference. !


Type: <bBug</bSince updating to 1.86, when I open a git diff in VSCode, I see the latest version of the file on both sides, showing no differences (except that word wrap is off on the left & on on the right... it's on everywhere else)... if I stage a file, open the diff, then unstage the file, then I see the correct diff like I've always seen before likely related: the new +- buttons next to Changes & Staged Changes show the same behavior (although while playing with it, I did have one time where I saw the correct diff on the first file) at one point I restarted VSCode, which seemed to resolve the issue, but it was only temporary. once I started editing files again the issue returned not sure if it's relevant or not, but... in all cases, the changes were saved to disk... the git change indicators in the left gutter of open files are not affected by this issue, they continue to work as the always have, showing up as I edit, clearing when I stage the change VS Code version: Code 1.86.0 (, 2024-01-31T10:28:19.990Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (55)</summaryExtensionVersion ------ vscode-icalendar1.0.1 vscode-m3u1.0.0 vscode-caniuse0.5.0 case-change1.0.2 rtf2.7.0 spellright3.0.122 markdown-checkbox0.4.0 markdown-emoji0.3.0 markdown-mermaid1.21.0 markdown-yaml-preamble0.1.0 vscode-tldr1.0.0 gitignore0.9.0 vscode-markdownlint0.54.0 vscode-eslint2.4.4 rushcore1.0.2 rushnav1.0.2 githistory0.6.20 xml2.5.1 escaping-characters1.0.0 EditorConfig0.16.4 vscode-macros1.4.1 git-project-manager1.8.2 url-encode1.1.0 shell-format7.2.5 matlab3.0.2 vscode-pull-request-github0.80.0 gc-excelviewer4.2.58 vscode-markdown-footnote1.0.0 vscode-favorites1.11.0 rest-client0.25.1 path-autocomplete1.25.0 mediawiki2.1.0 anki1.3.1 markdown-katex0.1.4 vscode-peacock4.2.2 gpg1.1.1 zotero0.1.11 markdown-shortcuts0.12.0 debugpy2024.0.0 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 azure-account0.11.6 azurecli0.6.0 hexeditor1.9.13 live-server0.4.13 vscode-yaml1.14.0 vscode-zipexplorer0.3.1 pdf1.2.2 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-icons12.7.0 org-mode1.0.0 JavaScriptSnippets1.8.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Please use the Start Extension Bisect command to investigate whether the problem is being caused by one of your extensions.
I can duplicate this in Insiders with no extensions loaded (... however, that opening & closing revealed more details I didn't realize previously... I only see the buggy behavior with changes made in this session... if I close & reopen VSCode, changes that were staged before VSCode opened render correctly... new changes stop rendering when they're staged (and when I say "stop rendering" I mean no red & green highlights, because both sides of the diff tab contain the new code) & start rendering again when the app is restarted (or I switch between Release & Insiders) side notes: I'm no longer seeing the no word wrap on the left in VSCode (& I never saw it in Insiders), so not sure what was up with that... I know that there are often visual artifacts in one side of the diff editor (e.g. valid relative paths get yellow squiggles on one side but not the other), so guess I'll put this one in that category... who cares? I'll see that in the main editor, I just want the diff in the diff viewer I forgot to try Insiders before I submitted because it was so obvious that only 1 thing changed, but I'll try to remember that just to make sure it hasn't been fixed already... but, I don't appreciate being asked to go on a wild goose chase bisecting extensions
one more thing I just noticed... prior to 1.86, if I stages a file, then made additional changes, so that the file is now in the Source Control panel twice... the 2 diff buttons would open 2 separate diffs, one with the staged changes & 1 with unstaged... now I get only one (with the unstaged changes) also, it makes no sense that the bot removed the label, unless there's been another Release since 1.86, and the Releases page still shows that as the newest version
I've had this issue since February too. Strangely enough, I started an Extension Bisect, stopped straight away (intending to restart) and now I don't have the issue. ¯(°_o)/¯
I'm hitting this too on two completely different machines (Windows and Linux). The issue is if you click the diff button on a staged file just after staging it, for some reason it opens the working tree diff (which has no differences). If you reload the window so it starts with the file already staged then the button correctly opens the index diff. I reproduced this with no extensions enabled. I think the reason this enormous bug has gone unnoticed for so long (I only just looked into it because I assumed that surely they would fix something as broken as this...), is that it only happens if you have this setting: Do you guys have that set?
yes, I do have that setting... and if I comment it out, I see the correct behavior
Sorry for not getting back to you on this. Could any of you experiencing this issue provide a screen recording illustrating the issue ()? Thank you very much in advance!
Ugh I can't seem to reproduce it at the moment - sometimes it does work, but I haven't found the exact pattern. So you'll have to use your imagination, but basically you click the diff button for a file (two circles connected by arrows) and it opens a diff view but there are no differences between the files on the left and right of the view. Next time it happens I'll try to record it.
Are you able to reproduce the issue if you disable the setting? Thanks!
Didn't seem to make any difference - I still can't reproduce it, sorry. What does that setting actually do? It doesn't seem to make any difference to behaviour and I don't understand the description: ! The Source Control view still automatically updates even if I have that off.
if I add to my settings I can repro, without it I can't repro... just recorded with gitcap, waiting for it to render so I can get a link
video was way over GitHub's 10MB limit... so dropped it in my OneDrive & tried to include it as an image... !Auy35hyaQsjmnpB70oGx2DvOlOjaXg?e=YLgT5J!
could you please re-upload the recording as it looks like it is not available at the link any more. Thanks!
i will try tonight... on vacay this week, so might need to wait until I'm back on the work PC Monday
any news on the recording? Thank you!
with in settings (without it I see expected behavior) !
thanks again! I have a fix but it will not make the cut for the August 2024 release so it will be in the September 2024 release.
<!-- 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!
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Verification steps: VS Code Insiders to a file, modify it and save it the Source Control view and click on "Open Changes" action Confirm that the diff is rendered correctly on the "Stage Changes" action on "Open Changes" action Confirm that the diff is rendered correctly


<img width="431" alt="image" src=""The debug view uses monospace font by default other than the workbench font


Enable Write a long commit message that triggers validation Hover over the diagnostic squiggle <img width="405" alt="image" src=""


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.86.1 OS Version: Ubuntu 23.04 Steps to Reproduce: an empty text editor the text opening and closing an empty text editor several times that the number of disposables increases each time Opening and closing an editor 1997 times results in 3994 disposables with this stack trace: When opening an editor, the function is called , the function calls adds a disposable to the disposable store When closing and opening the editor again, the same happens: the function is called , the function calls adds a disposable to the disposable store again This probably causes more and more disposables to be in . It seems, disposing the codeEditorContributions disposable () when a text editor model becomes detached might be a possible solution. That way, it would be registered when a model is attached and disposed when a model becomes detached:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.86.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Thanks a lot!


In VS Code action items inside inputs are vertically aligned to top, in the Chat features they are centered in the middle. This happens when putting in a lot of text or pressing Shift+Enter. Panel: <img width="425" alt="image" src=""Inline: <img width="608" alt="image" src=""Quick: <img width="621" alt="image" src=""For Inline and Quick the action items to the right of the input box should also stick to the top.
Seems like we have a mix of top-aligned and overflow w/ scroll (see below). But I agree that we should be consistent as much as possible. But it does feel like a chat send button should generally but aligned to the bottom, no? We may even consider rendering the toolbar on its own row once we're into multiple lines. That would ensure the text isn't forced to fill a tiny space now that we have 2+ icons. Here's how Teams does it as an example: ! ! ! !
Would be awesome if the text could wrap around it, especially in the narrow search widget case, I've always wanted that but I think it would be a pain to implement.
Don't have a strong opinion about top or bottom, I think each can be justified on a case-by-case basis. but middle looks weird. :) For example, inline Chat may want to do top alignment as the icons would align with those outside the input field (poppet and close) Bottom would help with the wrapping.


use generate cell in notebooks make a request while the request is active press stop a bunch of errors are printed
It seems not wise at all to maintain my own *chatcontroller. I'd love to look into how do I ensure I reuse the most of Inline Chat Controller later.
Is the generate cell feature just with using ctrl+i from within a cell body? Not sure how I can trigger it.


This only applies in a multi-root workspace. With just 1 view: ! With N views: ! I think we should use the workspace label here. to you recall why this code is there:


<!-- 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: 1.86.2 OS Version: Windows 10 / macOS Sonoma Steps to Reproduce: at least three windows the command least one of the windows will show a strange close icon, instead of the regular one, like the image below ! I reproduced the same error on Windows, and it also presented a strange icon, but it was a different one. A small vertical rectangle, like that missing unicode chars. I tested the on Insiders release, at least on MacOS, and didn't notice the error. I didn't have the opportunity to test in Insiders on Windows yet. I'll update the issue later with more details. Thank you
are you using a product icon extension?
Nevermind, a regression from , fyi
Hi , Glad to know you could find the fix. Let me know if you need me to verify it when released. Thank you
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


To be able to reach to the files presented in a multi diff text editor the tab model should provide a corresponding TabInput (see ) May be a good idea would be to have a general composite tab input. For the multi diff text editor the elements could then be
When you listen for tab changes the input of the tab is currently .
Not sure if this is or
Related:
Thanks!
Reopening to get API approval. I'm also not sure we will be able to expose the resources in multi diff This will probably complicate your use case. pointed out that the resources can change without changing the input and this is not something any of other inputs do making supporting showing the resources for this input quite difficult.
Can you verify? To verify please ensure that you see a type now for the multi diff text editor and it properly reacts to resource changes


This error appears in the insiders dev tools all the time (FYI Cannot read properties of undefined (reading 'includes'): TypeError: Cannot read properties of undefined (reading 'includes') at at at at at at at at at at at


Type: <bBug</bIn the below image, clicking the link Learn More brings you to However, that section (id) does not exist on The link is most likely supposed to go to ! VS Code version: Code 1.87.2 (, 2024-03-08T15:20:17.278Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 5.4.0-173-generic <details<summarySystem Info</summary </details<details<summaryExtensions (32)</summaryExtensionVersion ------ yang0.1.3 jupyter-keymap1.1.2 remote-containers0.348.0 remote-ssh0.109.0 remote-ssh-edit0.86.0 remote-wsl0.86.0 vscode-remote-extensionpack0.25.0 remote-explorer0.4.3 remote-server1.5.1 vscode-openapi4.25.1 vscode-fish1.0.38 ruff2024.16.0 vale-vscode0.18.5 vscode-markdownlint0.54.0 gitlens14.9.0 prettier-vscode10.1.0 code-runner0.12.1 go0.41.1 restructuredtext189.3.0 direnv0.17.0 vscode-azureresourcegroups0.8.4 vscode-cosmosdb0.20.1 vscode-docker1.29.0 vscode-kubernetes-tools1.3.15 python2024.2.1 azure-account0.11.6 vscode-yaml1.14.0 code-spell-checker3.0.1 even-better-toml0.19.2 shellcheck0.37.0 simple-rst1.5.4 vscode-proto30.5.5 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --


Type: <bBug</bCC command works only from inside the Accessible View; it does not work when invokved from the code block area of the Copilot Chat View. VS Code version: Code - Insiders 1.88.0-insider (, 2024-03-25T05:49:32.344Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (119)</summaryExtensionVersion ------ vscode-openapi4.25.1 zotenote1.0.1 android-dev-ext1.4.0 aiprm-lang0.0.2 Bookmarks13.4.2 openscad1.2.2 spellright3.0.122 mermaid-markdown-syntax-highlighting1.6.0 doxdocgen1.4.0 vscode-markdownlint0.53.0 vscode-eslint2.4.4 vscode-quick-select0.2.9 vscode-deno3.35.1 gitlens14.6.1 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-firefox-debug2.9.10 shell-format7.2.5 vscode-google-translate1.4.13 codespaces1.16.17 copilot1.175.784 copilot-chat0.14. remotehub0.62.0 vscode-github-actions0.26.2 vscode-pull-request-github0.85. cloudcode2.6.0 overleaf-workshop0.11.0 cslpreview0.2.2 easy-snippet0.7.5 path-autocomplete1.25.0 latex-workshop9.19.1 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 commitlint2.5.1 language-julia1.75.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 git-graph1.30.0 azure-dev0.8.1 vscode-azureappservice0.25.2 vscode-azurecontainerapps0.6.1 vscode-azurefunctions1.14.0 vscode-azureresourcegroups0.8.3 vscode-azurestaticwebapps0.12.2 vscode-azurestorage0.15.3 vscode-azurevirtualmachines0.6.5 vscode-cosmosdb0.21.0 vscode-docker1.29.0 vscode-edge-devtools2.1.5 black-formatter2024.1. debugpy2024.3. flake82023.10.0 isort2023.13. python2024.3. vscode-pylance2023.12.103 jupyter2024.1. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.352.0 remote-ssh0.110. remote-ssh-edit0.86.0 remote-wsl0.81.8 vscode-remote-extensionpack0.25.0 azure-account0.11.6 azure-repos0.38.0 cmake-tools1.17.17 cpptools1.19.9 cpptools-extension-pack1.3.0 js-debug-nightly2024.3.2217 powershell2024.3.1 remote-explorer0.5. remote-repositories0.40.0 remote-server1.6. vscode-github-issue-notebooks0.0.130 vscode-node-azure-pack1.2.0 vscode-selfhost-test-provider0.3.25 vscode-serial-monitor0.11.0 vscode-speech0.7. vscode-speech-language-pack-ko-kr0.1.0 vsliveshare1.0.5918 windows-ai-studio0.2.4 autodocstring0.6.1 pandocciter0.10.4 shiny-python0.1.6 shinyuieditor0.5.0 quarto1.111.0 r-debugger0.5.4 java1.28.1 vscode-xml0.26.1 vscode-yaml1.14.0 r2.8.2 multi-command1.6.0 vscode-deepl1.1.1 abc-music0.4.0 lua3.7.4 latex-utilities0.4.13 cmake0.0.17 vscode-terminal-here0.2.4 windows-terminal0.7.0 errorlens3.16.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-conventional-commits1.25.0 vscode-arduino0.6. vscode-java-debug0.56.2 vscode-java-dependency0.23.5 vscode-java-pack0.25.15 vscode-java-test0.40.1 vscode-maven0.44.0 zotero-cite0.8.2 markdown-all-in-one3.6.2 grammarly0.25.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I see this when I try that !
Looks like we should be overriding that or going with a different keybinding.
Note that this also doesn't work when in the accessible view. I believe has somehow worked around that by tweaking his keybindings / clauses.
You are correct. I had to tweak around my keybindings to make it work.


Just asked hi: ! Expected: ! Version: 1.88.0-insider (user setup) Commit: Date: 2024-03-25T05:49:32.344Z Electron: 28.2.6 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0. GitHub Copilot Chat v0.14. (pre-release)
because of
To verify configure have a very wide view port ask AI to change some code make sure the input widget is full width of the zone widget


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


Testing In the screenshot below, "Chat: Insert at Cursor" should be "Chat: Insert into New File" !


Testing to filter e.g. Python Notice the non-extension entries remain at top Maybe this was by design, but I don't understand it. If I type python, don't I want to quickly select a python related entry?


Note that both of these scenarios used to work. In the terminal inine chat, run a command like which yields just a chat message response. Try to tab to it. one cannot Run a command like which yields a code block response. Try to use to go from the input box to a code block response and vice versa. one cannot
Note that the keybindings are important because it's annoying as a SR /keyboard only user to have to tab through a bunch of things to reach the response.
This works for me, I do the following with success cmd+i, paste , press Enter wait for the response press tab repeatedly and reach the response
the tabbing part works for me in today's insider's
I'm able to spam Ctrl+Up on Windows to focus between the inputbox and the chat response, but I'm not able to spam Ctrl+Down to do the same. I'm unable to use either shortcut to focus from the inputbox directly into a code block within the chat response. Let me know if the behaviour is as expected or if there's some other steps I can follow.
I haven't tried windows yet. This won't directly focus the code editor, just the response.
this works on mac, could you pls try on windows?
The behavior seems wrong now and is quite disorienting: Input: ctrl+up will focus the response list ctrl+down will focus the response list Response list: ctrl+up does nothing ctrl+down does nothing Response code block: ctrl+up focuses the input ctrl+down focuses the response list I would expect: Input: ctrl+up does nothing ctrl+down will focus the response code block Response list: ctrl+up focuses the input Not sure? Response code block: ctrl+up focuses the input ctrl+down focuses the next code block, otherwise not sure
This issue was about cmdCtrl+up/down going between the response list and the input. This is unexpected, but unlikely to be attempted by the user IMO. Input: ctrlCmd+up will focus the response list This works on mac. Not sure why it doesn't on windows. Response list: ctrlCmd+up does nothing I didn't implement this yet, but can in April. Response code block: ctrl+up focuses the input ctrl+down focuses the response list
verified that this does work. I'm making a new issue about focusing the code block(s) and the bug with in the input focusing the list


using Default Light + theme run peek references <img width="978" alt="Screenshot 2024-03-26 at 17 30 37" src=""


Sometimes the default width for inline chat seems very wide: <img width="854" alt="image" src=""Maybe it could grow while typing and or allow to be resized.
decided against dynamic and going with a more reasonable default width of 360px


Testing Sometimes when I hovered over the button it would show the hover of that button over the button. When moving down to the button it would close the editor hover sometimes because the mouse would move over the hover. This could be solved by setting an anchor for the and hovers


Testing The keybinding does not work on windows due to quick open. Also the keybinding collides with the command. I wonder if this could be solved without registering keybindings. One idea could be that when the hover is focused the user could just use and on the keyboard to increase and decrease the hover (possibly also arrow keys could work). Make sure to mention in the hover of the increase and decrease actions what the keybinding or keyboard key is.
That's a very good point. I think we would still want ideally the + and - to be linked to keybindings so they can be configured by the user. I'll remove the keybindings, so they can simply be set by the users if they so wish. The current code already renders the keybindings if they are set: Perhaps they are not fetched correctly in your case because of the keybinding collisions. !


Testing on Linux I have 2 monitors: primary and secondary. I opened VS Code and maximized it on my secondary monitor. Then I dragged an aux window out and maximized it on my primary monitor. After closing and reopening VS Code, the maximized state of both my main window and my aux window were restored, but both were on my secondary monitor. The aux window was on top. I'm using Remote Desktop + Hyper V, so maybe something is going on there: Remote Desktop from Windows to another Windows machine. Hyper V to an Ubuntu VM.
Looks like which monitor is primary and which is secondary doesn't seem to matter as the same thing happens when swap the windows that aux and main are on.
I also experienced a variant of this: Main VS Code window maximized in primary monitor, 1 aux window maximized in primary monitor, 1 aux window maximized in secondary monitor Close VS Code Reopen VS Code All 3 windows (main and aux) are restored to max, but they're all restored to my primary monitor I'm testing on Windows 11 Insiders.


Testing Steps: Use Windows PowerShell (not PowerShell Core) Turn on the terminal intellisense Type stuff is to the terminal


Testing ! This happened when updating the file on disk outside of vscode, I'll try to find a consistent repro
a notebook with several markdown headers in insiders the same notebook in stable and add a header :bug: outline in insiders is not updated (stable does update when doing this in reverse) a different markdown header in insiders :bug: screencheese
!
Thanks I can replicate this issue.
Giving the issue back to Aaron to verify. My Python install's a bit broken.


It seems that works workspace-relative unless an absolute glob pattern is used. I would clarify that from the settings description.


Type: <bBug</ban existing remote project an embedded terminal in VSC "PORTS" tab shows 51 ports This is a vanilla-flavored nodejs service that uses one dedicated port determined by the remote environment (an AWS EC2 instance running Rocky Linux) -- and that dedicated port is not opened until the service is started. I expect at most 2-3 ports to be open at any one time. VS Code version: Code 1.88.1 (, 2024-04-10T17:41:02.734Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 4.18.0-477.27.1.el88.x8664 <details<summarySystem Info</summary </details<details<summaryExtensions (12)</summaryExtensionVersion ------ remote-ssh0.110.1 remote-ssh-edit0.86.0 remote-explorer0.4.3 java1.30.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.3.1 vscode-java-debug0.57.0 vscode-java-dependency0.23.6 vscode-java-pack0.26.0 vscode-java-test0.41.1 vscode-maven0.44.0 markdown-pdf1.5.0 </details<!-- generated by issue reporter --
Can you connect to your remote then share the following: the value of the setting the value of the setting A screen shot of the Ports view
I appreciate your prompt attention, thanks for looking at this. As you can see in the attached "Ports view", this morning there were 53 open ports at startup. I've attached a screenshot of the "Settings" view (searching for "remote.autoForwardPorts") and the "Ports view". I looked in the local "" (in ) and see no settings with the two names you requested. I similarly found nothing in the relevant "" file(s) on the remote server. Hopefully the attached screenshot of the "Settings" view provides the information you requested. ! Settings ! Ports view
is it possible you at some point ran something that listened on each of those ports? By default, VS Code will auto forward ports, but with the setting set to , which is what you have, we don't know when to stop forwarding the port. We also restore ports (setting ). I think the best thing we can do is change the default for SSH for to , which will let us know when to stop forwarding. I've made the appropriate PRs to get that changed.
If something ran that was listening on those ports, it was unknown to me. I don't knowingly do anything with ports on the local (Windows 10 pro) system. I manage multiple ports on the remote system, but each has a 4-digit port number. An aspect that may be of interest is that the startup behavior seems to be specific to this remote folder (). When I use VSC to open a sibling on the remote host (), the embedded terminal shows no forwarded ports at all. Screenshots below show this behavior. ! Startup VSC on ~/tms/backend/gate ! Ports view on ~/tms/backend/gate
We restore ports based on the folder, so it makes sense that you're seeing different ports depending on which folder you have open.
Hmm. It seems likely that at some point something was running and listening on those ports, otherwise we wouldn't have found them and auto forwarded them. I think the change to use by default that I mentioned above will resolve your issue in the future, but for now, I would suggest you unforward all those ports and set to .
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!


Using the workspace TS version, 5.5.0-dev.: ! ! !
Closing for verification


I got the default font rendered in the parameter hint widget. It looks alien compared to the rest of the hover widget UI. Steps: chat sample line 21 type the following: will see the parameter hints with a weird font (default system?) ! fyi
I haven't been able to reproduce this Are you still seeing this issue? Does it only show up with specific functions?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Yes, I still see this. I see this for all parameter hovers. I have nailed this down to be due to this setting I got a new mac, so most likely I do not have Fira Code installed. So the Editor seems to fall back nicely to a good default font, and Parameter Hints falls back to a non coding font. Which looks like the gist of this bug. I will reopen this so you can chime in. Thanks


Type: <bBug</bThe terminal in VSCode - insiders is unable to display special characters in terminals after latest update How it looks in VSCode: ! How it looks in VSCode - insiders ! The font settings are the exact same for both versions VS Code version: Code - Insiders 1.90.0-insider (, 2024-05-03T05:49:15.006Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (40)</summaryExtensionVersion ------ better-comments3.0.2 TabOut0.2.2 Bookmarks13.5.0 doxdocgen1.4.0 githistory0.6.20 gitlens14.9.1 copilot1.184.0 copilot-chat0.14.1 latex-workshop9.20.1 rainbow-csv3.11.0 git-graph1.30.0 autopep82024.0.0 debugpy2024.4.0 isort2023.10.1 pylint2023.10.1 python2024.4.1 vscode-pylance2024.4.1 jupyter2024.4.0 jupyter-keymap1.1.2 jupyter-renderers1.0.17 tensorboard2023.10. vscode-jupyter-cell-tags0.1.9 vscode-jupyter-powertoys0.1.1 vscode-jupyter-slideshow0.1.6 remote-wsl0.88.2 cpptools1.20.3 cpptools-extension-pack1.3.0 hexeditor1.10.0 vsliveshare1.0.5918 autodocstring0.6.1 advanced-new-file1.2.2 material-icon-theme5.1.0 r-debugger0.5.4 r2.8.2 markdown-preview-enhanced0.8.13 errorlens3.17.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.3.1 markdown-all-in-one3.6.2 material-theme3.17.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
can you share your Also are you using Windows PowerShell () or pwsh 6+? Could you get the version of that via ?
Same issue for us using bash 5.0.17(1) so might not be pwsh dependent. Terminal prompt now not showing special characters on latest insiders update 1.90.0 e.g. x1b[01x3b34m~/code/project1x1b[00m (main))
actually got a fix in for bash in
Where can i get the The powershell version is: 7.4.2
I have the same exact problem, and the following suggestion finally fixed it on my end:
I am not sure I understand what the comment is trying to say. I am supposed to replace my with the one from commit and
I agree, the instructions could have been clearer. The commit selection does seem a bit random, but what I did was clicking 'Browse files' on the commit and found the from that repository version. Here's a link to get there directly:
It was pushed to the official build. I'm having this issue and I dont rememeber ever joining any kind of insider program.
Related on Stack Overflow:
thank you so much! This was what fixed it for me after trying everything yesterday. Some more clarity or directions from the dev side would have been nice, but now its back to normal after all!
Thanks replacing the shellintegration.ps1 from this commit fixed it for me. The location of the file is:
In addition to the semi-permanent solution above, I have found that you can simply type (for PowerShell 7) or (for PowerShell 5) in the terminal, and it will launch a brand new, yet identical terminal in the current working directory - but without the gibberish.
FYI, I see this in the regular code branch Version: 1.90.0 (user setup) Commit: Date: 2024-06-04T19:33:54.889Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0. !
To verify: oh-my-posh a PowerShell terminal oh-my-posh, you should not see the escapes as shown above
Same issue here. oh-my-posh, powershell, issue only with vscode, windows term looks as intended. !
This should be fixed in v1.90.2 which was just released
Can confirm as fixed. Thanks for the work!
confirm as fixed and work well without needing to disable setting! !
Looks good again!
Looks good to me too!!
This morning, I updated my VS Code, activated the setting, but I am still experiencing the same issue (especially when I try to clear the terminal with CTRL+L). I am using Windows 10 Pro for Workstations x64, AMD Ryzen 5 5600X 6-Core Processor, and Nvidia 720 GPU. !
Still same issue
what shell/prompt is that?
It's the PowerShell from the Microsoft Store. Special characters appear when I press Ctrl + L to clear the terminal. I also have the same problem in Git Bash, but it happens when I execute a command. In both cases, I am using Oh My Posh. !
I was also having a related? problem with PowerShell integration since the 1.90 release. The recent 1.90.2 update has changed the outcome a little, but not fixed it. I get output like the below when I open a new pwsh terminal, and often the terminal stops responding after executing a command or two. I have this PowerShell profile. I thought any of PSFzf, zoxide, or the encoding settings could be the culprit, so I tried removing each one. Oddly, removing any combination of them doesn't fix the problem, but completely blanking out the file fixes it (second image below). It all worked fine in vscode prior to 1.90. ! !
you have the experimental suggest setting enabled, disabling that will fix it. What version of PowerShell is that you're using? Currently in Insiders we force suggest to be disabled on Windows PowerShell (5), but if you're experiencing it in a latter version maybe we need to disable it in older versions of Windows too.
Are you referring to a different setting? (I was wrong; see below.) (Not sure if it's relevant, but PowerShell suggestions do work in Windows Terminal.) ! !
OOPS, I did have an old version of that setting in my , and removing it did indeed fix the problem. Thank you.
Is there a separate issue tracking this behavior with ? I do not use OhMyPosh and am still getting the same behavior with VSCode . ! The workaround of invoking from within the VSCode terminal does work.


This extension wants me to install it, also has a reload, and has a restart button. The restart button doesn't do anything. This is just in the VS Code repo <img width="476" alt="image" src=""
Can you please share the following file F1 Open Extensions Folder Share file
What do you see in Installed Extensions view? Also What version of that extension is running in Running Extensions editor - F1 Show Running Extensions? Is there a message when you hover on Restart Extensions button?
Installed <img width="470" alt="image" src=""Running view <img width="917" alt="image" src=""Hover of restart <img width="470" alt="image" src=""Ok, so it does appear I have this extension installed. And it wants me to restart it to uninstall it? And then to install it as a workspace extension? Clicking the restart button doesn't do anything and I didn't request the extension be uninstalled
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!


<!-- 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. --Related For migrating towards ESM in VSCode, it seems the tsconfig option could be useful, ensuring that imports are compatible with ESM. For example, this typescript code transpiled to javascript would cause a runtime error because of the export: The rule would enforce a type only import for : Enabling the tsconfig option in VSCode, it seems these files would need to adjusted:
We reverted this because we learnt, albeit very late, that it has disabled inlining of const enums. See


Personal preference - I do not like the border around the attached context. Does not align with the rest of the UI. Do we really need the border? Have we tried this without the border? ! fyi
Yeah, I've tried this because I don't love the weight it adds either. It does cause some weirdness when there are follow ups and lots of pills. But I'll keep playing with it to see if I can get to a place where we don't need it. !
Thank you David!


Type: <bBug</bI ccould not close inline chats or quick picks anymore. Looks like captured all esc shortcuts. I had used voice input during the session. VS Code version: Code - Insiders 1.90.0-insider (, 2024-05-17T17:53:51.447Z) OS version: Darwin x64 23.4.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (64)</summaryExtensionVersion ------ html-snippets0.2.1 tsl-problem-matcher0.6.2 emojisense0.10.0 github-markdown-preview0.3.0 markdown-checkbox0.4.0 markdown-emoji0.3.0 markdown-footnotes0.1.1 markdown-mermaid1.23.0 markdown-preview-github-styles2.0.4 markdown-yaml-preamble0.1.0 mermaid-markdown-syntax-highlighting1.6.3 vscode-tailwindcss0.11.68 esbuild-problem-matchers0.0.3 vscode-eslint2.4.4 kusto0.4.4 EditorConfig0.16.4 prettier-vscode10.4.0 auto-close-tag0.5.15 auto-rename-tag0.1.10 codespaces1.16.22 copilot1.194.885 copilot-chat0.16. copilot-nes0.0.1 remotehub0.63. vscode-github-actions0.26.2 vscode-pull-request-github0.89. headwind1.7.0 debug-tracker-vscode0.0.15 peripheral-viewer1.4.6 vscode-azureresourcegroups0.9.0 vscode-docker1.29.1 vscode-dotnet-runtime2.0.5 debugpy2024.7. isort2023.13. python2024.7. vscode-pylance2024.5.101 jupyter2024.4. jupyter-keymap1.1.2 jupyter-renderers1.0.17 remote-containers0.366.0 remote-ssh0.112. remote-ssh-edit0.86.0 remote-wsl0.88.2 anycode0.0.73 azure-repos0.39. cpptools1.20.5 live-server0.4.13 remote-repositories0.40.0 remote-server1.6. vscode-github-issue-notebooks0.0.130 vscode-markdown-notebook0.0.26 vscode-selfhost-test-provider0.3.25 vscode-speech0.9. vscode-typescript-next5.5. prisma5.14.0 vscode-xml0.26.1 vscode-yaml1.14.0 kuskus-kusto-syntax-highlighting2.0.2 svg-preview2.8.3 pdf1.2.2 vscode-mdx1.8.5 volar2.0.10 gitblame10.11.0 markdown-all-in-one3.6.2 (3 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
are you certain its that command? It is only enabled when a voice chat session is active. When you set the log level to trace, please check what is printed when you trigger in the chat widget:
Happened again on a different machines. The main step of the STR seems to be using voice input (I mostly demo the hold down key usage) Both times I did troubleshooting and it pointed to the stop listening command.
I need some steps to reproduce that you lead you to the issue and the precise location in the UI where this happens (globally anywhere or when you are in a chat input field?)


a chat request that yields no code blocks the response with the keyboard in screen reader mode left and right arrows are in toolbar !


Testing I select a set of cells with Shift+Click, and I hit Ctrl+F to open the find widget. The cells are then highlighted as such: <img width="981" alt="image" src=""I scroll down a full page length, and then scroll back up. The cells are now highlighted as such, with no click or type input on my part: <img width="980" alt="image" src=""It appears that the Code cells lost their yellow highlight.


<!-- 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. --Version: 1.90.0-insider Commit: Date: 2024-05-31T01:05:41.342Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code-Insiders/1.90.0-insider Chrome/122.0.6261.156 Electron/29.4.0 Safari/537.36 Steps to Reproduce: There is no test-log-channel in the output panel.
Thanks for reporting this I have the exact same issue. In the meantime I have a workaround: I was surprised this does not throw, usually if you create something that was not previously disposed, it will throw an error like "command was already registered" or "notebook controller already exists". I am currently commenting out my line in my extension. It's not ideal though.
PR fixing it


Have the following code Move line request down via Notice how the lines that have been passed change. Their indentation gets modified. The move line down command should not mutate lines it passes.
See and for similar/duplicates.
should be fixed by
Thanks for the fix!


Type: <bFeature Request</bCC setting is ignored when accessibility mode is on. While screen reader's TTS can auto-announce Chat response, some users may want to use this new synthesizer. so, we may want to turn off aria-live when this setting is on. Another consideration is that some low-vision users, who don't necessarily use SR, have turned on the a11y mode and they still want to benefit from this auto-synthesize setting. VS Code version: Code - Insiders 1.91.0-insider (, 2024-06-10T05:48:36.787Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
Makes sense cc
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
would you, yourself, enable this? I worry about turning off regions.
I don’t know whether I would turn this on permanently, but would like to try this out definitely to see if it gives me any new experience. I may be able to manage to listen to two different TTS simultaneously (one for Copilot; SR TTS for my own drive).
That makes sense. It would be great if you could try it out. You can do this now by using the action in the toolbar,
Yes, I have tried this, but this is a manual trigger which does not give me the same experience as the auto-read-aloud.
do you mute NVDA speech and use a braille device when you want to use voice input? or do you use a separate speaker/headphones? When testing this experience, the screen reader's speech is getting recorded by the mic and used as chat input for me unless I mute VoiceOver speech.
That happens when microphone is too sensitive. SR users need to mute their speech synthesizer or they need to use a different sound card or headset.
I use a separate sound card for my screen reader.
what are some verification steps for this issue?
enable screen reader mode, adjust the setting to on, run a chat request, (make sure volume is up), hear the response
I am still unsure what to test and what I should hear. I followed the steps and didn't hear the chat response. I only heard it when talking to chat in the first place.
Sorry - in order to hear the response, I forgot that you have to use voice input to the chat. So pls try that with screen reader mode enabled and that setting on.


When I use the command line code --install-extension {id} Cannot find the installed extension Vscode - userdata: $HOME /. Vscode/extensions/extensions. The json. This error only appears in version 1.90.0, but does not exist if you go back to version 1.89.0.
This only happened the first time, and it worked the second time I executed the command line to install the plugin. So did everyone else around
Are you still seeing this issue? If so can you please provide steps to reproduce?
My plug-in is a private plug-in that updates through the code command. When I released the updated version of the plug-in, I used the code command to update it, and there would be an error the first time, and it would be successful the second time, which was stable. !
TLDR: The issue happens when a version that was installed before is installed again I have pretty much the same scenario. A private extension that uses to update itself when a new version is available. This is the error that's logged: I do have an entry for my extension in the file though: I did some testing on a bare project to understand the failure mechanism. What I found out is that if a particular version of the extension is installed before (for example during my testing before I release the extension) then upgrading/downgrading to that version will fail. Using following steps I can reproduce this issue reliably: 1- Create a bare project: 2- Package the extension: 3- Increment the version number, and package again: 4- Install the first package: 5- Update to second package: So far everything is in order. The problem begins when we try to install any of those packages again: 6- Downgrade to first package: At this point the neither 0.0.1 nor 0.0.2 is shown as installed. So installing any of them will be successful. this explains why you're always getting the error on the first, but the second round is successful. 7- Install the first package again: 8- Update to second package again: Tested this with Windows and WSL Ubuntu. Happens only on WSL Ubuntu in my case.
<!-- 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!
Looks like this is working now in the latest VS Code Insiders. Tried with WSL: And using the latest stable (which doesn't have the fix yet) I can repro the errors that describes.


<!-- 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: 1.90.0 OS Version: Darwin arm64 23.5.0 (macOS Sonoma 14.5) Follow the section of the Then, in the the first step (after connecting to the container) is to run: Yarn install should complete successfully, and should run the app. We get the following error: <img width="803" alt="yarn-install-failure" src=""According to the we're using . 20 is the current LTS, and 18 hasn't been in active support since October last year. We can use the node 20 version of the typescript dev container image: . For context: there was a compatibility issue with and node 20, as noted in the issue when we switched to the node 18 image: But it seems like this was resolved in : And we're on , so it should be fine
I've linked a PR with a fix. As suggested the last time this issue popped up: a CI test for the dev container could be useful.


have a squiggle open inline chat for it the UI flickers when coming up
I believe the is the same underlying cause as Drilling into this and it seems that setting follow up always triggers a layout with the "old" dimensions which isn't going fit. I believe that explains why the editor is looking so weirdly. It only gets very little height left IMO setting follow up should only trigger a content heigh change event so that the owner can issue a relayout but should not attempt to relayout with the existing dimensions. (maybe unless the number of follow up has changed in which case the content height didn't change...) <img width="1412" alt="Screenshot 2024-06-18 at 16 47 47" src=""
tried this is a notebook and it felt very jittery still (but in a regular file it was fine) should I create a new issue for this? Seems to be due to the inline fix dialog getting placed in one spot then immediately moved <img width="1273" alt="Screenshot 2024-06-26 at 10 31 06 AM" src=""<img width="938" alt="Screenshot 2024-06-26 at 10 31 01 AM" src=""


<!-- 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: 1.90.1 x64 OS Version: Ubuntu 24.04 (Updates 14 Jun 2024) I get the error on a fresh installation of Ubuntu 24.04 and VSCode 1.90.1 Everything works fine with VSCode version . Steps to Reproduce: latest version of Ubuntu 24.04. command. command.
In my case the issue occurred when doing , also on Ubuntu (20.04) and also on vscode 1.90.1 Here is a temp workaround to revert to vscode 1.89.1, if that's useful to anyone:
Hi Having same issue on remote VM Ubuntu 20.04 Install errors with Solved by using the flag


Seeing this logged about 100 times at startup. Let's avoid stuff like this in the log level


I think the editor used to preserve the vertical position of the line where the the cursor is in. It jumps now: ! Repro steps: Enable Code Lenses for TypeScript Navigate to a symbol in a file that has not been opened yet Notice that the editor reveals the symbol correctly, but without code lenses yet Notice that the editor jumps once code lenses appear Verification steps: Observe that the line the cursor is in does not jump anymore. If I don't misremember, there was a change made here recently?
No changes for code lens since long. Doesn't reproduce for me. Can yo consistently repro? Can you try without custom settings?
The current logic is to keep the first line in the viewport stable. A good improvement might be to keep the line where the cursor is stable (if it's in the viewport), but that is not what we have implemented. PR welcome.
Oh, somehow I didn't realizing the jumping then. Did you open this file before in the VS Code session? In the first frame of your screenrecording where shows, the code lens feature already reserved some (empty) space to prevent layout shifts (which I don't think the feature knows the first time the text model is opened): !
Between reloads the slots are persisted and optimistically shown for a couple of seconds so that the actual extension/provider can compute theirs (which is usually the same)
I think there is something fishy going on with persisting the code lens cache ().
<!-- UNABLETOLOCATECOMMITMESSAGE repo --Issue marked as unreleased but unable to locate closing commit in repo history. If this was closed in a separate repo you can add the label directly, or comment .
<!-- UNABLETOLOCATECOMMITMESSAGE --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
Closing in favor of (which proposes one possible solution to this). To be honest though, I think is what caused my feeling of this happening much more often.


Testing text buttons some code and ask "What does this do?" starts, and the "ctrl+esc to stop" button shows. . actually opens the Windows start menu and streaming continues. It seems like this is a default Windows shortcut.
This is the default keybinding (the one we use in all chat boxes) and it looks like we need something else on windows...
They have a whole keyboard button for that, why are they taking ctrl+esc too...
Going with alt+backspace. Would like ctrl+backspace, but you might start typing while the previous request is running, and still want to use ctrl+backspace to delete a word.
Works great!


Testing Hover in Chat View doesn't respect underline setting (expect to be underlined): !


Type: <bBug</bPreparation: create the following file: the terminals panel, create a new shell terminal it to the main editor area to make it a full-size terminal open an editor tab (any file will do, including Command-N) sure the panel is closed (press Command-J to close it if it is open) the above task (e.g. with Command-P, then type ) Expected: the panel opens and shows the running task Actual: the editor terminal is brought to the front, and the panel stays closed VS Code version: Code - Insiders 1.92.0-insider (, 2024-07-11T05:03:58.450Z) OS version: Darwin arm64 23.5.0 Modes: <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
In this scenario, focus also fails.
I can confirm that fixes the problem for me. Thanks!


Testing 1) select a cell 2) cmd+/ -cell commented 3) ESC 4) cmd+/ -nothing 5) arrow-up 6) Cmd+/ -nothing 7) Shift + arrow-up 8) Cmd+/ -two cells commented I don't really understand in which mode I'm in after step 3 and 5. I would expect Cmd+/ to work in those states.


<!-- 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?: 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. --Version: 1.91.1 Commit: Date: 2024-07-09T22:06:49.809Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: a TreeView with an TreeItem the TreeItem's iconPath to the extension. The TreeItem's icon will still be yellow same as in debugging. After inspecting developer tools, this is likely due to how the icon debug-stackframe's color rule is set to !important. The ThemeColor fails to overwrite it due to low specificity. This may not only happen with the icon "debug-stackframe" and is affecting customisations of treeitems. Why is some icons' color rules given the !important flag et al? There might not be any easy fix due to this flag's present. I hope the team could look into it, and if possible fix this selector specificity issue (if it won't break vscode, somehow).
Edit: This not only occurs on special icons like debug-stackframe, but also on very ordinary ones like circle-filled. style attribute { color: rgb(204, 204, 204); } .monaco-workbench .codicon { } Adding !important to the color flag of .monaco-workbench .codicon will fix the issue though.. The problem is worse :C
I think the best solution would be to get rid of that . it's coming from here. Can it be removed? The css you shared is correct. The rbg value is the one you set in your ThemeIcon. !
Yea, we should scope these rules better (and also move them to css now that we have variables there)
<!-- UNABLETOLOCATECOMMITMESSAGE --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


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.92.0 Commit: Date: 2024-07-31T23:26:45.634Z Electron: 30.1.2 ElectronBuildId: Chromium: 124.0.6367.243 20.14.0 V8: 12.4.254.20-electron.0 OS: Linux x64 6.9.3--generic Steps to Reproduce: theme to Light High Contrast a Javascript file final bracket is black, not red as in other themes
I believe this may be the core cause: The value for hcLight here is just an empty string
Thanks for investigating, looks like this color got forgotten when creating the Light HC theme. I took the same color as used in the overview ruler


As reported by open notebook open nb from timeline close diff close notebook then I got Can repro from stable


<img width="1072" alt="image" src=""<img width="838" alt="image" src=""


<!-- 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 No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- 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. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!


Testing Repro steps: some changes to a cell, in my case I a cell with some content the changes some lines from the cell that was in step 1, and save. diff view launched from "changes" SCM view should diff between staged and working.
Now the diff view for the changes in the 'Staged Changes' group is the same as the diff view for the unstaged changes
I am seeing it as I would expect. This is diff launched from staged (where the cell was ) ! This is diff launched on unstaged: !
Works for me too, can you share the text file contents in the 3 cases Commited ipynb Staged ipynb & finally changed ipynb
Original steps LGTM
Original file: ! Modification 1: ! Modification 2: ! Observe that the diffs for the Staged and Working Changes regions below are identical !


Testing I think we have another issue discussing a similar issue. This hover and the main item hover can conflict with each other: <img width="579" alt="Screenshot 2024-08-27 at 10 37 49 AM" src=""Instead of having a special hover just for the badges I think the main hover accomplishes the goal just fine as the badge and its description shows up at the bottom: <img width="698" alt="Screenshot 2024-08-27 at 10 39 05 AM" src=""


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.93.0-insider Commit: Date: 2024-08-29T05:04:03.909Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Linux x64 6.9.3--generic Steps to Reproduce: a few editor groups in seemingly any split configuration one for text input or otherwise run to type: no result, as no editor has focus any more. This is especially frustrating when some of your other keyboard shortcuts rely on the editorFocus context, as they become unusable after using this feature.
In case this takes a while to fix, anyone looking for a workaround can rebind their preferred shortcut to automatically refocus the editor and then "move" the cursor to ensure if another window has now covered your cursor, the editor scrolls to reveal it again (also respecting scrolloff setting).
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


Enable the setting which enabled the native edit context adoption Copy some code which is more than 3 lines long Paste the code. The code that is pasted does not correspond to the code that is copied
After some investigation, I have noticed the following curious points. In the following, please note that to fix the long-press-E chromium issue, we essentially always write the screen reader content which means we always change the document selection. When screen reader is toggled off: When we read the copied text from the the electron clipboard in order to paste, it is incorrect When we remove the logic that sets the document selection for the screen reader content, the pasted text is correct When screen reader is toggled on: Text that is read from electron clipboard is always correct In fact interestingly when we revert the changes we have made for the long-press E issue, then this copy-paste issue no longer occurs! Since the long-press E issue is not important, and copy pasting is much more important, I believe that we should revert that fix. From this I believe this could be somehow related to a chromium bug. cc
I have made the following PR to revert the long press E fix : This fixed copy-pasting too.


Enable the setting Open the editor Open the find widget Type several letters The editor is focused as soon as there is a match for the find result It is no longer possible to continue typing in the find widget without retriggering the focusing of the find widget


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.93.1 OS Version: Windows 11 Pro Originally from To Reproduce Steps to reproduce the behavior: an empty dart project (can be any language, this is just the one I use of course) the code below breakpoints on both and print calls the breakpoint on the trigger only after the one at (screenshot) the code and make sure the breakpoint stops the program that triggers before Expected behavior For the triggered breakpoint to wait again on restart. Also note that there are two ways to restart a debug session too - a full restart handled by VS Code (which is what happens for Dart above), and a restart that is delegated to the debug adapter (which we use for Flutter to do Hot Restart, so it's faster than a cold restart by VS Code). In both cases, this state should be reset. Screenshots ! <details<summaryRelevant debugging log part </summary</details// CC:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.93.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Interestingly, I cannot reproduce this with JavaScript using an equivalent file: Unfortunately I don't think it uses DAP and I don't know if there's a way to get a log of what's happening there. It's not clear to me how it could be working there given the DAP traffic captured for Dart. Someone familiar with the implementation of Triggered Breakpoints or the JS debugger might be able to explain what's going on.
I can on python:
I am also running into this issue
This is probably because the JS debugger has each debugee as its own, child session, and when restarting JS you will retain the parent session (handled by the DA) but get a new child session that doesn't have the data set.
I am debugging Go. I don't remember seeing it with other languages but I also only rarely run anything other than Go.
yea, it's reproducable with Python too. Fixed in Monday's Insiders.


today's insiders open GHINB and run a cell see errors (many) on the console
broke
We should also add a custom eslint rule for this. It has been broken for a few weeks and it regresses the output focus context keys.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.95.0-insider OS Version: Windows 11 Steps to Reproduce: : window to message and use <kbdShift</kbd+<kbdEnter</kbd<kbdShift</kbd+<kbdEnter</kbddoes not work in Source control message text area if option is enabled. It seems that it occurs not only in but also when I edit any file. <hrMaybe related to
I see thank you for filing this issue. I will look into it.
Hi may I ask you what you were expecting to see? I turned the setting on and off and press when I have no commits to make and a notification pops up mentioning that I have no changes to commit. Thank you.
Hi, thank you for checking it out. I expect that a new line will be , the same as with just pressing <kbdEnter</kbd. By the way, the same issue occurs when I edit a file.
Hi thank you for clarifying the question, yes I am able to reproduce this behavior. This happens because we don't send a new line event when we receive the event. I will make a PR to fix this.