<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.74.0 (Universal) OS Version: MacOS Monterrey 12.5.1 (21G83) While using a window manager on Mac (Mosaic), I'm not able to resize / place the vscode window on the designated location on the screen. This is relatively new behavior, can confirm this was not an issue prior to release . I believe this release started this bug. vs code is the only application I know of that has this issue. I included a screen recording showing the problem. https://user- Steps to Reproduce: a window manager (mosaic), drag and drop vscode into any of the resizing blocks.
requires a purchase, is there a repro with other open source window managers ? In your demo, you seem to using native titlebar. Does the issue repro when launching with ?
Hi I was unable to reproduce it with a free alternative from the apple store (). Setting was not successful either. Normally I would approach the developer of Mosaic myself but it's only vs code that stands out here, every other app I know of (30+) work just fine. Even vs code used to work like any other app, hence this bug report. Mosaic does have a 7 day free trial if that's of any help:
I actually went for that but I just get pop-up that trial is expired on starting the application :( I have an idea what might have caused this issue in the runtime, Can you maybe help with confirming the issue by following the steps below which requires running VSCode from source.


If the above steps are difficult to attempt now, I will try to provide a custom build later this week to verify.
Thanks for the update. Will give this a try and get back to you
Hi sorry for the long wait. Happy new year by the way! I followed your steps and I can confirm that running with from source I can resize/reposition windows just fine with Mosaic.
Happy new year :) and Thanks for confirming. As part of an accessibility experiment we disabled the attribute in the which looks like the Mosaic window manager relies on.


From: Crash dump: I tried to use but the result seems weird, maybe you can help me explain how you do it? Attaching the output here:
will use symbols from which does not contain symbols for our custom Electron builds, so you will have to manually replace the symbols under with corresponding ones extracted from
should address this crash.
but then our instructions are not correct right? can we please update them to explain how to do this step by step? thanks!


Just upgraded to macos 12.3, try to ENABLE System Integrity Protection if you have disabled it before: Originally posted by in
[(42)] opendir /Users/xxx/Library/Application Support/Code/Crashpad/attachments/-107c-4a3e-8990-: No such file or directory (2) objc[2187]: Class WebSwapCGLLayer is implemented in both /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/Frameworks/libANGLE- (0x7ffa4f13a8f0) and /Applications/Visual Studio (0x115684ce0). One of the two will be used. Which one is undefined. [(171)] EXCCRASH should not contain exception 12 [(70)] exception EXCGUARD invalid in EXCCRASH [main 2022-11-01T07:19:07.195Z] CodeWindow: renderer process gone (reason: killed, code: 9)
Local OS Version: macOS 13.0 (22A380)
If the issue persists with latest stable , can you provide the crash logs following the steps at , thanks!
my version is 1.74
In your case, is SIP enabled or disabled ? Does it crash when you run with ?
! The same mistake. Are you running normally on the latest Mac 13 system
I think is not specifically a vscode problem. Im getting this for every Chromium <108 based electron app like: Logitech G-Hub I replaced the with the latest it working since but please don't do that it requires SIP disabled and this is not a solution not even a workaround. !
This "not even a workaround" works here as well. Thank you for sharing! SIP was reduced beforehand due to OCLP, so I don't know about it. But definitely not recommended reducing/disabling it! For anyone curios:
If you are using OCLP with reduced SIP you just need to add ipccontrolport_options=0 to the nvram boot-args.


Upstream issue
sudo nvram boot-args="-v csenforcementdisable=1 amfigetoutofmyway=1 keepsyms=1 intcoprocunrestricted=1 amfiunrestricttaskforpid=1 amfiallowanysignature=1 csdebug=1 ipccontrolport_options=0" exec this command,program is ok
are there steps for this?
this requires booting macOS with custom arguments specifically SIP and AMFI disabled, better for authors to verify this issue. can you help verify if this issue is addressed with our latest insiders without having to add to the boot args, thanks!
Are there any conclusions? I also have this problem
this will be fixed in our next stable release
Today it keeps failing. !
please create a new issue with crash dumps based on the steps here , thanks!


VSCode Version: 1.41.1 OS Version: Win10 1909 Steps to Reproduce: In an extension: .executeCommand('', 'telemetry'); settings open, but without a search filter <!-- Launch with to check. --No, as there is nothing to run that code
Why do you need this? You can use but I don't really want to provide a ton of commands to control all the different options in the settings UI.
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
There is a difference between User settings or Workspace settings, there is different UI and comparable methods in the API to reach them. The openWorkspaceSettings has the same signature as openSettings, but they don’t behave the same way. That’s why I think this needs to be resolved to be consistent. Martin Martin Tirion Microsoft Tel +31 (6) 1250 6153 Blog
Same issue. I just want to open the workspace settings and filter by my extension name.
Same here!
+1
+1
This is exactly what I need to programmatically open the workspace settings for my extension, allowing users to easily make changes. For anyone who needs this feature, execute openSettings with your search, then execute openWorkspaceSettings. It will switch the current settings window over to workspace settings while keeping your search string. Example vscode.commands.executeCommand('', 'telemetry' ); vscode.commands.executeCommand(''); Although this works, I still believe these commands should be consistent. I believe my use case is exactly why we need this, a per project/workspace settings window for extensions at the click of a button rather than multiple quickPicks.
Tried solution by I have the exact same use case for this as a couple of people above, providing a shortcut to my settings from an extension. The solution above didn't work, but reordering the calls worked for me: vscode.commands.executeCommand(''); vscode.commands.executeCommand('', '[search term here]'); Works for now, but I have a feeling this will break on me in the future.


Since the solution provided by already stopped working as of now (at least on my machine/env). So here's my motivated '+1' on this: I think there's a clear use case for this I also subscribe to the argument provided by -- that adding this would make the API more consistent, since then openSettings and openWorkspaceSettings would work the same way.
Thanks and for documenting this workaround I had this same need btw.


have insiders with settings sync enabled add exploration build to the sync select replace local when prompted so that exploration because just like insiders over time insiders UI state gets ruined, e.g the side bar is populated with views I have carefully hidden and rearranged
This is caused due to the dependency between two states and . Values of both states changed together from outside Change event for first state is triggered. Updating to this change can cause view container changes like (registering or deregistering) This triggers internal change events to update pinned viewlets Updating pinned viewlets is updating the stored value for second state Bug is caused at the last step -pinned viewlets state is getting overriden without refreshing its in-memory state.
How would this be verified?
<!-- 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!
Since it cannot be reproduced easily, I would ask to verify this.
the steps are as easy as described in or the description of this issue. use settings sync onboard another machine :bug: view state of the main machine get's broken: views reappear, views are reordered etcpp
Can you please verify this? I believe this depends on some pre-existing state therefore not everyone can reproduce. This state is not trivial to set up. Since you have this state already, it might be easier for you to verify.


Open a large workspace Start a text search Press esc See busy process still running is never called here:


Steps to Reproduce: in VS Code, build and run as an extension the debugged VS Code version open a text file some text Rename from the context menu Observe: the rename dialog opens, however the method on the rename provider is never called. The return before however since no other rename provider is registered the provider should still be called according to discussions with


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


Expected ! Actual !
Regressed in
The markdown preview in the chat is also broken for Dark Modern but is fixed by your change: !
And the markdown preview in the settings editor: !
I looked into this some more and have the following findings block rendering is broken for Dark Modern, Light Modern, Dark HC and Light HC What changed: we a new theme token, , adopted it in and , and updated the values for to look good with a different background color But we didn't adopt token for blocks in Markdown previews, which is why is broken for Markdown preview Some options Adopt for blocks in Markdown preview -- this amounts to a rather drastic styling change for Markdown previews ! Revert Revert the change to and drop the usage of so that Markdown preview, chat, and settings UI are in a reasonable state for all themes, which I attempted in
Also affects the Extensions Details page since it is a Markdown preview !
Verification: for Light/Dark Modern and Light/Dark HC, make sure that blocks are properly rendered in Markdown preview, settings UI and chat


Issue Type: <bBug</b(or maybe feature) HI! I have a habit that I constantly do and and we have strict rules on doing feature branches, hence creating (& removing) lots of branches per week. (did I just implicitly mentioned that I'm fast : )))) ) So it comes to me a lot that I do and I see no action, and sometimes I even don't understand that no action happened. So it happens a lot that I do code, I do branches, I do sync, I go home happy, I come back tomorrow and I find out that my commits existed only on my local system the whole time. (and, BTW, I have strict inner rules that my codes should always be synced with remote) So, firstly, what I am asking for, is to receive a toast, a popup, an error, or everything that can notify me when I do and my branch is not published yet, so I can remember to publish my branch every time its new. Secondly, I think it wouldn't be bad if VSCode automatically publishes my branch when I do . I'm not sure if this is correct considering git rules/conventions. But If that's OK with Git & VSCode team/community, well, that's OK with me :) +1 Keep up the good work :) VS Code version: Code - Insiders 1.30.0-insider (, 2018-11-30T06:19:37.226Z) OS version: WindowsNT x64 10.0.


<details<summarySystem Info</summary </details<details<summaryExtensions (20)</summaryExtensionVersion ------ swagger-viewer2.1.0 npm-intellisense1.3.0 path-intellisense1.4.2 vscode-markdownlint0.21.0 vscode-eslint1.7.0 githistory0.4.4 gitlens9.0.1 tslint1.0.40 vscode-npm-script0.3.5 prettier-vscode1.7.2 vscode-nginx-conf-hint0.1.0 Angular27.0.1 camelcasenavigation0.3.51 Angular-BeastCode7.0.18 vsliveshare0.3.1005 vscode-icons7.28.0 sass-indented1.4.9 vscode-nginx0.6.0 move-ts1.11.3 html-css-class-completion1.17.1 </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.453 --- <!-- score: 0.448 --<!-- potentialduplicatescomment --


has said that when switching between editors, it's unclear to him when a diff editor has been entered, though this is clear for sighted users. We should something like to fix this. cc
I think we announce whenever an editor gets focus. Each editor has a title that is announced. So I am not sure what is missing here? I would not like that we just add a new alert. Is the title of the diff editor not descriptive enough? Or is nothing getting announced (which would be a bug)
Good point, the file name is announced and says (Working Tree). is that sufficient to indicate this?
Closing for now, but will reopen based on your feedback
Just discussed with JooYoung and the redundant info is escaped/ignored by screen reader users, so we need to alert with this info
Should we consider a better announcement on focus of the text editor? how does this interact with the existing announcement?
Venkatesh observed that the editor title isn't being read at all, only the accessibility help hint, need to investigate that. EDIT: I explored and this works as expected.
Edit: we use already. This is working as expected. When a new file is opened, the title is read. When a user focuses the document, they hear the hint, if any, along with the "edit text, ...content". If that hint is disabled, they hear "edit text,...content"
which command do you use to switch between editor tabs? Is it ? I believe this issue is about when using that command, indicating if the focused editor is a diff editor via an .
What should I be looking for when verifying this?
Have some editor groups open, including ones with diff editors. Run the command . When a diff editor group is focused, you should hear "diff editor" announced by a screen reader. Disable that setting, and ensure you don't hear that. You should also hear it when navigating the open editors view. !
Using the Open Editors view, I don't see anything read about diff editors when I hit on a diff editor: !
Actually, I do see it when I toggle accessibility mode on


<!-- 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.0 OS Version: Ubuntu 23.04 a file with contents a file with contents the explorer, right click on file and select the explorer, right click on file and select , opening the diff editor the diff editor that , and event listeners have been but not been removed The issue is not present in VS Code 1.84.2. It seems to be caused by


Testing Disable scrolling output via command Select ! The scrolling setting is enabled, which I didn't expect !
The setting is for the initial rendering of all outputs, whereas the command will change a single cell's output. I'll see if I can clarify that in the description


Microsoft/vscode Tested using VoiceOver on MacOS Issues The add reaction button on the right side is currently read out atWhen focusing on a reaction in the context menu, it is read as just the emoji name. Github instead reads each option asThe existing reactions do not have helpful voice text. They should be read as the reaction name and number of reactionsThe add reaction button the right of existing reactions also does not have helpful voice over labels
This is now read as "Toggle Reaction" Since this uses a context menu, this is intentional. Menus don't have special aria labels. This now reads a more useful "Toggle reaction, x reactions with y" message. Same as above since this is a menu.
This seems improved but I can't get it to read the menu when I tab from the comment to the react menu button. It doesn't read anything when I use the arrow keys to move focus between menu buttons. If I expand the menu with space, then it reads the menu name. It looks like this, so I guess voiceover is stuck on the full comment context even though focus has moved. Not a voiceover expert though, is that an issue or should I be using other nav keys anyway? <img width="610" alt="image" src="https://user-"


Seeing an increase in issues (such as ) where a mapped network drive or symbolic link points to a UNC path. If you use methods such as or to resolve these paths to their UNC equivalent and use them for further file operations, our UNC allow list might prevent use of these paths until you add them to the allow list. We should discuss if there are options here to make this easier on the impacted users. The issue often goes unnoticed because we do not prompt the user on startup for these paths to add them to the allow list. Workaround Given an exception like this one: Find the resolved file path (here ) and add the hostname of the path (the value between and the first after that) to the setting (here: ). Then restart VS Code. See also:
There are some cases that are a bit difficult to handle: In my company, people always either use the raw path to access files, or map a drive to and then access files using the mapped drive name. However the real path is , which is on a server that most developers have never directly interacted with or even heard of (and there are a number of these file servers depending on the exact path). The TS server and likely many other extensions use this real path in their code, and when it does not have access the server crashes. The only way developers would be able to know the host names causing problems and add them to the allowed host list is by examining the error message of extension host which is extremely user-unfriendly. What is tricky about this is that a user may never know the real hostname until a runtime error occurred. And depending on the extensions a user installs, this may or may not be a problem at all.
Is there a way to get an older version of vscode ? The current version is unusable as long as this bug persists.
This worked for me Note: omit the leading and the at the end.
/fixedWith
Steps for verification: create a that points to a localhost UNC folder which has a Typescript project open the mapped network drive verify TypeScript smartness works and shows no errors in the TS server output logs
For some reason I wish to go back to 1.78 until there is a release which includes the fix. However I cannot find the Windows zip (needed to make VSC ) on the . Any idea where to find it?
The fix for this is in releases.


I am still getting this error while using the extension !
can you give more details, did you configure the setting accordingly?
!
Are we certain this is related to UNC paths? Whats the extension repository, maybe reach out to them as well?
I am on this issue thread from , that points me to then to this one. Repo is See that someone pointed a cucumber issue here: It's a bit confusing honestly.
I see no UNC mentioned in any of these issues, so I consider it unrelated.
, you have a example from this configuration ??


VSCode Version: 0.10.11 OS Version: OS X 10.10.5 Steps to Reproduce: a long line of text that wraps in the editor the cursor on the first line and press Cmd-Option-Down (on OS X). This creates a second cursor on the next visual line, which means it is somewhere on the same logical line depending on how the text is wrapped. When creating multiple cursors on adjacent lines, often it is to perform the same edit on multiple (logical) lines that are aligned with each other. The current behavior having the second cursor appear instead at some situation-specific place on the same logical line throws a wrench in this workflow. I can't think of a good situation where it makes sense (though I do realize it is consistent with pressing the down arrow without cmd-option) Definitions: a logical line is a line in the file on disk. A visual line is a line in the editor. A logical line may span multiple visual lines when there is wrapping.


a cell that updates the same line of output continuously :bug: extra character appended at the end and the last update doesn't seem to occur !


There is now a better Intellisense plugins for Vscode PHP: and . In it's known issues it says "There may be duplicate suggestions for functions or variables. This is because VS Code has it's own (very limited) code-completion support for PHP, and there is currently no way to turn this off." This indeed is annoying, the vscode suggestions are too broad and are just noise compared to accurate entries by crane.
It should be possible to uninstall the VS Code php extension.
fyi
I think crane still uses vscode's syntax highlighter for PHP. So if one were to remove VSCode's internal PHP extension, would it also remove the syntax highlighter? P.S. I think simple options would suffice, e.g. "", so it could be turned off.
Yes - but we can also think about splitting our extension into one part that does highlighting and bracket config and another that does completions. That would allow for more freedom.
This is now annoying the testing of proper language server in here : Quote: P.S. I think the option would be a simplest thing to implement for now.
Related
Any update on this?
I have been holding back the PHP IntelliSense release with intelligent completion for over a month now because it is useless if VS Code just spams the completion list with countless functions that do not make sense in the context. When will we get the option to disable or uninstall the built-in PHP completion?
I agree it makes sense to provide a temporary option to disable this. Just submitted a PR here:
Also just checking - at this point in time, is there anything else about the built-in support that is interfering with the experience? (hover, signature help, etc.?)
thanks for looking into this. Signature help is being implemented right now, iirc there is no built-in hover. It would be great if all of them could be disabled (everything except syntax highlighting).
I pushed the PR and changes the setting name for the code completion to "". If disabled, hover and signature help are also disabled.
I don't think the setting achieves the desired result. Setting to I no longer get completion suggestions even from PHP Intellisense extension. If have to use to trigger the completion suggestions list.
I don't think this is related, this only removes the built-in completion provider.


So something else which controls the display of suggestions list from extensions like php intellisense is broken?
Part of the January build. Add to your settings to disable all completions from the built-in PHP extension.


!
when we triage issues assigned to ourselves we usually use the milestone, anything that will be fixed in this milestone we put to june. Appart from that adding the bug label is usually good so this issue gets verified in the endgame (since it is june and bug). Assigning issues to other team members we usually leave with no label and milestone so the owner can triage and assign it. Cheers
thanks, I'll make sure and mark them appropriately next time!


<!-- 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.62.2 OS Version: Windows 8.1 Steps to Reproduce: a markdown file with the following content: Open a Preview to the side Rendering/Parsing of line 5 goes wrong Parsing of line 6 gives the: I have line 3 and 4 to determine what causes the problem, it is the literal text at the end of line 5: Any literal text (single backtick) of the content: generates the error If there is a tag on a line, any literal text (single backtick) after that is not recognized by the syntax highlighting in the editor
I have just updated the extension that has this piece of Markdown in the README. Github, Marketplace and Extension Bar all render the markdown correct.
I recommend that you disable the built-in , because it turns the Markdown inside VS Code to a flavor much different from GFM that you apparently don't want. The Markdown Math was introduced in . Besides, if you install some VS Code extensions that offer math support someday, you will need to check their documentation to disable the corresponding features. The rendering did not go wrong, to my knowledge. You just discovered the dark side of Markdown. Markdown is not a single rigorous language, but a collection of various flavors (aka "dialect", "variant") that disagree with each other. Let's take a glance at its history first, though there should already be more detailed articles on the Internet. created in 2004. It's the origin of Markdown, and unfortunately ambiguous. Soon, flavors bloomed.


Many years later, a group led by began to develop . The new spec has become the basis of many flavors in recent years. Among these derivatives, the current , , is the one that you're familiar with. Interestingly, a number of Markdown implementations adopt GFM and modify its extensions to create new flavors, for example, . I don't know the very flavor that VS Code's Markdown Math tries to follow, but it ( and . Please correct me. Now we can see that lots of Markdown flavors are technically incompatible. Thus, it's a pity that Markdown users have to configure their processors to get desired results. Here, in VS Code, the built-in ships a GFM-like environment. You can to get a more GFM-like experience as long as you're careful.
Minimal example that demonstrates the issue:
Marking as a good first issue since this should be a fairly scoped bug Here's the relevant repository where this issue should be fixed: The repo includes tests that you can use to confirm the issue is fixed and also check for regressions
I am looking to fix this by not allowing a dangling dollar symbol inside a markdown block to open or close. Do you think I'm on the right path?
I still do not regard the behavior here as a bug. Things just work this way as per the inline parsing strategy of CommonMark. From a CommonMark-compliant parser's view, we can say in a non-normative way that is equivalent to Then, given the enabled rules ( default, CommonMark HTML, pandoc-style math, and something else), it's recognized as This is correct and exactly reflects the philosophy of CommonMark. This issue ought to be marked as flavors are not compatible, . A derivative flavor can inherit the philosophy of its parent, but cannot retain the semantics. In other words, you cannot enable a math plugin and expect GFM-like rendering at the same time. You can only discuss right or wrong within the same flavor. If you want GFM-like rendering, disable the built-in Markdown Math () extension first.
But how do I write in Markdown Math a line that shows me Is there a way to Escape the
Avoid plain HTML-like pieces in Markdown. Use proper syntax whenever possible. In Markdown, HTML-like pieces (leaf block "HTML block" and inline structure "Raw HTML") are nothing, but just a kind of literal content.


CommonMark requires implementations to skip them: There are roughly 7 + 6 rules for recognizing HTML-like pieces; HTML-like pieces are captured, and then emitted as-is to the output, without further touching parser's machine state. This design is a compromise for compatibility, and causes usability and security issues, like your cases. jgm complained about the terrible fact many years ago. As for escaping, if your use case is presenting a character in textual content, you can try "backslash escape" like , and "entity and character reference" like and .
Maybe the wrong example asked, the OP was about some italic (or bold) text inside a code block, it was done with <codefoo<embar</emfoo</codeand when you use a character outside backticks and further down on the line a it goes wrong. I did not know Markdown allowed HTML entities. I have now enabled Markdown Math and replaced all characters inside with and now there is no
Excuse me? I'm confused now. So, you add these dangerous pieces to your Markdown document for formatting? Unfortunately, CommonMark Markdown is not a superset of WHATWG HTML. They actually have almost no intersection, and apply nearly opposite handling when encountering pieces that look like HTML tags. If you decide to have HTML-like things in a Markdown document, you have to be careful, and know how to lead the parser to your desired result. I thought I've made these basic facts clear. But seems no. No one understands my comments above. Before I come up with another way to explain, we can demonstrate something by this sample: If it's treated as HTML, there is one element with a comment and a text node "" inside. However, if you feed it to a CommonMark-compliant renderer, you'll get somewhat illegal HTML output:
If they are so dangerous why do they allow HTML tags in CommonMark Markdown? As soon as you use single or triple backtick all inside is treated as literal, there is AFAIK no way to make something inside italic (or bold) using Markdown syntax. I use HTML tags to get the required rendered output.
Good to know. Then, you only need to be careful when configuring Markdown renderer and authoring Markdown documents. This is for not only performance but also conformance. Avoid using inappropriate parsers, as flavors may hold dramatically different logic.


For example, , , and can give mostly different results for the same input. The Markdown flavor of GitHub is GFM. GitHub processes user content with , and then pipes the HTML output through some "filters" to add GitHub-specific features, such as sanitization, heading anchors, emoji codes, issue references, and diagrams. , VS Code's provides default + , which is a few steps away from GitHub. Basically, you just need to install extensions for emoji and task list, and disable those that don't exist on GitHub (e.g. ). Additionally, since VS Code and GitHub generate heading ID with slightly different methods, a link to heading might work on one and break on the other. It's John Gruber, , that introduced "HTML" (but not real HTML). The world has no choice but to live with it. If you ask me to judge Gruber's decision, I'd say the "HTML" in Markdown is a sign of laziness, besides, thousands of collective developer hours have been wasted due to tons of lazy and ambiguous design of the original Markdown. He should have defined generic construct syntax first, and built language structures on top of it. Probably I'm bad at teaching. But other people have good skill in communication. I recommend their articles:


<!-- 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: Version: 1.85.0 (Universal) OS Version: Darwin arm64 22.5.0 Terminal input doesn't work ( is too slow almost feels like not working ) when using in Aux Window. Steps to Reproduce: Open Aux Terminal Window In Full Screen Mode or make it Full screen afterwords.
This seems to be working in OSS Dev container.
This looks to me like a case of scheduling something on the main window which gets throttled once hidden. is the terminal using scheduler for rendering such as RAF or ?
I can reproduce and its pretty bad.
off-topic: is there a way to move panel to separate window. e.g. bottom drawer or individually like terminal, debug console ?
PR fixing it


Testing With the following settings: I saw the terminal migration notification and then clicked "Migrate", and my settings changed to: Which is defintely not what I expected to happen.
Perhaps if the shell/shellArgs match one of the detected profiles, the name of that profile can be used? So in the sample above,
I'm also kinda confused by this... here's what I had: and it turned it into:
The behavior should be: If there is an exact match (eg. just ), it should assign the existing profile as the default (). If there is not an exact match (eg. ), it should add the profile to the list and set it as the default. As for the name maybe something like would be best.
To verify, see and try other combinations
or could you pls verify this?
with the following: I don't get a notification. Is that expected?
If you've already said don't show again to the notification in that workspace, yes.
ah... I hit the which didn't show the notification until I reloaded the window.
that was another fix that went in to make sure we're not annoying
Migration doesn't seem to be working for me. Here's a gif: ! These are the same settings as here
Ah looks like if I already define then this migration doesn't work. If I delete that setting (and use instead as the default profile, the migration works.
Meaning if you set the to the name of a profile that already exists within your it doesn't work? I think that's by design.
Gotcha. The only thing I'll mention is this, with a defined does not prompt me: but this without it defined does prompt me:
I guess I would expect the migration to still happen (and a new profile be to my existing ) but maybe that's out of scope.
That seems wrong. It should happen as long as you haven't said don't show again. I'll try it.
ah... just opened dev tools:
it's working for me on Windows.
Hmm what does that mean?
Here's a repro on non-Windows without PowerShell:
any errors in dev tools with that repro? can you turn on trace logging? and search for 'migrat'
Beyond this: I don't see anything... which Output should I dig into specifically?
Run set log level -trace -open developer tools.


you should see a migration message. migrated from shell/shellArgs...
I wonder if this could be the issue
Hmmm I don't see
The fix here is probably:
Even better is marking the type as readonly too:
We might be able to catch this in the future with
I don't understand what's going wrong here though - if userValue is undefined, profiles get set to already
I'd think making it readonly would be even worse since then we can't add properties to it - such as the newly created profile
Which works fine, the failure case was when had profiles set. The there just corrects the type we're receiving from the config service
ok, should this be a candidate or moved to June?
I think it meets the candidate bar, we really want migration to be solid


Testing Before reverting metadata ! After reverting ! language remains . If I try to revert, nothing happens.
I was expecting the revert will revert the content to the version on the left side if the diff editor is opened from the timeline view, but it seems reverting to something different.
I think this can be fixed next month.
Thats a duplicate of Marking as as metadta gets reverted
Yes, the plan is to fix next month, I have a PR, but do not want to merge it just yet Its a slightly convoluted issue,


This works on web e.g. but does not work in desktop, either with a desktop git clone or with RemoteHub. The last time this happened it was due to a regression in the list of enabled codecs for our Electron builds.
Sorry for the breakage, the changes from has not been to Electron = 22 versions yet. It will be addressed in new builds this week.
Addressed in
Reopening because of


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


vscode window (given you have setting to put debug controls in the command center notice how the command center includes debug controls and then right away disappear See:


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


This is a valid bug. To repro: Open an empty window Open the explorer view. Make sure you have welcome page opened in the editor. Click on link the empty view Select a folder to open You will see above error trace in the console
No Folder Opened view () is removed when folder is opened. When removed this view is disposed. Following listener is getting invoked even after view is disposed It is because, view is being removed/disposed by listening to the same event It seems, once an event is fired all its listeners are invoked even if one of the listeners is disposed in the middle. This is causing the listener to be called even if it is disposed. Assigning to you also because it is related welcome view.
What link should I click? !
You have to make sure welcome page is opened <img width="955" alt="image" src="https://user-"


<!-- 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.71.0-insider OS Version: macOS Big Sur 11.6 Steps to Reproduce: a link in terminal containing "[" or "]" characters (ex. ) to cmd+click the link, observe that it is split on those characters. For example, links to , , , , and . In reality this is one valid path (nextjs uses "[ ]" to identify parameters in URLs) <img width="526" alt="Screen Shot 2022-09-22 at 5 12 00 PM" src="https://user-"
This works for urls: ! Not local paths: !
reported that it does (kind of) work: ! We would need to review all link detectors for this.
This happens with local links because [] are currently excluded chars:


<!-- 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 Steps to Reproduce: The documentation has a spelling mistake LINK: -Value of an environment variable on the host machine (in this case, called VARIABLENAME). Unset variables are left blank. To for example, this would set a variable to your local home folder on Linux / macOS or the user folder on Windows:
/ , can you please point me to the GitHub page that corresponds to this page.
Thanks for pointing this out. It looks like we fixed the typo () but have not yet deployed the latest changes.
You are welcome, ! I was trying to fix the issue for Hacktoberfest 2022, but I was unable to figure out in which repo this file was located. Just out of curiosity I would like to know as to where the source file for the page with the typo reside in GitHub?
Thanks for looping me in! Opened a PR in is the repo for


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


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


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


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


If user does not want the close button to be visible - vscode could make tabs more narrow to show more tabs. Tabs with changed content could get wider to show the 'dot' denoting unsaved file ! !
[ ] Verify: when the tab close button is disabled, the tabs are not leaving room for the dirty indicator until the editor is actually dirty.


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


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


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


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


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


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


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


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


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


cmd+i now cmd+backspace invokes instead of deleting the line in the text editor The ChatWidget is writing its context keys to the editor's ContextKeyService, so we need a scoped CKS at some point, either inside the ChatWidget or outside in the inline widgets
pushing a fix to use a scoped CKS but this does look like debt. Isn't a better fix to reset context keys when hiding/dispose the chat widget?
I don't think those context keys should be applied on the editor at all, they are intended to just be active inside the widget's dom tree.


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


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


!
updated Insider's and the problem remains
I think this is the same as We will need to always send the exit code and have it get evaluated on the renderer against the extracted command name to fix these problems.
sometimes reproduces on mac
you can check if this is the same issue () by running a command a few times and then when is run if it's a single entry or multiple in the output.
interesting to me that it allows repro on linux/WSL and does so inconsistently on mac. here's linux: !
K, let's try understand this a little better then, that shouldn't happen as the initial history id is 0:
Oh I figured out when it reproes on mac - if you run the same command in a different terminal, then the second and beyond ones don't have an exit code
Running the command again in the terminal where you first ran the command works every time and does not repro on mac. So mac steps are: in terminal 1 - again in terminal 1 - in terminal 2 - Linux: a terminal and run any command - placeholder decoration shown for the first one regardless of exit code
It would be nice to fix this since is the default shell used
Think I see the problem, PR incoming.


Repro: Add a long string item to a list setting, e.g., . Try an item without spaces (like a really long identifier) or with spaces. Expected: Overflow of the item is handled somehow, e.g., elision, broken to separate lines with enough spaces. Actual: The item text overflows horizontally and vertically (depending on spaces in the item), overlapping other UI elements. E.g., <img width="854" alt="Screenshot 2024-02-27 at 11 31 47" src=""<img width="815" alt="image" src=""Version: 1.86.2 Commit: User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 Embedder:


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


With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.


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


Testing In the export flow, there's the step to "Export as...". The options are "File" and "Github" <img width="615" alt="image" src="https://user-"I can make the educated guess that I'm not exporting the whole of Github from my VS Code window, but it'd be better to say "Github Gist" instead, or "Export to" instead of "Export as". I prefer the former since it's clear where it's going--otherwise people might assume it creates a repo on their account or something.
It was GitHub Gist before, after feedback I changed to GitHub. I will bring this to UX and see what other think too.
Good feedback. We will also do a user study next week so we will see how users react here. Alternative rendering: "GitHub" and then "gist" as the description a bit to the right - QuickPick should support this.
There was some confusion in the user study when exporting as GitHub. They were expecting that it will be part of a repository. So calling it GitHub Gist might be the way to go.
I think adding as description would be good
!
Lovely, tried it out. Verified.


Type: <bBug</bAlt+C or Alt+W or Alt+R Now if area with code is in focus, broken search parameter selector will appear without search panel itself. If terminal is in focus, search panel will appear. I think it is completely unneccesary to intercept alt+c globally when no search panel is opened. In my setup it leads to conflict with alt+c fzf's key binding in terminal. VS Code version: Code 1.86.2 (, 2024-02-13T19:41:37.860Z) OS version: Linux x64 6.7.6-arch1-1 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (19)</summaryExtensionVersion ------ vscode-nginx-conf0.3.2 vscode-cython0.3.10 vscode-docker1.29.0 autopep82023.8.0 debugpy2024.2.0 isort2023.10.1 python2024.2.1 vscode-pylance2024.2.2 jupyter2024.1.1 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.348.0 cmake-tools1.17.17 cpptools1.19.4 cpptools-extension-pack1.3.0 rust-analyzer0.3.1860 cmake0.0.17 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.87.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
This is feature - it influences bahavior of Add Selection To Next Find Match (<kbdCtrl</kbd+<kbdD</kbd) and Select all occurrences of current selection (<kbdCtrl</kbd+<kbdShift</kbd+<kbdL</kbd). However not sure how regexp is useful here, except it would be applied for next find.
Can you share a screen recording? I'm not sure if I understand what you're talking about.


This video shows the behavior of vscode after pressing alt+c
This video shows what I expected after pressing alt+c in terminal It is configured with following lines in .zshrc:
I can repro when the widget is visible even if my focus is in the editor
Never mind, the little toolbar in the editor is coming from the editor command , not our terminal one.


I'm always returning to projects and see the terminal messages filled with the same repeated message and would like to clean them up and not be shown as I see no value in them for myself. <img width="630" alt="CleanShot 2022-06-14 at 09 10 55 src="https://user-"<img width="622" src="https://user-"
This bugs me too, tracks only showing it once in this case by avoiding saving new parts if there is no terminal input, similar to how it only saves and restored in the first place if the terminal has been interacted with. I don't think we should be hiding the message all together as it's misleading what is part of this shell's session, command decorations would be broken for the ones that aren't part of this session (look like a bug) and it would show up like this which is a bit weird: !
Would it be possible to have an option to hide the previous session altogether and just show a new session? That would be a simple approach that would work for me personally, similar to <img width="566" alt="CleanShot 2022-06-14 at 09 40 18 src="https://user-"
you can just create a new terminal altogether by setting to false
thank you! I was searching for a setting and didn't ever find that one, kept looking for "terminal history" and "terminal clear"
the name is definitely not discoverable. I wonder if we should change it
or can we add any meta data or keywords to settings that will be picked up by search? cc
I guess?
Oh that doesn't work, do we have a way to do search keywords?
you actually want , the setting will disable process reconnect across window reloads.


Testing I started the Troubleshoot issue flow and it took a long time to create my initial profile. All I had was a status bar item which took me a while to discover (I actually thought something else went wrong). I would love to see and editor / web view better guiding me through that process by: listing the steps and adding check marks when done showing me the number of bisects still necessary giving me a final report.
<img width="258" alt="capture" src=""
We should also have a UI to always stop the process (see ) for a situation where this is useful
I now see that there is a notification for each step. This makes it better, so may be a simple thing to do is to show a notificatio with progress when the profile is created instead of a simple status bar item.
Actually, setting up the trouble shooting profile should be fast and instant.
Was not for me :-(
Following notification is shown now !


Here's what I am seeing. It looks like the accessibility help always gets the content from the editor. Here's a gif: I might be doing something wrong ! Originally posted by in


Open a new folder Trust the workspace Some of the colors in the window become wrong An editor has the wrong background color Opening the theme picker fixes it !
I originally filed because I encountered this during Settings Sync but think it's not related as I also saw this when opening files: !
Step to verify connect to settings sync install and set the Dracula theme () notice that the remote indicator is violet open a new folder that is not yet trusted the trust dialog shows up, approve verify that the remote indicator is still violet, not blue


For some projects, every commit has to have the signed off by tag. It would be very helpful if there was a workspace level setting that enabled signed off by flag when committing.
Verified !


I opened the Settings editor, hovered over a setting, and noticed a new grey line appear to the left of the settings. This issue occurs with the default light and dark themes. !
I found that when calling , if we don't pass in the style override anymore, it will be reset to default I put this fix for notebook but I wonder if it's unexpected
Thanks for figuring that out. We shouldn't update options that are not set, that a regression. I fixed that with and updated your code to back what it was. Is different, it's about the indent guides which were disabled previously by not providing any colors. With my change we complete your colors with the default colors, which IMO is the right thing to do. is a simple fix. But I think we should not use the colors for that but the already existing option. I'm working on a follow up PR, but that needs to be reviewed by who is out today.


I'm not certain if this is a bug (in the tests), but while looking at the completion ranking I noticed there are some tests cases for the fuzzy scoring annotated with "direct case match" that don't appear to match exactly - the order of the lowercase/capital is reversed: It's possible this is deliberate (because VS Code handles some swapped characters), but if so I would've thought an exact match would be included also (to ensure it ranks above the entry with the reverse characters) and the comment would be more explicit. There are other tests in the same file with the same mismatch.


This clear option can be into the exiting task property and would be called : { "label": "ExampleTask", "type": "shell", "command": "echo hello", "presentation": { "echo": true, "reveal": "always", "focus": false, "panel": "shared", "showReuseMessage": true, "clear": false } } Added to : / Controls how the task is presented in the UI. / export interface TaskPresentationOptions { …. / Controls whether the terminal is cleared before executing the task. / clear?: boolean; }
This doesn't work for me: I run it multiple times and see all the output, the terminal is never cleared.
Turns out that if the only presentation option set is clear, this doesn't work. Thanks for finding!


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --<!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.76 Steps to Reproduce: Exported a user profile using the GitHub gist link . The user navigates to the link in their browser, where they enter , and the profile opens in the explore view. At the same time, the profile badge is to the settings icon prior to importing the profile. If the user clicks "Import Profile", they are prompted to overwrite an existing profile. The user has never imported a profile prior to this experience. !
thanks for great repro steps. I can nicely reproduce. Assigning to since it seems like the Profile got applied to before hitting the import button, and hitting the import would double-import.
thanks for fixing can you try with latest Insiders and if it works fine you can add the label. Thanks!
Verified, however the profile badge gets to the Settings icon and to the Profiles list prior to importing the profile, but if you click "Import Profile" it imports as expected. Is this as expected? My assumption was that those would not show up until the Profile is imported. !
Yes. This is to indicate user that the profile is applied in preview mode.


Steps to Reproduce: a notebook with a markdown cell that has multiple headers e.g. the preview for the markdown cell - shift+enter symbols quickpick ctrl+shift+o and arrow down through the symbols list :bug: cell decoration appears for the first item but then is removed for the second


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


<!-- 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.74.2 (user setup) Commit: Date: 2022-12-20T10:29:14.590Z Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: WindowsNT x64 10.0. Sandboxed: No Steps to Reproduce: a snippet for latex that uses $TMSELECTED_TEXT. The following is an example that wraps selected text in auto-sized brackets: 'lr' over a selected text and hit TAB. The selected text is not included in the output. ! F1 + Insert Snippet, however, produces the desired output. I have only encountered the problem in latex environment, including inline math in markdown files. The issue was raised in and was fixed in 1.73 update via (I think). But came back in 1.74.
The problem is the which requires two characters to be typed... This is what happens overtyping happens, we capture the overtyped text, and "await" the next suggest session to start this doesn't happen because suggest only auto starts at word ends and a single character is no word the next character is typed, erasing the overtyped, captured value suggest starts because the 2nd character makes this a word looping you in here and wonder if you know why such a word definition was chosen and if it can be changed
I don't know why the definition specifies 2 characters.


I'm not familiar enough with latex to know if there's a reason for it. Given that no other language does this I would be fine to remove it.
+1 for changing the word definition. FYO who originally this via
I confirm that changing the word definition to 1 character is fine.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


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


<!-- 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. --Do not see similar issues here: Steps to Reproduce: interactive rebase click tab, "Copy path" file picker, paste path path file name from to . This is a file that git uses to track what is done. "Language mode" should be "Git Rebase Message" but it is not. I am using worktrees, but I don't think this is related, since has proper language detection.


Testing Insiders dated 28th March, 2017 Happens in linux and windows <img width="333" alt="screen shot 2017-03-28 at 11 42 13 am" src=""


My VScode and Cursor are broken since today's update. I can't use 'Run and debug', it doesn't open a terminal for my web app runs. Only runs work. VS Code Version: 1.93.0 OS Version: MacOS 14.6.1 (23G93)
I have the same issue when trying to run and debug my Electron application. When I change to (or remove since is the default value) I can use 'Run and debug' again. I won't get the output of the main process (only the renderer process), but at least it's working for now.
same here, this launch configuration fails to start on macos when using or . it only works if you have or remove the console configuration. VS Code Version: 1.93.1 OS Version: MacOS Sonoma 14.6.1 Demo:
Exactly the same issue with nx and nest, also for some strange reason the breakpoints are marked as attached (red) even when no process is running. Something definitely was broken in the last version, this was working fine a few days ago. Not happening on WSL2.
were there any terminal-relate changes here? The on the debug side didn't change in the last release. (Or is there a better way to do things side from a 1s timeout now that shell integration is smart?)
I'm experiencing the same issues; I can't debug anything in NodeJS/TypeScript. This started happening after I updated to MacOS Sequoia. The only way to make it work is if I set the value to the property in the . However, that's not the desired behavior. After a few hours of testing, I managed to make it work —although it's not the ideal solution— by adding the property with the value . Additionally, I with the value . In summary, I have the following configuration:
Your case probably duplicates
Nothing comes to mind around recent changes to terminal launch, apart from a different path for SI scripts. The better way to run command is to use shell integration is it's available. There's no helper function for it just yet though. do you know what that issue was we were discussing a helper?
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected.


If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Looks like it's solved. Waiting for the official release so Vscode + Cursor will be fixed.
fyi I think cursor is quite a bit behind vscode so I would not expect it to be fixed there soon
Weird, the issue was immediate on both ides a week ago.
Marking as verified due to confirmation.


The rulers and indent guides do not display well on high pixel density displays VSCode Version: Version 1.21.0 (1.21.0) OS Version: macOS Sierra 10.12.6 (16G1212) Steps to Reproduce: out editor Does this issue occur when all extensions are disabled?: Yes Example !


Testing The feature is called . But it does more than fetch, it also pulls. Fetch typically only 'downloads' commits, but does not update any branches. Maybe the proper name would be:


It doesn't matter in this case, but note that you collect all the keyListener disposables in the store of the AccessibleView class (even if you dispose them in , but the disposable is still in the disposableStore). This can lead to memory leaks. I can really recommend to compose components according to their life times. I think here the lifetime of the rendered content is owned by the caller of (the caller is supposed to call on the result). So the disposable returned by should be owned by whatever you return in . I suggest to create a DisposableStore in render, push the key listener to it once the text model resolves and return the disposable store at the end of render (also add the to the store). Also, note that the getTextModel promise can resolve after the caller called dispose. Originally posted by in


<!-- 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. --Steps to Reproduce: long variables that cause scroll them that the scrollbar gets in the way of the "relaunch terminal" button


We have a setting to disable the settings split view, but it might be useful to have a command to open the user outside of the split view for a one-off. From
I am reverting the PR, it actually doesn't work. We intercept the editor open here:
Damn, it's already a part of my workflow . What's wrong with it?
So it opens the raw outside of the split view for you? For me, it actually just acts the same as the normal open settings command and opens the settings split view.
And you don't have ?
I don't have . The command itself works for me. Does it break some other functionality? ! OS version: Windows_NT x64 10.0.
I see now. Opens a split view on linux VM. Was it ever working before on non-Windows environments?
Yeah it only works on Windows, because the == check with fspath can fail due to drive letters being different. I guess that's a separate bug... I'll revert this tomorrow.
We got a good bug out of this:
Now that the settings UI exists, I don't plan on investigating much more on the JSON editor. The split JSON UI will probably go away at some point (the JSON files themselves will always remain)
BUT I CAN'T OPEN SETTINGS FILE (WITHOUT SPLIT) NOW AT ALL BECAUSE IT'S NOT LETTING ME. Are you planning to allow users to see plain json file or to forbid it completely?
We will always allow users to see the json file. Hopefully you can still open the raw json file with .
I know about that option, it's not great.
I'll close this just because I am cleaning up issues that are specific to the JSON split editor. But to be clear, editing the JSON file will never go away :)


Add the following settings into user settings Create a Notebook (e.g. github issues notebook) Add a few cells, run (its ok if there are failures) Save and stage the notebook Make changes to at least one of the cells View differences using Notebook Diff view You'll notice that the screen flickers, This is because the heights of the cells are computed by taking the height of output & metadata sections After a few ms, these are hidden and the cells move up a few pixes.
hit this and wasn't able to test:
Should be available for testing with next Insiders, thanks1


<!-- 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.81.0-insider : : 2023-07-12T11:13:11.418Z : Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 OS Version: Mac os 12.2.1 (21D62) Steps to Reproduce: Configuration Display Language to . devtools after page auto refresh !
eg. does not exist, but exists.
thanks for working on this. The true fix for this issue actually needs to be in 's source code. I've made that fix and this should work for you now. Let me know if you still see any trouble.


<!-- 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. --Executing "Surround with snippet" from the command palette while there's no surround-able snippet, results in an empty pick list: ! Shouldn't it be like showing an information message saying there's no snippet to pick, or just not prompting the user to pick anything?
Prompt might be too annoying but quick pick itself might have a way to show a lightweight in-place message
Do you mean something like this (using )? !
Just submitted the PR. Could you please check it?


CC In , you type something in the input field and hit enter. When search result pops up, you need to press tab key tediously mutiple times to land in the search result treeview. It would be better if the search result tabindex could be adjusted so that users can quickly jump into the treeview after providing the search term (e.g., pressing from the search input field goes to the result treeview). Another way is pressing key in the search input field moves user focus to the search result treeview directly. Version: 1.78.0-insider (system setup) Commit: Date: 2023-04-04T09:32:52.453Z Electron: 22.4.3 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
The latter option is preferred for a screen reader user's better navigability.
what do you think of this suggestion?
You can press ctrl+down/up to move between the input and the tree immediately, does that help? I don't quite understand the suggestion, that the tree come before the search input in the the tab order? And with pressing enter to move focus to the tree, I think that doing multiple searches while tweaking your search query is a common workflow, and this would interrupt that, but maybe something like that could be configurable.
If you want to jump directly to the results, you could add a keybinding like The command will focus the results view.
and -- Thanks for sharing great tips! I did not even know that I could use Ctrl+Down/Up Arrows. This is working very well. -- I think this is now a "discoverability" issue. I recommend adding an aria-label or other similar techniques to remind screen reader users of these Ctrl+Down/Up key commands.
I did not know that either, so agree that this is a discoverability problem. does it make sense to you to add this hint to the ?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it.


To learn more about how we handle feature requests, please see our . Happy Coding!
Yes, I could add it as an on the search text box. Is there an example elsewhere that I can follow in terms of adding a hint?
Here's what we do for the terminal's
I have found that Ctrl+UpArrow does not work when the keyboard focus is on the last item in the search result. Ctrl+Up only works in the first search result item.
The context key is why it only works for the first item: . Removing will do what you want
-- Shouldn't it be removed by default for other users? It does not make sense it only works in the first item if we want to generalize this behavior.
do you know why was applied here?
I'm guessing that it's because users wanted a keybinding that allowed them to move to the query fields when there were no more results to see. do you happen to know why it's like this and whether we can remove the check for ?
That keybinding also does other things- on mac. I didn't want to interfere with normal list keybindings. If this would be really useful, we could add a new keybinding which doesn't have that context key? Or users can customize it that way for themselves too?
On mac when the search results are focused, does not do anything.
It works for me
Ah yeah I see it working now. hb as it seems like it is more important to be able to get back to the search box in this case than to scroll one line up?
I think I'd rather leave the typical list navigation commands alone, but if it's just behind tbh I'll defer to you. But I also remember that the ctrl+shift+F shortcut should just focus the search input too, if that helps.
Since is a pattern we use elsewhere and screen reader users already have a high cognitive load placed upon them, I think we should follow suit here behind that flag.
To verify: With , search for something, navigate in the search results, and use to return to the search input fields


An information disclosure vulnerability exists in VS Code 1.71 and earlier versions. If an attacker is able to run arbitrary scripts inside of a webview (either created by extension or by core VS Code), the attacker could bypass the local resource roots check to read arbitrary files on the user's system The fix is available starting with VS Code 1.71.1. The mitigates this attack by performing input validation on the URL pointing to the repository to be cloned. Only use webviews from extensions that follow proper security measures to block script injection Do not disable VS Code's default security measures in the built-in markdown preview The patch for this can be found at An advisory for this can be found at MSRC details for this can be found at
Hi, just curious about this: The description of the vulnerability ends mid-sentence. I see the same phrasing on the GHSA advisory as well: Can it be revised to be clearer what is the nature of the vulnerability? (And of course: Thanks for finding and fixing it, and for making these advisories! Transparency and security are appreciated!)
Updated
Should the references to 1.71 in fact be 1.72?