<!-- 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.88.0-insider OS Version: Darwin arm64 23.2.0 Steps to Reproduce: folder text View as Tree View as Tree ! View as List ! Mysteriously, some of them do show up when run in a project with many folders...
Did not reproduce in
Same for me: Version: 1.88.0-insider (user setup) Commit: Date: 2024-02-29T22:51:22.369Z Electron: 28.2.2 ElectronBuildId: Chromium: 120.0.6099.276 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0.
Also for non-tree view it doesn't show the single result: 3 results shown: ! 1 result isn't shown: !
watching :
There is no way to set aiResultsVisible and it always returns false now. The hasDownstreamNonAIResults called here should also only contain NonAIResults, so it is false and should not be in the if statement, but it is now. Upon deeper investigation, we found that it occurs under the following conditions. It seems that the deepest part of the TREE is not displayed in this way. This is because the folderMatchesIterator is retrieved, but the deepest point is always [] and [].some() =false. You also need to look into fileMatches iterators.
Apologies for the inconvenience, and thanks for finding the fix!


It runs the correct intent, but renders rather than ! ! This does not happen in panel chat
You implemented this, right?
Yes, the problem is here


The code in question looks like: This doesn't actually do anything, and is likely a bug. There are a few cases in .


Issue Type: <bBug</bFold a region and observe it. Unfortunately this went away after a window reload: VS Code version: Code - Insiders 1.66.0-insider (, 2022-03-23T05:27:08.615Z) OS version: Darwin arm64 21.4.0 Restricted Mode: No <!-- generated by issue reporter --
There haven't been any changes from mein that area recently. Likely a Chromium glitch. Please reopen if you have it reproducible.
I still don't know why this happens sometimes, but it shows up regularly. In the dev tools it shows that chromium has loaded the stylesheet in a wrongly encoded way. I hope to avoid this by escaping the ellipses unicode character.


<!-- 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


with the remote repositories and codespaces extensions installed the remote explorer on under prompt (see ) escape to close and cancel Bug A url is still opened Version: 1.68.0-insider Commit: User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.64 Safari/537.36 Embedder: <!-- generated by web issue reporter --
I'm not seeing the section that Matt describes in the linked issue. !
The remote explorer is in the sidebar: !


When I disable the "Show raw keys" option (showKeys) in the VS Code settings, the editor no longer shows the shortcuts either. If the "showKeybingings" option is enabled it should show the shortcuts. This is not behaving the way expected. !
When I set these settings: <img width="652" alt="image" src=""I still see the command if I hit . You don't see it?
Unfortunately it doesn't work for me in this same configuration. Version: 1.85.1 Commit: Date: 2023-12-13T09:47:11.635Z Electron: 25.9.7 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Linux x64 6.5.0-14-generic
I found something strange. Some commands works fine, like "Ctrl + N", "Ctrl + P", "Ctrl + Shit + P", "Ctrl + Tab". But it still doesn't work with commands like: "Ctrl + C", "Ctrl + V", "Ctrl + A", "Ctrl + X", "Alt + Arrows", "Ctrl + Arrows". Could you please test the commands when editing code?
Sadly this is this: A big chunk of our internal commands simply do not have good descriptions. It requires a large change over the code base. Feel free to send a PR my way which adds descriptions to the few that you are dependent on, if this is important.
Ok, but I would like it to show commands such as "Ctrl + C" even without a description and that is not happening. If I set it to show only the commands it continues to behave the same way, without showing the commands in the editor part. I remember that when I sent the commit that fixed some problems in the screencast, it was working perfectly, but now it no longer works. ! It still doesn't work in this configuration.
You simply closed the issue and didn't even understand the problem I brought up. I see that these are two different problems. This is very frustrating...
You're right, sorry for jumping the gun there, and thanks for the additional explanation. Fix coming.


<!-- 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?: It requires at least the remote SSH extension to be enabled due to the nature of the bug, all other extensions can be disabled/uninstalled. <!-- 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.75.0 OS Version: Local Windows 10 21H2 / Remote Fedora 29 Steps to Reproduce: -up VS Code with Remote SSH Python Extension in to Remote SSH error message and get asked to download manually opens link: the following error text: it's because the extension hasn't been published for 2023.2.0 for Linux yet so try installing older version same error and browser instead opens this link: very similar error text: I have had to revert to 1.74.3 where I am not getting this error so can I continue to work, but if you need me to test things again I can install 1.75.0 again and retest.
I am having the same issue since upgrading to VSCode 1.75.0. When trying to update the Python extension on the remote server I get an with the log Trying to download manually brings me to the as reported above. I am getting the same errors for the Jupyter extension. I could successfully update the extensions locally. VSCode: 1.75.0 OS: local openSUSE Tumbleweed / remote Red Hat Enterprise Linux 8.5 (Ootpa)
I have the same problem.
Same issue. Downgraded VSCode to 1.74.3 to restore functionality.


VS Code Version: 1.75.0 OS Version: Local: macOS Monterey 12.6.3 Remote: Amazon Linux 2 w/ Kernel 5.4
Triaging this issue I am unsure if the initial post with the error message of is the same as the error with the message . Therefore all conversation on the issue should be moved to this other issue: Thanks
This issue is related to target platform and not related to sign verification.
Yes, I am initial poster, I also get the signature untrusted error. I assumed the two errors had the same underlying cause, i.e. when VS Code made the web request it got the above error which does not have the signature of the extension and therefore throws a red herring of "Untrusted: Signature", then when VS Code prompts you to download it manually you can see the actual underlying error. This is why I posted the latter error and not the former error. But if you are convinced they are two separate errors then it makes sense to track them separately. But be aware I got both errors, and everyone else who has posted seems to have also got both errors.
Thanks for the info It seems that the root cause is signature error for you too. Being said that the manual download shall work. Can you please share the link you are using to download the VSIX?
From the marketplace web page. Version History -2023.3. -Download Manual download and install work for me.
As per my original post the link that VS Code to manually download the extension is: Which gives this error:
It seems VS Code is generating an invalid download link. Updating this issue for fixing the update link. For signing related, please refer to
I'm not sure how to get this, are there repro steps?
To verify Open extensions view Browse for eslint extension (any non platform specific extension) Disable network connection Click on install, you shall see a prompt to Download Manually Enable network connection and click on that Download Manually button Make sure the VSIX is downloaded/


Moving this over from After the backups are not restored if the workspace directory doesn't exist anymore. The workspace is no longer tracked but the backups are kept around in the backup directory should they be needed later.
Tricky.... I would expect an empty window to open with those files dirty. This might require some work on the area of restoring on empty workspaces. Have not thought about this longer yet.
Marking as important because this means data loss if the folder is deleted on disk.
maybe this should be done on the main side on startup similarly to If a folder no longer exists, convert it into an empty workspace backup and let it open as empty window.
On test plan:


Testing scenario in Codespaces web UI Opening a Python file in a fresh codespace Web UI shows a notification: ! Clicking on Yes shows ! VSCode desktop is opened Python calls VSCode should intercept that URI and handle it by directly opening the extensions viewlet and not make an external call
Unassigning myself as it seems url handling related. Please let me know if there is something I have to do in extensions area.
What do you think? Should we perform the fast-track to handle these URIs internally?
I can't repro this in desktop Code. I can repro in web
I couldn't get the Python extension to show that dialog again, so I verified that with my own extension that does That code is inspired by That code works and, on codespaces now directly opens the extension viewlet. -verified However, if you do '();' it opens the external open dialog again. In the first case the URL has a relative path (), in the second one an absolute (). Relative paths are kind of rare. Is that all as designed? Or would it be better to also accept the absolute path?
Paths are not required to be rooted in , or even separated by characters: they can be arbitrary strings within the allowed character set. We've long defined extension URIs to simply be . Not sure if you've seen the format anywhere in our docs? If so we gotta fix it.
I will have to revert the fix for this, since it broke existing functionality. With the fix, a web extension can no longer actually open a URI in desktop Code. When looking at the breakage, I no longer this this is true. If is invoked, it should always be handled externally, never internally, unless it's absolutely obvious (running in Desktop). The right way to move forward here is to have the Python extension run the instead of calling .


VSCode Version: 1.37.1 OS Version: Linux x64 5.1.14--generic Steps to Reproduce: a search term (make sure it actually exists in the current document) the replace term empty the match case box Ctrl-Alt-T the error ! Does this issue occur when all extensions are disabled?: Yes
What does do here? I don't think I have that keybinding.
I think I meant Ctrl+Alt+Enter, the shortcut for replacing all. I am not sure if it is the correct shortcut (I don't have access to my laptop right now), but it is not specific to it. I am guessing replace or replace all will trigger the same bug.
I can't reproduce it. It would help if you can try it again and get the full error stack from the developer tools (Help Toggle Developer Tools)
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!


Tracks updating the TS 5.4.4. recovery build
Actually may wait for TS 5.4.5 with a fix for auto imports
Merging 5.4.4 for now


The "Open in Terminal" does nothing when the current window has no folders. Instead, if there are no folders, it should open a Terminal window in the same directory as the current file.
this works for me, how are you running "Open in Terminal" exactly?
I'm using while I have a saved file focused in VSC. !
That command opens the active workspace folder currently. Maybe we should fallback to the active file if there is no folder open? Open to PRs
I would like to work on this as my first bug. Could I get some advice on how I should go about fixing this?
Great! All the external terminal code is located in the "execution" part You change will be in here: Utilizing the (see for how to pull it into that file).


Type: <bBug</bo meu terminal do vscode ficou todo preto derrepente, ele esta normal e quando fui abri-lo estava preto, nao consigo resolver e nao posso voltar a minha rotina por causa disso. My vscode terminal suddenly went all black, is that normal and when I opened it was black, I can't resolve it and I can't get back to my routine because of this. ! VS Code version: Code 1.81.1 (, 2023-08-09T22:22:42.175Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (8)</summaryExtensionVersion ------ turbo-console-log2.9.6 gitlens14.2.1 auto-rename-tag0.1.10 copilot1.105.350 prettify-json0.0.3 vscode-language-pack-pt-BR1.81. vscode-thunder-client2.10.5 vscode-icons12.5.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Please write the pn in english.
/duplicate
can you share your file?
here it is
Confirmed that is disabled by default. I have now enabled terminal gpu acceleration and images, though I'm not sure whether I'll run into the issue on this machine.


Currently there are only tests for the groupview but not for the model. Add some test to make sure there will not be any regressions in the future.


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The vscode shell integration currently needs to be turned off or disabled for anyone with complex prompt commands, or any trap DEBUG. Please consider supporting some kind of chaining model so we can work with the shell integration as needed. Even better - use the defacto package that has already been written. VSCode is the 3rd script that wants to mess with prompts and traps - but it's the first to completely ignore Please consider shipping this along side and sourcing/using it. If that is unacceptable, consider at least detecting this module has been loaded as documented in the repo - and using it: fwiw: iterm2 has very very similar functionality to the vscode shell integration, but I've been able to work with it. Although they embedded the script directly, they kept the compatible function names and mechanisms and interop fine.
I believe we have already fixed this: Adding to make sure
Well, line 100 breaks my prompt. Adding the line as the 1st line of vscpreexec shows why. I think perhaps there needs to be 1 more state 'not in prompt' that causes preexec to bail until all promptcommand processing is done. Alternatively, if this is all to send vsccommandoutputstart - it seems like using PS0 on bash = 4.4 would be a lot cleaner?
Hi This was on 1.67.2 with dropped in place.
We've made some big changes in the past few days around debug trap and PS1 handling in bash, I believe the issues here are fixed. We may at some point hook into similar to but for now that will just increase the number of cases we would need to test for (contributions very welcome).
Actually I'll keep this open with help wanted to track integrating with bash-preexec.
OK. Pulling the - Things look better, but not quite right. The problems I see (only when DEBUG trap is being used): Still seems to be not preserving $? for promptcommand Seems to execute the trap twice. repro with setup instructions below: Do 'cd' into some directory. The command '..' should then pop one directory up, but it will try to process twice and pop twice.


Instead of 'success dots' in the gutter, all commands seem to think there are fail exit status. Here are my dotfiles: and a branch to help debug: The debug branch just build an array of what commands were that triggered the trap and print them at the start and end of building the prompt. It does show the trap being called twice when shell integration is enabled - and once otherwise. The repro environment/steps: Repros in OSX and WSL Ubuntu 22.04 for me. It uses dotbot. In a scratch user directory you can run ./install to link everything into ~/. Pass to ./install to avoid installing extra tooling it finds missing (pygments/tmux/coreutils)There is a script that get's sourced . This is the root of all evil. It's on the hacky side. The function is small and is (I believe) the only relevant part. I should stop using it, but it's sooooo_ ingrained into my muscle memory. To verify: Removing from makes everything work great with none of the above mentioned problems. One hack, that seems irrelevant is that uses debug trap directly, but also detects and uses the pre-exec infrastructure if it has been loaded (to not break iTerm2's shell integration). I appreciate the time and effort going into this feature. It's becoming a shockingly advanced embedded shell environment.
thanks again, planning on tackling this in June
I use just merged in a fix for this. It would be great if someone could help verify in tomorrow's insiders build as I'm not normally a user of bash-preexec.
Still some problems around . Very simple repro: clean environment. My bash and vscode versions are: use this .bashrc: For me (In WSL, repros in plain OSX): ! Without ! If extdebug works, then this would be the next simplest test (I think). Same clean environment. The following
Are there verif steps for this?
<!-- 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!


With the more complicated scenario, the decorations don't seem to show blue and red anymore. ! I realize that in the screenshot I forgot to add , but that didn't make a difference.
what is your exact debug trap when that happens?


<!-- 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. --Currently, it is treated as . (I have disabled all my extensions and confirm this behavior) It does support as comment like does. A simple workaround now is to set But it's nice to have it built in supported.
Clone the repository Open the repository in VS Code Insiders Rename to Open the file: Confirm that the file type is detected as "Ignore" Confirm that the comments in the file are coloured correctly


Type: <bBug</bCC CC I create a terminal in VSCode, press shift+alt+f1 to display the accessibility help, and then press the esc key to dismiss the displayed information. I believe that the focus should be moved back to the terminal but it doesn't. I need to press shift+tab to move the focus back to the terminal. I tested using orca but I believe the same happens using nvda, I'll test later. VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-09T05:23:03.109Z) OS version: Linux x64 6.1.9-200.fc37.x8664 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (37)</summaryExtensionVersion ------ doxdocgen1.4.0 vscode-markdownlint0.49.0 vscode-chatgpt3.5.9 rest-client0.25.1 better-cpp-syntax1.17.2 azure-pipelines1.208.0 vscode-docker1.23.3 csharp1.25.4 vscode-kubernetes-tools1.3.11 remote-containers0.278.0 remote-ssh0.97. remote-ssh-edit0.84.0 azure-account0.11.3 cmake-tools1.13.45 cpptools1.14.1 cpptools-extension-pack1.3.0 makefile-tools0.6.0 powershell-preview2023.2.0 remote-explorer0.3. vsliveshare1.0.5828 fabric8-analytics0.3.6 java1.15. vscode-xml0.25. vscode-yaml1.11.0 sonarlint-vscode3.14.0 cmake0.0.17 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-boot-dev-pack0.2.1 vscode-spring-boot1.44.0 vscode-java-debug0.48.0 vscode-java-dependency0.21. vscode-java-pack0.25. vscode-java-test0.37. vscode-maven0.40.


vscode-spring-boot-dashboard0.10.1 vscode-spring-initializr0.11.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --


! It could be that I caused this, but I doubt it (injected text has nothing to do with the gutter, maybe they shared a CSS rule).
I can reproduce but I'm not aware of any changes in that area from the debug side.
I would like to work on this issue!
Before fixing anything we should do a "git bisect" to find the commit that broke this.
commit . it should
thanks for pointing out the commit! If you like, you can provide a PR, that would be awesome!
PR


In that case, I think changing the label to be just email would be best. Then all of these sessions in my example screenshot could be grouped as one. If you deduped per-label with the current labelling it would show two accounts, one that represents 3 tenants, and another representing another single tenant. That would still be pretty confusing. IMO there's two options: Dedupe by email and hide all tenant related stuff. Signing out of that account removes all sessions associated with that email, regardless of tenant. Don't dedupe at all, instead include the tenant display name in the label as .
says this works!


Testing ! I would have expected it to be centered.... though this could just be this codicon.
Is this happening with all codicons or just this one?
I can see it for codicons. Fixing it


<!-- 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.91.0 (Universal) OS Version: Darwin arm64 23.5.0 Steps to Reproduce: new profile test to new profile in Devcontainer sample container is loaded without extensions. Opening in DevContainer with the default profile works correctly. Works correctly with the previous version of vscode 1.90.2
Same For Me
+1 extensions from are not enabled in the container when using a custom profile. Although the container logs does report that the extension was successfully installed, and I can see it is installed in the container, in . It's just not enabled when using a custom vscode profile.


<!-- 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.83.0 OS Version: macOS Sonoma(14.0) Steps to Reproduce: the color theme to high contrast any theme to extension search (I have attached a picture below which you will see there) will see no border-right edge of the install button !
I'll start trying to fix this weird border-right


Similar to but for libraries... Here are the docs for : <!-- 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. -- (, ) (, Needs version bump)
The HTML/CSS/JSON services are now all using adds the code to configure the servers with location of the localization bundle


Repro: Open DevTools: !
This started occurring recently due to It is now possible to get this warning from various parts of the product.
Yes. That's on purpose and the goal is to get rid of invalid URIs in our system. So, when your code causes such warnings, you need to change it ;-). I can consult. The background is that an URI must have a scheme but we never enforced that. The warning I have is the first step into that direction.
The warning is valid. We're passing a path to , which is wrong. Git remote addresses are not always uris, they can be paths; even relative paths.
So the consumers of should beforehand check if what they are passing is valid uri or not? Doesnt that fail the purpose of ? is used to parse json content. We can pass non json to it as well. It throws an error. Can we not expect something similar from ? If we are worried that throwing errors will break existing code, then can we have a stricter that we can use?
Yes, parse will throw an error but it never used to do that for missing scheme. I didn't think it's a good idea to now start throwing errors at first because not everyone encloses in a try catch block and also often people confuse and .


The new notifications pop open at the lower right corner of the editor. Some command palette actions pop these up with a button that I need to click on to proceed. In these cases, I have to move my mouse from the top center of the window down to the bottom right corner of the window. One such example is the "Git: Delete branch" command. I have to click on the branch I want to delete from the drop down selector, then click the notification button far away in the corner to confirm the delete. If I am deleting multiple branches at a time (because I'm finally cleaning up my local state ) I have to move the mouse back and forth a ton of times so now I use a terminal for this task instead. It would be nice to have an option that lets me decide where I want the notifications to appear. I would choose the top right corner to reduce mouse movement.
I'll narrow this issue down to make the delete branch popup a modal one, which it should be anyways.
I'm trying to repro, but don't get any such popup after selecting a branch to delete. The branch is instantly deleted. I'm on Mac OS X 10.11.16, vscode version 1.21.1


<!-- 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. --I work on an extension that has a custom tree view. Some of the items don't have meaningful extra information to show in a tooltip but setting the field in the to or results in the label being used for the tooltip which looks odd as it provides no additional information. We would like it if there was some way to disable tooltips for a tree item. It might be hard to used for that now as that would be a breaking change but perhaps there is some other approach that would be possible. I would note that if the tooltip is required for accessibility in some way then I'm happy that it stays but I think that angle is covered by the aria-label attribute and the tooltip is something else entirely. I have searched and I can't see reference to this from an extension API point of view in the current issues. I am not well versed in the VS Code code base but I believe the issue comes from these lines:
Here is an example screenshot of the issue: ! The supported features are programmatically detected and we don't have a reliable way of providing any additional useful information for the tooltip so being able to avoid it entirely would be desirable.
I think that allowing extensions to have no tooltip is a good feature request. Form an API perspective, do you think setting to empty string is an ok way to accomplish this? I don't think we should use since that would be a big disruption to the current behavior (where the is used).
Yeah, that makes sense to me.
To verify, modify an extension that provides a tree view so that the of it's tree items is an empty string. Verify that no hover is shown on those tree items. You can use the sample for this:


contribute command that uses enablement assign a keybinding, via :bug: enablement isn't honoured
When users configure keybindings we allow them to change preconditions as well, e.g rename requires an editable document so I don't plan to have a different strategy for contributed commands
I don't see the nice "Command 'Hello World' is not enabled in the current context." info toast when I try the keybinding though. I only see that message when I try to run it from the command palette. The command correctly doesn't run when not enabled though.
Yeah, that's the design. Keybindings don't show messages


Type: <bBug</bstep 1 - Run any command or project whose lines does'nt fit in single line step 2 - Your terminal can be full sized or small size does'nt matter step 3- Presss Alt + z to wrap line in terminal Step 4 - Resize your terminal window Example - If initially terminal window height is 100px from the bottom then word wrap using Alt + z and after that increase or discrease the size of terminal window. You will find that content is still showing in 100px of height VS Code version: Code 1.91.0 (, 2024-07-01T18:52:41.959Z) OS version: Linux x64 5.15.0-113-generic Modes: <!-- generated by issue reporter --
!
Thanks for fixing the issue One more questions Is there any way to off wrap word in terminal parmanent. I have to use Alt + z each time when I run my project
there is not
Can you make it happen like Eclipse Please
i haven't seen it in eclipse but I'm guessing they're using the old console api on windows which isn't really compatible with the pty based system that we use.
Works, but I never see a horizontal scrollbar with word wrap disabled, should I expect to? I see it in the screenshot above.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.47.2 (user setup) OS Version: Windows_NT x64 10.0. Steps to Reproduce: a file named in any directory. the file with VS Code. file is opened with the "JSON" language mode (instead of the expected "JSON with Comments" mode). Other file names, e.g. , are also opened in "JSON" language mode. In contrast, is opened in "JSON with Comments" mode even if the file name contains suffixes, e.g. . <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
This is easily fixable, look at the relevant code: Submit a PR
Thank you. Is a local build/test warranted, or would a direct PR suffice? Asking because I don't have a local build environment right now (and setting up one would take some time)


<!-- 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. --VS Code currently associates the extension with the Make language. is another common file extension for files included by s. It's associated with Make by , i.e. files are recognized by , and there are a few dozen public . VS Code should recognize this extension automatically.
could you point me to some documentation about please?
Hi I've updated the issue description with some additional information. Notably, , which I consider to be a fairly canonical source. I've not any of the other file extensions recognized by GitHub Linguist for Make, as I've not seen them in use. Anecdotally, my employer has been using the extension internally since at least 2001.
Here are some additional examples which demonstrate inclusion of files by s:
That's good enough for me, thank you!
/verified


Type: <bBug</bipynb notebook bug In dev tools, see: VS Code version: Code - Insiders 1.70.0-insider (Universal) (, 2022-07-26T05:17:37.262Z) OS version: Darwin x64 21.5.0 Modes: <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Looks like the directory is excluded from publish: You likely want to have the notebook code go to a different directory, such as instead of the dir
Just changed that inside esbuild, didn't realize that out wasn't included. I had been having an issue with needing to run while using OSS, could that be related? I'll make a PR to adjust and


<!-- 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.70.0 (Universal) OS Version: Darwin x64 19.6.0 Steps to Reproduce: to delete a file with nested files When you right click and hit "delete", vscode does nothing and the file and its nested files remain. You must open the parent and delete each nested file and then you are able to delete the parent file.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.70.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Also, I think it would be a good idea for an option to rename all nested files when the parent is renamed.
based on the setting description for file nesting, I expected a file I created in a folder to be nested under the that is in that same folder. Is that the wrong expectation here?
That is correct. I'm seeing that here <img width="457" alt="image" src="https://user-"


From : Error: TreeError [FileExplorer] Data tree node not found: ExplorerItem:
Any idea here because there's no explorer stack involved this might be a tree issue
You can try this. Enable fileNesting and select a file with nesting, control+c, the error would appear. The chosen file should be in preview.
third line in the stack frame:
This also happens when you try to open a file with enter or space keys. ! Pressing delete instead of enter will display the same error. (related issue: ) Once the nested files are expanded, this error does not occur until the next window reload, perhaps because the node is to the tree.
Thanks for the repro


On Windows: clone open workspace look at the workspace settings: all files are associated with schema . Note that this is a relative path to the workspace file open both files and check that code completion gives back property . You can also click on the JSON language selector ( next to JSON in the status bar) to see the schema that is associated :bug: No code code completion or schema association
76 candidate PR:


! Testing
I'll try to deal with this
I'm sorry, I would like to ask a simple question. If I want to use this accessibility mode, do I need a software like NVDA to make it work? Or if I only have VS Code, can I still trigger this functionality?
Hey you can enable this with the command - a status bar indicator will appear
I used to be able to trigger , but now when I trigger it, it will show up in the lower left corner, but it won't have any function, which is a bit strange, are and the same function, I didn't find
Yes that's what I had meant. Hm, maybe a recent regression? Last time I tried this, it worked for me. I'll investigate tomorrow
Also, re the question of do you need to use a screen reader, it depends on what you're trying to do/ test. With that mode on, certain audio cues will (should) be enabled by default for example.
I have used this function once before, and it is true that the audio will play after it is turned on, but this time there is no response, I will check again to see if it is a problem with my settings
you can test this - and it's working for me with: screen reader mode status bar item appears in the terminal hear sound screen reader mode status bar item disappears no sound
Thanks! This work for me
I started trying to solve the problem


Description Currently, when editing a file, the command <kbdctrl</kbd+<kbdshift</kbd+<kbda</kbd(toggle block comment) generates the following comment placeholder . I wonder if it might be also wise to include this as an auto-closing pair so that when users attempt to write the closing is automatically like other languages (ex: Typescript).
This issue is caused by an extension, please file it with the repository (or contact) the extension has linked in its overview in VS Code or the for VS Code. See also our guidelines. Happy Coding!
I'm not quite sure as to who or where the owner is for the extension. Looking at the I noticed multiple past updates to support additional features. Isn't the proposed feature request present in the issue similar to those past updates?
Oh, you are right. This part is us, not the extension. Sorry for the confusion...
Looks like a good change to me. Feel free to make a pull request.
Not able to reproduce ctrl+shift+a not having any effect.
I assume you are editing a file, but sorry the keybinding I mentioned is for Linux, on macOS for example the keybinding is . The easiest way to test is to simply run the command from the menu 🡒 :)
Got it, in windows it is Shift+Alt+A.
I forgot to mention I won't be able to submit a PR myself due to my company policy. If anyone would like to take on the issue, please feel free to do so :)
In that case, I am more than happy to make a pull request for this. Thanks for the information. I will submit one soon.
thank you!


VSCode Version: 1.36.0 OS Version: Windows 10 / Mac OS Steps to Reproduce: any c++ code inside of a .cpp/h/hpp etc file. "/" at the begging of of a line that has already been written "/" gets automatically afterwards, but before the code, so nothing actually gets commented out Simple example, where "|" denotes the cursor position: "/*" shouldn't auto-add the end symbol of the comment block by default, should be setting controlled, and should be able to recognize when it's been entered at the start of a line. Does this issue occur when all extensions are disabled?: Yes Originally reported here: They forwarded me to you folks, so I'm assuming this was to the "C/C++ Language Basics" built-in extension without a setting to control it. Please for the love of god fix this. It's super annoying.
Found a temporary workaround: to: (User Folder)AppDataLocalProgramsMicrosoft VS Coderesourcesappextensions "cpp" to (User Folder).vscodeextensions it something like "cpp.language-basics-custom" to avoid any later confusion. "language-" & comment out (or remove) this line: the trailing comma in the previous line (might not be necessary) VS Code. The custom version should take precedence over the built-in version. Comment blocks will no longer auto-close.
Also, of note: Neither javascript nor typescript contains that in their language- files, but uses the same style of block comments. I think it's safe to say it should just be removed from the cpp language-
It looks like C# and json use the as an auto closing pair, but java, javascript, php, and typescript use the . For C languages we whould use since it is more consistent.
Fix will be available in next insiders if you want it ASAP. It installs side by side with stable, so you can have both:
the C/C++ extension already registers a custom , including for . Please don't add autoClosingPairs for comments since there is no way to disable them in vscode. There are only settings for and . I seem to recall these all being controlled by a single setting at some point, but now there are only 2 out of 3 available.


Visual Studio Code lacks support for automatic comment-block ending in C and C++. If you were to start a comment-block with , an automatic will not be as it would be in the traditional Visual Studio. When I type , it should automatically be turned into and the text cursor should be between the two ``. It isn't that big of a deal but it would be really nice to have this feature in Visual Studio Code.
Ugh. I currently have the exact OPPOSITE problem: I want to DISABLE this feature. This is happening for me and I can't figure out how to turn it OFF. There are a large number of developers who just don't ever want their text editor to ever, under any circumstances, insert a character that did not correspond exactly 1:1 to a specific keystroke. I push "A", I get "A". And so on. "Surprises" break my flow worse than any other kind of interruption. Obviously, there are a lot of developers in the other camp. But the upshot is that the fact that both camps exist, and both camps are large, means that when features like this exist, it needs to be possible to disable them. I have encouraged many projects for years to consider adding a "dumb as a brick" switch that will just globally disable all of these. In the absence of a master switch, we at least need configuration switches that can shut these things off-- preferably arranged hierarchically, so that we can shut off entire branches. But the absolute lowest rung on the ladder is that individual switches must exist to disable these things.
Let's track in


Issue Type: <bBug</bmultiple brackets "" Expected: All cursors at brackets become selections starting where the original cursor was and and ending at its matching bracket. Actual: Only the first cursor becomes a selection, the rest dissapear. VS Code version: Code 1.21.0 (, 2018-03-07T10:54:22.798Z) OS version: Darwin x64 17.3.0 </detailsReproduces without extensions <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.531 --- <!-- score: 0.527 --- <!-- score: 0.498 --- <!-- score: 0.498 --<!-- potentialduplicatescomment --


Issue Type: <bBug</bThe preview in the minimap slider is wrong when: The minimap is NOT overflown (doesn't need to scroll internally when the editor is scrolled) is (default value) When is set to , the preview is shown as expected. Reproducible without extensions: Yes ! The slider preview ends at the beginning of the block comment, while it should contain a portion of it. VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: Windows_NT x64 10.0. <details<summaryExtensions (15)</summaryExtensionVersion ------ gitstash2.1.0 bracket-pair-colorizer-20.0.28 vscode-eslint1.8.2 todo-tree0.0.129 svg0.1.4 tag-rename0.2.1 vscode-simple-icons1.11.4 dotenv1.0.1 vscode-docker0.6.1 vscode-javascript-booster0.10.2 code-settings-sync3.2.9 markdown-preview-enhanced0.3.13 code-spell-checker1.7.0 language-pde1.3.0 markdown-all-in-one2.2.0 (1 theme extensions excluded) </details<!-- generated by issue reporter --
A new observation: It's not about the state of the window (maximized/restored), it's about weather the minimap is overflown or not (needs to scroll internally when the editor is scrolled). I edited the issue accordingly.
Another observation: has no effect on the issue either. The problem is that the minimap height is not calculated correctly when is , the extra lines that this setting adds are not accordingly to the minimap height, only when it's NOT overflown (i.e. when ).


In Markdown preview, inline formats in single backticks (`) seems small sized in heading. Headings of different sizes have this problem in common. !
fyi
Yes, this collides with our font-size rule for the code block which is not ideal. I am happy to accept PRs for making markdown CSS better. The CSS is defined in
Still happens with our new markdown extension: !


Testing <img width="348" alt="image" src="https://user-"
Extension fails to launch child_process during initialization Will check if the issue is isolated to this extension with a minimal example using module
Was able to isolate the issue, firstly as pointed above the extension makes an attempt to launch a child process via the helper which basically emulates options and passes them eventually into Since variant relies on when node executable path is not provided, this will default to use the Electron executable that is used to create the extension host. Now there are two problems with this usage, (i) execa module will not add the env variable, so the exectuable cannot be launched as intended. (ii) We also disable calling Electron executable as unless flag is provided in the call site. For the (ii) we automatically add the flag at both and callsites internally in the runtime, so this should not be a concern for the extension authors. As for (i), if the extension author used the vanilla then the env variable would be set internally by the runtime. But since the call is done via a 3rd party module, I think it is upto the extension authors to ensure the env variable is provided if they rely on the Electron executable. I feel like there is no action required from runtime/VSCode core for this issue, but we should loop in the extension author to fix this on their end. Thoughts ?
So what exactly is different in the utility process vs. child process today? I did not fully understand.
When extension host is created via , internally the runtime would launch the process with env variable set and we never remove this variable explicitly in the extension host after launch (i-e) , this would indirectly help above scenarios since the env gets inherited by extensions. This is not the case with utility process since there is no runtime induced env variable, the extensions have to explicitly add them if they rely on the electron executable. I would say the previous behavior was a hidden bug and is visible now with the utility process api.
Oh yeah understood! I think I somewhat agree that we need to just document this to extension authors.
btw, since this is a public issue, I've shared it with the dendron extension author directly to track
hey, dendron author here. thanks for looping us in on this. so as I understand, we have two options: either use vanilla or set when using the module.


is this an accurate understanding?
yup that is correct. To clarify, only when ends up using on the desktop extension host.
Got it. What's the timeline for us patching this? Is this already live in insider?
The change is not default in insiders yet, it is currently behind an environment variable , can give more context on the timeline.
after discussing with the team, we have decided to push a workaround in core to avoid breaking the extension community with the new process type for extension host. You don't need to make the adjustments outlined in


see gif have the debug hover above the cursor expand some objects the hover grows over the current line/cursor !
Yeah, this is a consequence of the change to not make it jump. Since in this scenario it does not have enough space above to grow, it can only grow over the line and below. Alternative would be to show it down, which would cause a jump. Or to limit the size, that it does not grow over the current line. That I think makes sense. However will not tackle during endgame.
How about not growing and use the scrollbar sooner? Just measure the max size above the cursor and don't go over that
I think this makes sense. My current max height is 70% of the editor height. Idealy as you suggest the max height should be the size above the cursor if I am placed above, or max size below the cursor if I am placed below. However I am not aware of editor API that gives me height above or below the cursor. Are you already using something like this for the suggest?
I am using and some math:


<!-- 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.85.2 OS Version: Windows 11 Enterprise (Windows_NT x64 10.0..3007) Description During an accessibility test, we found the contrast ratio between the highlight color of the focused button in "More Actions..." in notification popup and its background is not high enough under "Default Dark Modern" theme. Highlight Color: Background Color: Contrast Ratio: 1.346:1 Required Contrast Ratio: 3:1 !
I think this refers to the background color of the gear icon in the toolbar of a notification relative to the background color of the notification.
The bug reported on my side particularly specified the "Manage Extension" button highlight color and the background color of that actions popup under settings icon in the notification.
Looks like it's about the blue on black bg, in that case this applies to all the web menus in VS Code.
yes, it's about the blue highlight and black background.
A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #Win32; #Visual Studio Code Client; #BM-VisualStudioCodeClient-Win32-Aug2023; #WCAG1.4.11; #Non-text Contrast;
Hi, is there any update on the plan of fixing this accessibility bug?
putting this on the March plan.
Hi, may I check if the fix is included in v1.88.0?
Hi, I have checked v1.88.0 but it seems the active color is still not the one you changed to in your PR. Did I miss something?


Verified with the Dark Modern theme, but do we also have to fix this with the Dark+ or Dark (Visual Studio) themes?
Thanks, I think it's fine we only fix it in default dark theme for now. The test team doesn't require that in other themes so far.


<!-- 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.73.1 OS Version: macOS Ventura 13.0.1 Steps to Reproduce: VoiceOver a command that uses a Quick Pick List where the items have a as well as a title or description (demoed with Azure Extension "Create Resource") list a command that uses a Quick Pick List where the items have no detail, e.g. "Select Display Language" or even command palette reader will read the title of the new item with the detail of the item in the previously displayed quick pick list https://user- Same bug with the command palette reading details for items: https://user-
This issue is caused by the item still containing the values from the previous list.
Verification steps: the issue steps are good. If you want a non-Azure extension command that shows a quick pick with details, use


Issue Type: <bBug</bCompared to input boxes in other viewlets, the search box in the extensions viewlets looks slightly different with a little padding of a different color inside the box. VS Code version: Code - Insiders 1.27.0-insider (, 2018-08-15T05:19:24.200Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<!-- generated by issue reporter --
This appears to be because the sets the background color to a transparent color (), if that is changed to , the look is the same but without the border. This seems like incorrect behavior of the renderer, as the type of color shouldn't affect what gets colored.
Actually, looks like the transparency is showing up differently on the different backgrounds. If you increase the alpha, it starts to look like this: ! I'll look in to making the transparency affect both equally


<!-- 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.81.1 OS Version: win10 Steps to Reproduce: new version vscode after 1.78.2 remote connection before vscode 1.78.2 in win 10 right click win10 taskbar show remote connect like ! but recently I update my vscode to 1.81.1, the information for remote node disapear. ! This bug is quite inconvenience when I have many projects with the same name in different remote nodes.
Same Issue Here
Do you own this part of the label service Aware of any changes?


Not much padding between it and the word: ! !
Passing to as this is a file icon but in the icon we actually have it designed at 14px scale (and offset to avoid pixelation) and i know the file icons use different scaling styles <img width="568" alt="CleanShot 2022-06-17 at 12 33 56 src="https://user-"
The trust editor uses a product icon (codicon) as editor icon here: I think this needs to be adjusted there.


I've had a couple of people report debug adapter crashes recently. One of them I'm unable to reproduce which means I need to get more information from the user. Currently, when a debug adapter crashes, the error information that appears in the console is very vague: ! The actual exception that was thrown is not shown. Since I can't repro this, the only ways I can think of to debug are: try/catch around all debugger methods that handles errors and passes them back nicely (and remember to do this for all future methods) the user to run my project from source and debug the debug adapter to catch the error (whilst not the hardest thing in the world, it's a bit involved for an end user) Is it possible to get better information from the error back into the console without having a debugger attached to debug adapter?
I don't know if the text "ERR" in the console was actually supposed to be my error; but it isn't. My error was "AAAAAARGH".
this request makes sense. Not sure though if I am getting your error when your process crashes. Can you be so kind and set a breakpoint make your server crash and check if your message is coming through as a or as something else. Thanks
Do you mean the text? I also don't get that now when trying to repro, only the "terminated unexpectedly" message. If you still want me to try that breakpoint, can you explain how to add a breakpoint there. I did try breaking in my adapter and navigating the callstack (that file wasn't in there anywhere) and also checking the filenames of the files that were (they showed ).
I mean let's try to see if your error "AAAAARGH" surfaces on our side. You should be able to just run regular vscode, F1 open developer tools, wait some time and put a breakpoint by openning a . Also try to put a breakpoint and check if the error stream spits up something.
The breakpoint is not hit, which is perfectly normal since the exception occurs before the socket connection is created. You should be able to reproduce by adding require('unknown_module') to the top of any debugger extension .js file
Ok, I got breakpoints in both and . First wasn't called and the second was called but is and is . So seems like the message isn't there.


For testing, all I've done is put inside my debug adapter. Though now I think about it; the error isn't occurring in code that's been executed directly by Code - it's during the response from my debugger. In my debug adapter I spawn a process and I add a handler for . When something comes over and my callback runs, that's where the crash is occurring. I don't know if this changes things (for example, I don't know if this is on another thread?).
That one (in ) didn't seem to be hit either.
Actually, I think I can repro this really easily by just putting in the constructor of the ? Also gets .
This issue has the needs-more-info tag though I think it's easily reproducible with my last comment. Let me know if that's not the case!
I have removed tha tag and plan to look into this issue this week. Thanks
Investigated and the issue here is that I am not getting any exception data from the spawned process. I simply get the code while all the other error chanels are blank. I am not sure what would be the proper solution here. Suggestions are very welcome. Also are all your debug adapters launched using node? If yes then it might be that our  launch is somehow eating up the error if it happens on startup. If this also happens for adapters which are not realying on node to be launched then is not to blame.
please try to disable the launch for node () and see whether this makes a difference. DAs should work independent from . But make sure that the node version used is roughly the same as Electron's version (i.e. 7.9.0).
Yes, using stdfork is the cause here. If I do not use it, I nicely get the error popping up in the extensions output channel. My weekend is starting if someone is feeling smart code review and let me know if you find something fishy about stderr not being wired through.
Then you might want to involve/assign
I am going on a vacation tomorrow evening, and this is like this since forever so pushing to April to investigate with Alex what is going on behind the curatans here.


Because both colors are blue they become hard to read and fail the color contrast ratio. Would expect for the highlighted text in these selected states to become white. Outline Breadcrumb cc
can you also attach the look for quick open after this change? and would this change be for the light theme only or all themes?
I can't find an example that uses selection for quick open, do you know of one? And this change would be the new default for the breadcrumb/outline view, so it would affect all themes that use the "light theme" defaults in those two views. It's currently broken and was hard to see in our previous color as well: !
yeah, none of the pickers use selection color, I was more referring to how quick open would look like if you change highlight color to white. My understanding is that this would have an impact pretty much everywhere where highlighting is being used (independent from the tree or not)
To clarify: this would affect all light themes, even the ones in the market place? or only our light theme
sorry if I wasn't clear, my intention is to only change the highlight color when it's on a selection row. So I'm not intending to change the default highlight color. In the example below, the highlight color remains the same except when it's selected: ! I still need to investigate how to do this, but my suspicion is that we already make the text lighter on a selected row, so I'd explore doing something like while it's selected. yes, this would affect all light themes.
but there is only , we do not distinguish the highlight color based on the type of selection currently. that sounds like it could break many themes because the change from our current blue to white is quite a different color. if this was an issue for any of the themes in the marketplace, they would have fixed this already I suppose.
me do some investigation to figure this one out.
I think the point is the we don't have (and want) a highlighted-and-selected-foregournd-color but that the selection color always wins.
The highlight color on the dark theme also fails the color contrast ratio (3.2:1): !


<!-- 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.58.0-insider (user setup) Commit: Date: 2021-07-01T09:30:57.217Z Electron: 12.0.13 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: error I think only occurs using Workspaces. A single project, the terminals seem to work fine. However, with multiple projects, the environment gets confused. Terminal (ctrl+shift+) Terminal I get this error message: 'The termial process failed to launch: Starting directory (cwd) "homeusernamemyproject"'. The first terminal works, but it's the second or subsequent terminal that creates the error. This is using the VSCode for Windows using WSL Remote. This error has now existed for at least a week in the Insiders edition. I am surprised this has not already been brought up. I think the error is indicating that its confusing a windows path for a linux path. Because this is using WSL-Remote, the path should be using forward slashes not backslashes for windows. This happens when "terminal.integrated.splitCwd" is inherited or initial. The workaround is to set this to workspaceRoot, then it works. However, it's annoying not to have inherited or initial working. Also, nowhere in my settings is "cwd" assigned anywhere.


Also there is , but I suspect the issue on MacOS is different. Jae
The bottom line: Only while using Workspaces, the first or default terminal is properly run in WSL2. However, any subsequent new terminals are being recognized as a Windows environment, not Linux. Somehow the combination of Workspace+WSL is messing up the terminal environment.
I just discovered there is a command called "Create new Integrated terminal (In Active Workspace)"; where as the default "New Terminal" calls "Create new Integrated terminal". This is another possible workaround. However, you have to make sure the active file is where you want the new terminal to be created. You lose the ability to select which folder to create the new terminal in, unfortunately.
Can repro: ! multi-root workspace in WSL +shift+ +shift+5
Ah this is happening because we're getting a instead of a here:
I'm also getting this issue when using inherited for workspaces and remote ssh from a windows to a linux host. If I reload the window I am able to split the terminal for terminals that were created before the reload. Version: 1.58.2 (system setup) Commit: Date: 2021-07-14T22:10:15.214Z Electron: 12.0.13 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Windows_NT x64 10.0.
Same here.
As a workaround for this issue in version 1.58, I was using this setting: But now in version 1.59.0, the issue happens with any values .
Awesome! Just got the fix in insiders! Thank you!
Verified fixed in


We want to discourage extension authors from using activation. We should consider adding a diagnostic warning similar to the one we have for implicit events.
Is it not enough that provides the same prompt in terminal when packaging/publishing an extension?
at that stage in the development lifecycle, authors are more likely to just ignore the warning from vsce. Additionally, they might be publishing in CI and might not see it there either.
verification: in an extension, put in activation events see this: !


This is to track all the issues surrounding the terminal switcher for the August iteration. [x] move keyboard focus [x] add create new terminal option [x] add kill terminal actionbar item to entries and [x] fix tab focus for action items [x] fix focus on arrow keys [x] fix spacing between actionbar icons


Similar to GitHub style or Keyboard Shortcuts GUI: <kbdCtrl</kbd


Type: <bBug</bCC (alt+F9) does not stop at the last comment. It cycles back to the first comment once it reaches the end. This is especially confusing for screen reader users because pressing alt+F9 multiple times does not always guarantee the last comment position. Please make stop at the last comment position. Of course, (alt+shift+F9) has the same issue. ! VS Code version: Code - Insiders 1.93.0-insider (, 2024-08-20T08:04:15.567Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (128)</summaryExtensionVersion ------ vscode-openapi4.28.1 zotenote1.0.1 android-dev-ext1.4.0 aiprm-lang0.0.2 Bookmarks13.5.0 openscad1.2.2 spellright3.0.136 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.6.0 external-pdf1.2.0 doxdocgen1.4.0 vscode-markdownlint0.53.0 vscode-eslint3.0.10 vscode-quick-select0.2.9 vscode-deno3.38.2 gitlens14.6.1 EditorConfig0.16.4 prettier-vscode10.1.0 figma-vscode-extension0.3.5 vscode-firefox-debug2.9.10 shell-format7.2.5 vscode-google-translate1.4.13 codespaces1.17.2 copilot1.223.1058 copilot-chat0.20. remotehub0.62.0 vscode-github-actions0.26.2 vscode-pull-request-github0.95.


cloudcode2.16.4 overleaf-workshop0.13.2 cslpreview0.2.2 path-autocomplete1.25.0 latex-workshop10.1.0 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 commitlint2.6.0 language-julia1.109.1 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 language-matlab1.2.5 zotero0.1.11 git-graph1.30.0 azure-dev0.8.3 vscode-azureappservice0.25.2 vscode-azurecontainerapps0.6.1 vscode-azurefunctions1.15.2 vscode-azureresourcegroups0.8.3 vscode-azurestaticwebapps0.12.2 vscode-azurestorage0.16.0 vscode-azurevirtualmachines0.6.5 vscode-cosmosdb0.22.0 vscode-docker1.29.2 vscode-edge-devtools2.1.5 black-formatter2024.3. debugpy2024.11. flake82023.13. isort2023.13. python2024.13. vscode-pylance2024.8.101 jupyter2024.8. jupyter-keymap1.1.2 jupyter-renderers1.0.19 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.381.0 remote-ssh0.114. remote-ssh-edit0.86.0 remote-wsl0.81.8 vscode-remote-extensionpack0.25.0 azure-account0.12.0 azure-repos0.38.0 cmake-tools1.18.44 cpptools1.21.6 cpptools-extension-pack1.3.0 js-debug-nightly2024.8.1517 powershell2024.3.2 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.12.0 vscode-speech0.10.0 vscode-speech-language-pack-en-ca0.4.0 vscode-speech-language-pack-en-gb0.4.0 vscode-speech-language-pack-ko-kr0.4.0 vsliveshare1.0.5936 windows-ai-studio0.4.0 autodocstring0.6.1 pandocciter0.10.4 publisher1.1.5 shiny1.0.0 shinyuieditor0.5.0 quarto1.114.0 r-debugger0.5.4 java1.33.0 vscode-xml0.27.1 vscode-yaml1.14.0 r2.8.4 multi-command1.6.0 AudioQ0.0.2 vscode-deepl1.1.1 abc-music0.4.0 lua3.10.5 latex-utilities0.4.14 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.7.0 vscode-gradle3.16.4 vscode-java-debug0.58.0 vscode-java-dependency0.24.0 vscode-java-pack0.29.0 vscode-java-test0.42.0 vscode-maven0.44.0 zotero-cite0.8.6 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'm wondering if we were to announce "comment 1 of 3, 2 of 3, 3 of 3" etc., that would be a sufficient workaround?
-- Adding the index number would be really helpful! However, that is a separate feature enhancement and I would prefer not to wrap once it reaches the end. At least, a simple bell sound needs to be played when it wraps.


Toggling the command center works, but the title bar height is stuck until the window is resized. I also noticed some issues where I had to click twice to open the command center once enabled. The command center input then disappears while the command center quick pick opens.
Maybe an electron update regression


Steps: begin with multi tabs showing open an editor hide tab bar actions move to the top close editor open same editor actions are not visible anymore, there is just a "..." <img width="1348" alt="image" src=""
When creating the editor actions we rely on the event to tell us when actions change. However, this event is not set when there is no active pane. In that case we should have a different event trigger the onDidChange event such as onDidChangeActiveEditor for example


<!-- 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.69.0-insider OS Version: Windows 10 Steps to Reproduce: Two split terminals + one standalone terminal, select them all then join. !
this works now, must've been fixed
I tried it in the latest insider build, still fails. Instead of selecting the terminal tabs one by one, can you try to select all, then join them? If you can reproduce, please reopen it.


(originally reported in ) Extensions that are enabled both in the show the text . This text can be confusing. asked me to open an issue Te proposal is thus to remove the text. To be honest though, I am unsure what the text even means. Look at this image: ! That extension is clearly installed locally. But I do not find it installed in on the remote. It is not there in the remote part of the Extensions sidebar. 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 5.4.0-177-generic <details<summarySystem Info</summary </details<details<summaryExtensions (40)</summaryExtensionVersion ------ yang0.1.3 jupyter-keymap1.1.2 remote-containers0.354.0 remote-ssh0.110.1 remote-ssh-edit0.86.0 remote-wsl0.88.0 vscode-remote-extensionpack0.25.0 remote-explorer0.4.3 remote-server1.5.1 vscode-openapi4.25.3 lit-html1.11.1 markdown-preview-github-styles2.0.4 vscode-fish1.0.38 ruff2024.20.0 vale-vscode0.19.0 vscode-markdownlint0.55.0 vscode-eslint2.4.4 gitlens14.9.1 prettier-vscode10.4.0 code-runner0.12.2 go0.41.4 path-autocomplete1.25.0 restructuredtext190.3.0 vscode-azureresourcegroups0.8.6 vscode-cosmosdb0.21.0 vscode-docker1.29.0 vscode-kubernetes-tools1.3.16 debugpy2024.4.0 python2024.4.1 vscode-pylance2024.4.1 azure-account0.11.6 vscode-thunder-client2.21.15 vscode-yaml1.14.0 vscode-direnv0.0.2 code-spell-checker3.0.1 vscode-stylelint1.4.0 even-better-toml0.19.2 shellcheck0.37.1 simple-rst1.5.4 vscode-proto30.5.5 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --


Type: <bBug</bIt's a UI fault in the merge editor. I have written the steps to reproduce it and also attached a screen recording for better understanding. Note: What I mean by , and in this issue ! First things first i) Need a code base which have conflicts You can clone this repository with both & branches and merge branch into to produce merge conflict. ii) Open the conflicted file in the Merge Editor And then: (Please watch the video for better understanding) in the Result tab, place the conflicted code block's widget aligned with 'Complete Merge' button in bottom-right corner in a way that the conflict actions bar is intersecting with the button (as shown in the video below). code from any stream, incoming or current doesn't matter. try to hover over same straight horizontal line as conflict actions bar towards the 'Complete Merge' button, You will notice that the cursor does not become a pointer, and you cannot even click the button. Now, If you reload the window, the issue will be fixed. However, as soon as you select any action from the actions bar, such as 'remove incoming/current', the issue will occur again. From my understanding, what is happening here is that after we select any action from the actions bar, the actions bar is overlapping the 'Complete Merge' button in the z-index's stacking context. I have tried to fix this on my local setup, and I believe I have solved the issue. If the maintainers want, I can raise a PR! VS Code version: Code 1.78.2 (, 2023-05-10T14:39:26.248Z) OS version: WindowsNT x64 10.0.


Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (26)</summaryExtensionVersion ------ vscode-tailwindcss0.9.11 vscode-eslint2.4.0 docs-markdown1.0.1 docs-preview1.0.1 es7-react-js-snippets4.4.3 auto-rename-tag0.1.10 live-sass6.0.5 githd2.3.3 vscode-text-pastry1.3.1 vscode-peacock4.2.2 vscode-selfhost-test-provider0.3.15 material-icon-theme4.28.0 vscode-react-refactor1.1.3 prisma4.15.0 vscode-thunder-client2.7.5 reactree1.0.8 LiveServer5.7.9 mongo-snippets-for-node-js1.3.12 svg-preview2.8.3 vscode-fileutils3.10.1 vscode-wakatime24.0.11 console-ninja0.0.141 vscode-import-cost3.3.0 JavaScriptSnippets1.8.0 pretty-ts-errors0.4.1 html-css-class-completion1.20.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for this detailed bug report! That would be awesome!
Hey I have raised the PR


Checking our drop (e.g. ) noticed that some layered code has sneaked in: !


Was verifying an issue Disabled settings sync Reenabled it but on the Stable service Changed profiles a few times Disabled Settings sync Got an error poupup, here is the stack from the window log
Do you have settings sync views enabled?
Turn on Settings Sync Open Synced Data views (F1 Show Synced Data) Turn off Settings Sync Above error is shown It is a regression and after looking at the root cause, it seems this can also impact other settings sync scenarios. Hence tagging this as candidate.
Can you please verify this on latest insiders?


Sometimes inlay hints are off for a short amount of time: ! It happens randomly and fixes itself quickly: ! I cannot reproduce it in isolation or in the monaco editor playground, but I see it very often when working in the VS Code repo. I think this is what happens: I type somewhere to trigger a delayed update I wait until the delay completes and the provider is asked I add new lines The provider comes back, but does not consider the edits in between The inlay hints are off I'm not sure if this is an issue of the inlay hints feature or typescripts implementation.
/duplicate of
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I still do think is buggy behavior and not a problem of delays. The initial screenshot should not be observed, regardless of delays. I'm not sure though if this is a typescript bug or inlay hint bug. And I can still reproduce it by doing random edits (took me some minutes though): !
this is still a duplicate of
Repro steps: Wait for 4 seconds, notice the inlay hint afer Press enter in line 1 Wait for 1 second Press enter in line 1 every 100 ms Notice that after 3 seconds there are invalid inline suggestions ! Validation: In the playground, click on "Compare with latest dev" Verify that there are no invalid inline suggestions after doing the steps again


<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: OS Version: Steps to Reproduce: a new file with a name starting with a space (using MacOS Finder) to rename the file by removing the space at the beginning of the file name (using the VS Code explorer). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No
Confirmed on Windows too.. Edit: problem is . trims file names, but (in this case? in all cases?) should only remove trailing spaces.


We have received feedback that inlay hints blend in with the code too much. We aren't eager to tackle that with changing font sizes because that can "harm" readability. Instead we should tweak the colors, esp for our default themes
Looking at a combination of slight color changes and some minor padding/border radius tweaks to make them look like a visibly different element and less like highlighted regular code. An example for dark+: <img width="337" alt="CleanShot 2022-07-22 at 13 45 31 src="https://user-"And for light+: <img width="280" alt="CleanShot 2022-07-22 at 13 48 40 src="https://user-"
Adding to the list to make sure we look at the current line highlight color in relation to the inlay hints: !
Did you push these changes or are these changes anywhere to be applied for August? Otherwise I'll move this to September
Moved to September—I have the draft PR but I didn't consider the compact settings yet.
ping
Made changes to all four base theme types. The most noticeable changes will be in the high contrast and light themes. The dark had decent contrast already but I tweaked it a bit. Let me know what you think.


I would expect the info box to remain open and not close and open on each keystroke: ! /cc
duplicates
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues . See also our guidelines. Happy Coding!


Issue Type: <bBug</bTesting . 1) Start creating a new folder in the explorer 2) Type 'folder1/' -once the '/' is in the input box every keystroke afterwards causes a full flicker of the information widget shown below the input box. This also happens on other platforms. VS Code version: Code - Insiders 1.21.0-insider (, 2018-02-27T06:17:53.785Z) OS version: Linux x64 4.4.0-59-generic Reproduces without extensions <!-- generated by issue reporter --
We need to debounce
Fixed by via


Issue Type: <bBug</bAssume If a FileSystemProvider extension implements more than one scheme, and if a file is opened using a scheme that is not used by the root folder(s) of the workspace, then when focus is switched to that file a call is issued on a folder resource that cannot possibly contain the file resource (because the scheme is different). In some scenarios a stat() call on a root folder can be costly, meaning it is important not to do it unnecessarily. This is not a new 1.37 issue. I will add information about how to demonstrate the issue using a variant of fsprovider-sample, and I am also willing to supply a PR to fix it. VS Code version: Code 1.37.0 (, 2019-08-08T02:33:50.993Z) OS version: Windows_NT x64 10.0.
Steps to reproduce: Use 1.38.0-insider, or a 1.37 build that contains the fix for branch at fsprovider-sample in VS Code a logpoint in the stat() method of (line 58) with the following message: that the 'Launch Extension' debug configuration. the Extension Development Host window appears, run the following commands in it: MemFS: Setup Workspace MemFS: Add Second Root MemFS: Create Files to Explorer view. on under the second root (MemFS2 - Different Scheme) the first root doubleclick on at least two files. the Debug Console of your initial VS Code instance, observe the stat messages as you switch between file tabs on the EDH, e.g. context menu of second root (MemFS2) to Remove Folder from Workspace. between tabs of the files and observe how when you click on the opened from memfs2 there is an additional stat of the first root (memfs)
Fixed via can you just let us know tomorrow once the new insiders is out if the issue is indeed fixed for you. Thank you
confirmed good in today's Insider. Thanks!
Thanks, adding verified label.


from Windows to Linux where zshell is installed, with shell integration turned on a new (zsh) terminal. Terminal remains empty a bash terminal. That works shell intergation and create a zsh terminal. That works Left side was created with shell integration on, right side was create  Let me know if there's any addition info to get.
It would be helpful if you could turn on trace logging and provide the logs


Testing on run continue on clone locally I see a browser-native dialog to open desktop I see a custom message that just reads "We tried opening Visual Studio Code - Insiders on your computer." which is confusing Unsure if we have to show the message or not but its wording needs to be improved. I mean tried and succeed in opening desktop so don't confusing me with this message. If we cannot prevent it I'd suggest to rephrase it and assume that it worked and give me a close option. Today, there this only covers the "didn't work cases" despite success https://user-
We cannot tell from the browser whether opening the protocol url succeeded, and the current wording for this dialog is based on a similar dialog from Office which also unconditionally appears in the browser: Maybe renaming 'Continue here' to 'Cancel' or 'Close' would help? Some other ideas for wording--when you launch a Zoom meeting from a browser in the desktop client, it says !
I can accept that but the wording should be positive/happy. Like: "This session now continues in VS Code Desktop. You can close this window, all your changes have been carried along. Try again if VS Code Desktop didn't start yet."


Window Sync entry is shown again Version: 1.39.0-insider (user setup) Commit: OS: Windows_NT x64 10.0.
Can confirm it happens on macOS with VSCode version 1.38.0


<!-- 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. --I am not happy with ctrl-shift-f. My steps: hit ctrl-shift-f enter the search term see several search results. want to go to the first match : There is no easy way to get to the first search result. After that I want to use up/down keys to go through the search results. The focus should not be in the source code. Screenshot of state of Step 5: ! Goal: Up to now I use the mouse and click on the first search result. If I use the mouse, I am at this state: ! After thinking about this some days, I think the best solution would be to map the ENTER to "Go to first search result". But not like F4, since F4 moves the cursor to the file, and not to the search result list. The ENTER should give the first item in the search result the focus. Then I can navigate to the matching result, and the next ENTER will bring me to the source code line. This would be great for all people who can't or don't want to use a mouse. Related:
Hi again! I'm just a bit confused on this part: For me, F4 moves to the first match, not the first file. Is this not what you're seeing? !
I think right now this might be the best you can do: is a better command to consider than what you were using. The problem is that <kbdEnter</kbdis used to re-run the search if you make any changes to the inputs. But the above keybinding does focus the first result without moving the cursor, and then <kbdEnter</kbddoes move the cursor.
thank you very much. If I add they keybinding via "Open Keyboard Shortcuts (JSON)", it works. But not always. After alt+enter I would like to use the up/down arrow keys and see the preview in the files. The strange thing: sometimes up/down shows me the places in the files (and the current entry in the result list is highlighted in blue color), and sometimes up/down does not show me the preview in the files.


We are on the right track, but not there yet. Thank you very much for your kind support.
For me, F4 moves to the first match. If I press up/down keys, the cursor moves in the file. But I would like to move up/down in the search result list and see the preview on the right side (in the window of the source code editor).
Hmm, that's interesting, I'm also seeing that the files aren't previewing after using . will look into this more.
I think I can get reproducible steps to the state where the file doesn't open when you have it highlighted in the tree view a long search it is searching, run using the up/down arrows to browse the search results, the file preview isn't triggering :bug: tree node is focused, but not selected :bug: This bug might be related to This is weird in that it only happens sometimes.


Look after is merged in Dark Modern: !
I see that it's currently using via Changing it to works, but I'm wondering what exactly broke this and why it was using in the first place?
It might have just always been out of sync which is common between the editor and simple find widget
! left : version 81 right : insiders Maybe it's related to background-color ?
! test, --vscode-panelInput-border color effect
hi , I don't know if it's some new issues.
is the find bg color meant to look like that?
Yes—changes made in to make editor widget and quick input backgrounds lighter to more easily distinguish against the editor background.
Yes, it's normal.Terminal simple find widget just not synchronized with the editor.


Issue Type: <bBug</bwhen clicking the percentage at the bottom-right of the state bar,zooming function won't work, and the aspect ratio changes to abnormal value. VS Code version: Code 1.28.1 (, 2018-10-11T18:13:53.910Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (9)</summaryExtensionVersion ------ intellij-idea-keybindings0.2.27 vscode-language-pack-zh-hans1.28.2 mssql1.4.0 java0.32.0 vscode-java-debug0.14.0 vscode-java-pack0.4.0 vscode-java-test0.10.0 vscode-maven0.11.1 markdown-all-in-one1.6.2 </details<!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.47 --<!-- potentialduplicatescomment --


I use quite a lot and have noticed that sometimes earlier queries are restored after runs. AFAICT it might be because when we run , the restores the input value from the saved view state, which can be stale
Blocked on verifying by
you can work around that issue by manually typing /clear into the input box, that issue only applies to when /clear is selected from the suggest widget


The issue is that when I resize the page to see it along with other content, I can see some text over the scroll page area. I think it wasn't supposed to work like this, that's why i'm reporting it here. ! ! .
The scrollbar is intentionally transparent. We have a color that is used only when the minimap is enabled. We could potentially use it always if set to allow defining opaque scrollbars.
Oh. Thank you for explaining :) In this case, sorry for bothering! Best, Alvaro
To verify, configure the color and that will be applied and will make the overview ruler opaque. e.g.


<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --microsoft/monaco-editor VSCode Version: Monaco 0.17.0 Browser: Crhome Steps to Reproduce: a Link Provider for monaco-editor 2 .Click on the link on the monaco editor. results with the following error: <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: N/A Solution: Looks like this is an error in Line 301: It compares the rejected promise errors to 'invalid' and 'missing', but in it rejects an Error not a string Line 61: So instead of the warning in throws an error. The code in should be:


<!-- 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. --Several shells (, , ) include vi mode keybindings. It's common for users to rebind vi escape to something like , , or . When interfacing with the shell, VS Code behaves as if it were a user typing keys, which may trigger vi escape if file names or other text input to the shell contains the escape sequence. To show the problematic behavior (assuming the shell is ): Include these lines in your In VS Code, try to run a Python file named . VS Code enters this file name into the shell, which triggers the escape sequence and causes the shell to interpret following the as vi normal mode commands. If VS Code input text to the shell with bracketed paste, this would not happen.
Not sure if this is related, but I use Spectacle to move and resize my windows. It used to work perfectly, but now, since today's update, I cannot use my shortcut to resize my VSCode instance. The shortcuts I used were control+option+command+(left/right/down/up) to move and resize, and option+command+f to toggle fullscreen(not fullscreen but resized as fullscreen). These shortcuts do nothing in VSCode and are not triggered anymore through Spectacle
Can you clarify how you're running the file? I think I understand the problem, sending text to the terminal via extension API or run active file, etc. are triggering the keybinding but wrapping them in bracketed paste would fix it. It should be safe to wrap in the bracketed paste sequences provided the mode is enabled in the terminal. that sounds like a different issue, maybe related to Electron.
Thank you, I'm gonna post this as a new issue.
I'm running the file using Run -Start Debugging, selecting 'Python File' as the debug configuration. VS Code then enters this into the shell: The file is supposed to be called but my shell sees (my escape sequence) and then stops at .


Thanks for confirming, we should be able to include the fix in 1.70 (too late for 1.69 unfortunately)
This caused a regression unfortunately so reopening The actual fix is more involved than I thought, we will need to be able to pass in a flag for whether to wrap in bracketed paste mode into the sendSequence command, internal API, extension API. An extension could wrap what it's sending in bracketed paste mode now but that won't work when the shell isn't in bracketed paste mode and the extension is not able to determine that.
We closed this issue because we in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider. If you wonder what we are up to, please see our and . Thanks for your understanding, and happy coding!


Type: <bBug</ba new profile from empty click on activity bar "Move Primary Side Bar Right" ! VS Code version: Code - Insiders 1.72.0-insider (, 2022-09-29T08:07:23.017Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes Remote OS version: Linux x64 5.15.62.1-microsoft-standard-WSL2 Remote OS version: Linux x64 5.15.62.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --


I'm using Light+. ! Could this be caused by bundling issues?
I also see this in oss. Seems like a somewhat recent regression


Testing a GH/Azure Repos repository on and file, and open the timeline view that both Git and Local History entries are shown a change to the file and save Local History entry is to the top of the list Local History entry is then moved under "Uncommitted Changes" entry
Just in case: this is not specific to web version and can be reproduced in Desktop as well.
I think this works as designed: the "Uncommitted Changes" from Git is probably always updating when you save and is more recent than the actual save event. would you agree this works as intended?
Roughly as designed, but could be smoother. Maybe if we had a way to denote at an API level that an event is "current" rather than historical. Or maybe we shouldn't even have the "uncommitted changes" entry now that we have local file history.
I agree, I don't think "uncommitted changes" should be a history entry at all. It's not a historical event. You might have uncommitted changes, but itself is not a change like everything else the timeline shows. Perhaps have a "diff" action in the Timeline title instead.
I really like the idea to not have "Uncommitted Changes" at all. It seems to originate from the git extension: Especially now that we have local history enabled, there will always be an entry for local history above the last committ, so the information is redundant. Lets do this.
not sure whether we want to remove those for remotehub extension as well:
Removed the Uncommitted Changes timeline entries for RemoteHub. I kept the Staged Changes timeline entry though, since that is a historical event and it looks like we also kept those for the git extension.
Thanks!
This change has actually caught me off guard. While I like the idea for the "Local History" in general, It's sometimes too granular and I'd like to view all the changes since the last commit. Imho, the "Uncommited Changes" entry should be shown when "local history" is disabled, or it should be configurable by settings.
Can you report a new feature request for this?