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


When you open a recent project from the welcome screen, the last one remains opened in a tab. VSCode Version: 1.9.1 OS Version: macOS Sierra 10.12.3 Steps to Reproduce: a new VSCode window. a recent project from the welcome screen. project is opened and the welcome screen remains opened.
The current behavior was chosen in the hope that this would help new users by staying in the same context.
I agree that the welcome screen should be closed after taking an action from it. Especially in my case, where I prefer to use the setting, having to close the otherwise empty welcome window after opening from the 'Recents' list or via FileOpen feels like a bug.
You can just not show it at all. Or do you need any of the actions on it? (I'm trying to preserve the new user experience here which relies much more on guidance.)
It's ok showing the welcome screen, but it should be closed after opening a project from there.
With we change the Welcome editor to open in preview mode, this way it will close when the next editor opens. (If preview mode is not disabled in settings.)
This could be an additional value for the setting.
Hey, I could look into this. Got any tips on where I should start ?
Great: Add an additional enum literal here: Check for that literal and the 'open folder' condition here:
Hey , I've ran into some questions which you might be able to help me with: should I name the enum literal? I can't seem to come up with the right name would I check for the 'open folder' condition?
You could use . Check for no folder being open: . You can get at the context service by adding it to the constructor of the calling class, similar to:
Hey everything seems to be working now, just one last question which is confusing me: isn't the objective of this issue to NOT show the Welcome Page when opening a new project? So why is your enum suggestion welcomePageInEmptyWorkbench? What is happening right now after my additions is: upon opening a new project, no Welcome Page is shown. Is this right?
Show it only in the empty workbench. :)
Hey Now I'm getting upon opening a new window (empty workbench). Any ideas? I did the comparison as you said for no folder being open.
Is the ?


You can debug it either in VS Code or in the Developer Tools (Help Toggle Developer Tools in the window running from source).
Upon opening a new window, it isn't undefined (verified by a console log) but then it turns undefined (verified by the same console log). Edit: and immediately after Edit2: Found it! Seems like isWelcomePageEnabled() is called twice, once in the class constructor and the other one in the onReady method. I'll make the PR in a bit


! is not very discoverable. If it would be a submenu of the context menu, it would be much easier to tweak this setting.
...
I'm for making these types of settings more discoverable, however, I do not want to add these types of settings to the contextmenu. We mainly use the context menu to change the visibility of elements/features but we don't really use it to configure them/change appearance. Also, the context menu is already pretty full and I don't want to overload it.
I'm open to other ideas to make them more discoverable. Maybe a "configure" entry in the overflow menu of the toolbar?
Yeah I like the idea of an action in the "..." menu to configure all things editor related by narrowing down a settings search in the settings editor.
verification steps: Right click on the tab bar (not on a tab) At the bottom of the context menu there is an action "Configure Tabs...", press it Settings editor should open with tabs related settings


Testing I can see that the of can be . When should I expect each of these types? I'm not sure I understand what the purpose of is.
is like the surrounding context lines that you see in the search editor. ! For example, here, lines 1791 and 1793 are context lines because they come directly before and after line 1792. I can try to explain this better in the docs, though!


Testing From the API: What is the behavior supposed to be in the following cases: The pattern contains . The pattern contains and is false. The pattern is a regex and is false. The pattern contains whitespace and is true.
If regex is not on, it just looks for literally. I believe that this actually acts as if is true (if I'm interpreting code correctly). Any time that you have regex enabled and explicitly match a newline, it will be multi-line. I should probably document this. Any characters in the regex will also match the other case. ie: should also match all characters, not just lowercase letters. It will look for the whitespace, and will look for line boundaries on either side of the search string.
I can also add extra examples for corner cases so that this is more clear.


VSCode Version: Version 1.12.2 (1.12.2) OS Version: OS X E Capitan 10.11.6 Steps to Reproduce: integrated terminal <kbdctrl+`</kbdterminal: key combination <kbdctrl + j</kbdExpected Cursor moves back a word, this the behavior that iTerm and exhibit Actual Newline is sent, essentially the same as using <kbdreturn</kbd
doesn't seem to be in the path in for me?
It's in zsh which is in mac by default? So just type in
Works for me, if you remove the backtick from your command: Not
Oh that was a typo, I am using Hmm that works in the integrated terminal for you? Using zsh without a .zshrc: Expected (in iTerm): ! <kbdctrl + j</kbdcauses the cursor to jump back to the beginning of each word. Actual (in integrated terminal): ! Should have probably left this gif linger a bit longer but at the end it says: As if you had just pressed <kbdreturn</kbd.
FYI, I just tried rebinding <kbdctrl + j</kbdwith bash's native binding commands: Again this works in iTerm and but not in the integrated terminal. Expected Terminal screen should be cleared Actual Newline is sent, essentially the same as using return
Hm I doesn't seem to be working anymore, maybe I didn't test it right or something. I looked into it a little bit, it seems to work fine in the demo which is the underlying library used. so that's why it's happening. The question is why does it work in the demo but not VS Code. It definitely gets registered within zsh inside VS Code: <img width="430" alt="screen shot 2017-05-17 at 9 50 05 pm" src=""Stepping through the code nothing stuck out as misbehaving through when run inside VS Code; they appear to both be sending 'n'. Nothing in the seems to be wrong either.
Aw I was really of hoping it was something wrong with my local configuration. Also I got the same behavior when trying it on windows + cygwin with a fresh install of vscode, <kbdctrl + j</kbdnot being distinguished from newline.
Hey just wondering if there was any progress on this?


If this is low priority could one of the contributors point me a area/file that might be causing the issue? Thanks!
I can't look into it any further right now, I'm pretty stumped on where to go from here though. It's a pretty technical problem so it might not be the easiest thing to jump in to. If you want to you can start by cloning and trying to reproduce it using the demo. If you can reproduce it you can check what's sent to the backend by loading up devtools and debugging If works fine, it would be a matter of doing a similar exercise but figuring out why VS Code behaves different by debugging similar code.
(Copied from ) This was happening because ctrl+j translates to (see ) and since we normalized to all input to the pty, this was getting lost and converted to a new line. The fix here is to never "sanitize" data that has already been processed by (ie. key strokes and paste) as knows how to handle them. We only need to process text that we send directly to the terminal such as a script the user is running or text being pasted into vim, etc.
Hmm just updated to 1.14.1 and this still isn't working for me... !
This will only be in 1.15.
Oh okay thanks.


Issue Type: <bBug</bI have noticed that every time I try to open an image on vs code, I get the error stated on the title no matter what image file type VS Code version: Code 1.39.2 (, 2019-10-15T15:33:00.827Z) OS version: Darwin x64 18.7.0 <details<summarySystem Info</summary </details<details<summaryExtensions (21)</summaryExtensionVersion ------ html-snippets0.2.1 vscode-browser-preview0.5.9 rails0.13.1 vscode-gemfile0.0.2 solargraph0.21.1 vscode-eslint1.9.1 code-runner0.9.14 vscode-rufo0.0.1 vscode-gutter-preview0.23.0 atom-keybindings3.0.6 vsliveshare1.0.1056 debugger-for-chrome4.12.0 erb0.1.1 LiveServer5.6.1 ActiveFileInStatusBar1.0.3 slim0.1.2 html-preview-vscode0.2.5 highlight-matching-tag0.9.5 simple-ruby-erb0.2.1 quokka-vscode1.0.257 erb-vscode-snippets0.0.4 </details<!-- generated by issue reporter --
Please share a screenshot of the error. Also, does this reproduce in the with all ?
I'm having the same issue on a feshly installed copy.
Found out the issue to be with the image file name. If the file name has % symbol in it, vscode does not show the image. <img width="708" alt="Screen Shot 2019-10-30 at 12 17 40 PM" src="https://user-"If, i remove the % symbol in my file name, vscode displays the image properly. Tested this both in current stable mac release and the insider build. Do let us know if you observe the same pattern.
Even i am facing the same problem and my image file name does not contain % character , resolve my issue.
My file doesn't contain the % character either and it's not working.


<!-- 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. --When folded, folding ranges are displayed in the editor as a single line with darkened background. Hovever (as of ), on the minimap, the background of this line is not darkened. This makes it harder to navigate using the minimap. !
Either this isn't working or steps are non trivial
Ok, see this working unless I have render characters enabled


I like the improved "All done. You can close this tab now."-dialog but I think it is missing a "Close Tab" option. Today, when everything works you need to hit "Cancel" but I don't have the close tab option - which is what the title suggests
what are the steps to trigger this?
Use Continue On Reopen on the Desktop from


This has been fixed for notebook diffs but is still an issue for text diffs: <img width="115" alt="image" src="https://user-"


<!-- 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. --in my project, there are several extensions in our recommended , but vscode sneaks in recommendations that are not recommended by workspace, but by vscode itself: ! in this screenshot, the WSL extension is recommended by vscode, and the YAML extension is recommended by the workspace. you have to hover over the star icon to figure out which recommendations are actually relevant for this workspace. this makes it confusing for new developers who just want to install the extensions required for the workspace, and not random additional ones that vscode suggests. as a workaround, i can add these vscode recommendations to the array, but that's annoying because i would have to update that list whenever new recommendations show up.
VS Code shows workspace recommendations on the top followed by other recommendations. If you are not seeing in this order, can you please share the steps to reproduce?
i don't know if i could, since it seems to be some sort of recommendation algorithm that shows different results based on all sorts of unknown factors. (i feel like it'd be comparable to coming up with steps to reproduce an ad i saw in a social media feed.) but i'll give it a go
it seems that the docker and wsl extensions (ones made by microsoft) always appear above workspace recommendations. steps to reproduce: to the workspace recommended extensions a to trigger the non-workspace recommendation to the extensions tab and look at the recommended extensions list ! ! even if these were showing up in the correct order (workspace recommendations first), it's still extremely confusing and misleading to the user to use the exact same icon for two completely different types of recommendations. i get that microsoft wants to get as many people using their extensions as possible, but this seems comparable to an advertisement that is not clearly labelled as one.
I found out that there is a bug in showing them in the right order. Will fix that. I am not sure how much it makes sense to show different icons for different kinds of recommendations. It might be super noisy or confusing. I believe at present we have a right balance to show an icon for recommendation and explanation on hover.


The cache is preserved throughout URI serialization. We should invalidate it when the URI crosses platform boundaries. Related to


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: head OS Version: n/a This is a bug/inconsistency in the VSC codebase, which is currently obscured because of the specific way the code is written. This wouldn't really matter, but when using a build step that generates files for dependencies, the gets evaluated down to and compilation fails. And overall, it'd be nice for the types to align in a sensible way. Steps to Reproduce: , replace with Expected: compiles fine Actual: there are a number of errors like Property 'getFirstLineText' does not exist on type 'never'. The intersection 'this & IResolvedTextFileEditorModel' was reduced to 'never' because property 'capabilities' has conflicting types in some (2339)TextFileEditorModelIWorkingCopyIResolvedTextFileEditorModelthis.isResolved() is known to be true) says capabilities should be a readonly 2. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Since this seems to concern only you with your specific setup, wanna do a PR to fix this?
I would be more than happy to, but I'm not sure what approach you'd find (in)appropriate. could type in as a number instead of an enum (since checks against it are anyways done via bitwise-and) could change in to actually be 2 instead of 0 (though it seems like you also use 0 for this field in other places like , and somehow TSC doesn't care...) could add a enum value of 0 to , since it seems like that's how you use it. I'm leaning towards approach 3. What are your thoughts?
Yeah I think we can give 3. a try in a PR.


When a test fails, it might sometimes look like this: ! By pressing in both editors, I can get it to look like this, which is more helpful for long strings: ! It might be better to enable word wrapping by default for string comparisons.
Code pointer:
Is this issue up for grabs? I would love to implement this
Yep
Could you assign me to this issue?
No, only people in the Microsoft org can be assigned issues. You can open a PR without being assigned though
I agree this is a better default. Thanks Maybe a setting to make this customizable? Not sure how many people would care.
How do I update commonEditorOptions dynamically? Replace every usage of commonEditorOptions with ?


VSCode Version: Code - Insiders 1.8.0-insider (, 2016-12-09T12:05:39.439Z) OS Version: Linux x64 4.8.0-28-generic Extensions: Steps to Reproduce: an untitled file and add content: the cursor after the shift, press down and then end, the selection should be shift, press home, the selection should be but it is because the select went to the start of the wrong line.
This used to work till yesterday... something broke. I'm pressing <kbdend</kbdafter going 3 lines above, and the cursor goes to the end of the selectionStart line. !


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- Version: 1.60.2 Commit: Date: 2021-09-22T11:59:27.195Z (1 wk ago) Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 Steps to Reproduce: a large file with a long line to be scrollable over the file (x and y axis). right. on minimap. Actual: The minimap slider does not have full width. Expected: The minimap slider is always full width.
Could you please also add a screenshot, I am not sure what you are referring to.
Please check. https://user-
can I work on this issue. if yes code pointers to investigate.
PR welcome.
thanks
what would be the expected behaviour of the minimap for a horizontal scroll?
I think we could just remove that the slider moves horizontally and let it stay put.
I think it should be:
These lines of code should work if you support scrolling horizontally for the minimap slider. At this time, we can only scroll the minimap slider vertically.
Okay, I can do that but I think it would be much better if we allow horizontal scroll in minimap. what do you think about that?


Testing I find it a little weird how there is a cloud badge on the list item and that represents 2 different items origin/main and origin/HEAD in the hover? <img width="1031" alt="Screenshot 2024-08-27 at 10 31 23 AM" src=""Should these be different icons? Should it be a single item ? Should they be the same color?


Repro: folder test task, wait to finish another terminal test task again <img width="1344" alt="Screen Shot 2022-08-07 at 11 40 14 am" src="https://user-"
In repo, ctrl+shift+b is focusing the terminal: !
Reproduces on webgl only
Guessing it's related to canvas recreation:
Yep: !


Using regex expressions am unable to find empty lines. Tried both the end of line sequence. Copying the same text in sublime simple n finds all the blank lines.
That has been an issue for me for quite a while. Never really checked again if it's already working because I started to automatically open notepad++ again whenever I needed to replace newlines.
This problem could manifest if the lines are being split before searching as opposed to doing a full text search. Interesting side note; seems to work in find in files (Ctrl+Shift+F), just not in the find dialog (Ctrl+F).
Couldn't even find empty lines with ^$ (in case they were being split without EOL).
Looked at the code, it does indeed look at each line individually. I'm created a new issue for multi-line matching


Steps to Reproduce: The cursor should go back to the exact spot where it was before the jump. Instead, it goes one sport further back...
Can you provide more details like VS Code version, OS type and version etc. Also, sample code of what you are trying to do in your extension and a screencast/gif/video ?
Likely
There is no extension involved. This is vanilla behaviour. Using version 1.4 on Ubuntu 16.04. Related to , but not the same. This is likely to be very easy to fix (jumpToDefinition event should push the current cursor position to the history).
I agree we should record the current cursor position on certain actions like "Go to definition".
Pushed a change to improve this situation for the following cases: goto definition will store the current cursor location as history entry so that when jumping back you end up in the same line number opening another editor will now also store the current cursor in the history so that going back puts you to the exact same line number too


Version 1.74.0, when I open the developer tools, it becomes a floating window, which is very unfriendly for extension developers, please add at least one option to use the old layout. !
Was caused by an upstream electron bug with WCO Believe there are plans to restore the docking feature in the near future now that the electron issue is resolved.
I found that if you toggle OFF the setting, Developer Tools docking functionality is restored AND you also still get the WCO experience (perhaps that's a separate bug?). Suggest docking at the bottom instead of to the right if there's any visual conflict due to the aforementioned electron bug.
It work, thanks!.
The setting will be removed at one point, keeping the issue open to provide and dock options when WCO is enabled.
I manged to get it to dock again with 's workaround but I noticed in the dev tool now it shows the HTML for the VS code app instead of the file I have open in the preview !
Related Stack Overflow question:
This makes working on Windows really awful for me, I think the upstream bug is fixed.
To give some context, with WCO chromium has a bug in orienting devtools window when docked to the position where the Window controls are, basically they overlap making it harder to use the close, minimize or maximize button. Chromium always pop out the devtools window in PWA for this scenario and Electron inherited this by default. The fix in does not address the aligning behavior but rather provides a workaround that calling would be respected even in the WCO scenario rather than forcing to always detach. Now, on our end to incorporate this fix we need to change all our callsite with a mode otherwise we will default to detach as seen in this logic Say we chose as default and user later reposition it to right or left then this new state will be persisted to json file under the user data directory, in non WCO cases this saved preference will be applied next time when calling or without a mode value from the application side, that is how user's preferred position is applied. But in the WCO case, this does not take effect so we need a logic on VSCode side to read the preference value and adjust the start mode with it. I didn't want to make this change yet in core hence this issue remains open, I will tackle it in debt week.


I see this as an issue when you dock the devtools to the right, but why is the ability to dock it at the bottom taken away? This seems to work just fine with WCO. But on Windows, a user is not able to reposition the devtools at all? This functionality seems to be truly gone, so a setting for Windows only would be a decent workaround and good improvement over what we have today. If we decide on a setting that forces the location, I can see to do such a change.
I am good with a setting to force the bottom position only on Windows. I will see if the runtime behavior can be improved to avoid docking the devtools to the position where the controls are present as part of this issue.
The dock options are back, though setting it to dock on the right looks funny with the WCO in the way. !
Yes that is the original bug in chromium which is not addressed.
In the new version, if the developer tools are on the right side, the close button will be blocked, which is not as good as the old version of . !
use a dock position that is not overlapping with the window controls, by default the devtools will not dock to the position were the window controls are to avoid the bug.
I know, but I always put the developer tools on the right, which is where I'm most productive.
Is it possible to revert "window.experimental.windowControlsOverlay.enabled" to a VS Code new version? In order for the developer tools to be correctly positioned on the right side, I now have to go back to VS Code version 1.81 and disable updates. !
is there an issue where we are tracking how the WCO is overlapping the devtools?
no we are not tracking it in the runtime, unless you have manually docked it to the overlapping position devtools by default would be undocked. The overlapping position in the runtime will not resolved anytime soon.


<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When we use to jump to definition, would open the definition in a new window, which is inconvenient for me. It would be better if we can choose where to open definition, like in . !
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.492 --- <!-- score: 0.467 --<!-- potentialduplicatescomment --
Nice suggestion. If you agree with this, I'll create a setting so one can choose if 'ctrl+click' always opens the peek view.
Normally, ctrl+click runs and cmd+ctrl+click opens . With this setting enabled, they both run . I don't think that's expected. Possibly change to ?
you can reopen verification-found issues
Uhm, I'll take a look on that. Thanks for your feedback!
Please file a bug and don't reopen feature requests
I created


VSCode Version:1.30.2 OS Version: Applies to Windows and OS X When the cursor flips on line numbers the SVG used has inconsistency's with the system defaults, e.g. tail is shorter Does this issue occur when all extensions are disabled?: Yes


developer tools console :bug: see a bunch of errors like this for github authentication, microsoft authentication, typescript language features, remote repositories etc


Testing Ideally there would be commands to navigate between changes. And they might deserve an action in the diff title bar. Same as the editor diff experience. !
Why is for these commands? I would expect them to be available from the command palette, since in a regular text editor Show Previous Change and Show Next Change both appear.


Testing Notice that the scroll range is below the decorations, even though they're on screen <img width="717" alt="image" src="https://user-"Meanwhile if I scroll to where they're shown, they aren't in viewport <img width="713" alt="image" src="https://user-"This was on the following gif: <img width="401" 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/No 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.2 (user setup) OS: Windows_NT x64 10.0. CPU: i5- Run command and pick a invalid uri (e.g. path doesn't exist) when having "large" (like a few hundreds) amount of recent history entries, vscode will freeze for a few seconds !
By the way, having "large" amount of recent history entries will also slow down the start up time (both vscode start up and open file time) for a few seconds as well, just tested that with out any history with a few hundreds
thanks for testing that, do you recall how you got into this state of having many entries? Just by opening folders and files that contribute to the history? If you could do me a favor: open the command palette run the command "Log Storage Database Contents" run command "Toggle Developer Tools" click on "Console" expand the first "Storage..." output that is printed there find the entry (see picture below) how many entries do you see? <img width="1005" alt="image" src="https://user-"
Total of 671 entries, most of them are temp files opened from things like MobaXterm and !
Got it, we do have a limit of 500 entries when presented, but I still have to understand the performance issue. You could actually help out by doing a performance trace yourself when this happens by starting performance tracing before invoking the time consuming action and stopping right after.


The steps are outlined here:
<!-- 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
Thanks!


When you hover over a type in a TypeScript file, the tooltip that appears has a very low max width, making it difficult to read long type signatures.
I would include a screenshot but it's not easy to take a screenshot keeping the tooltip on screen!
! Errors are quite unreadable if the width does not adapt to the font size.
! it would be nice if the tip used the available space instead of wrapping at an arbitrary point in c# too
!
! Same problem using rust's language server.
General styling control would be very helpful. Also line-height. Another approach would be to have a bottom panel that displays the full error and the tooltip displays a shortened version.
!
! When using the auto import feature it is often impossible to differentiate whats what as the import path is cut off due to the limited width of the suggestions window.
Is this something we can adjust with custom css? It makes snippet infoormation very difficult to read as well. !
Same in Python. We have to jump through hoops trying to flow doc nicely. And when it appears OK on Windows, it breaks on Mac... ! And it is inconsistent. Ex, hover is OK ! But completion list decides to wrap. What gives? ! Looks like hover respects markdown while completion item doc is plain string and gets wrapped randomly.
!
Someone say long type signatures? !
Here is a workaround by hacking the file "C:Program FilesMicrosoft VS Coderesourcesappoutvsworkbench" Simply append the code above after the original content of file, and restart VSCode. (Title bar may alert a warning message "Not Supported" and hacked changes would be overridden by updating VSCode) !
It would be nice to have some control on the width. The above does work but vscode presents the message your installation may be corrupt on restarting.
Instead of hacking the CSS directly as mentioned above, I recommend using the to just override the current CSS. That way when VSCode updates, you can just reload the custom css file that you have specified (personally, I have a project where I hold configurations for my shell, Spacemacs, etc. and this custom CSS file goes there). Until it's officially supported, hacking the CSS is likely the best route.


The suggested widths above were a bit much for me, so I settled on the following values for now:
What is preventing the devs from providing a configuration option for this? This issue has been open for almost 2 years, and it bugs me on a daily basis. Would love to see it fixed.
(since you seem like the most relevant person to ping) is anything likely to be done about this?
I would love to hear an explanation from devs too. What are the difficulties of implementing this? I imagine it's settings a dynamic max-width and adding some more lines to add it in Settings. Are there other design blockers?
Will you take a look at this? In 3 days it will be a 2 year anniversary for this simple feature request.
Assigned to and as I remember we are going to have some UX improvements for editor tooltips and so on.
maybe now is the time to take this on? current iteration tries to solve parameter hints ux and this is not that much different
! I employed CSS and put together full instructions: [Custom CSS and JS Loader extension][1] macOS VS Code: VS Code Insiders: Linux: : [1]: Restart VSCode Ignore "VSCode is corrupt" error You can choose to suppress this notice forever Run command "Reload Custom CSS and JS"
just as a disclaimer, if anyone modifies the CSS/JS of the app, it comes up at “corrupted” in diagnostic checks, and you’ll typically get pushback if you report issues and include diagnostic information. Or, at least, I received pushback when I had custom CSS/JS enabled, and wouldn’t receive help until I turned it off (even though it was harmless/not related to the issue I was having). While this is indeed an okay workaround, we should just keep making our voices heard so that this is natively supported.
100% agree. This is just a workaround. It's hard enough to read TypeScript lint as it is! :)
Currenlty using VSCode 1.30.2, followed instructions step by step, but it's not working. I don't even get the VSCode corrupt error. I'm running Windows 10 (V.1803). Edit: It was my mistake. For anyone who's having trouble, make sure to run Enable Custom CSS and JS from the command palette. Simply restarting won't work.


This issue seems to be fixed in 1.32.0-insider (1.32.0-insider) . I hope this is an intended behavior. I want to thank the developers.
This change is related to . I confirmed that the max width of is still small as mentioned above. <img width="867" alt="2019-02-22 17 06 19" src="https://user-"
Update: in , only the hovers for problems and the hovers with code blocks become to have larger width. Others have smaller width.
Hello there,your solution is great,but I want to ask how to get rid of the word at the title.As sort of OCD,sufferring from that. thx a lot!
This extension was created specifically for solving this:
This has been a long standing annoyance, with an issue that's like 2 and a half year ago. It shouldn't take much effort to have a config property that overrides the width/height of the tooltip, surely? Like, 10 mins of effort? <img width="525" alt="Screen Shot 2019-07-18 at 6 41 15 PM" src="https://user-"
if it's really 10 mins of effort, then I'm sure you can submit a PR for this? I definitely can't do this in anywhere close to 10 mins, so it would be much appreciated!
Seriously, I want instead of this: ! At least something like this (with syntax highlighting it will be even better): !
There's already been a PR. I really don't understand this. I figure most VScode devs develop VScode in VScode, are they comfortable with the current state?
fyi, it would be great if the hover could be resized
How is this issue 4 years old and such a basic thing still isn't implemented?
Is there any word on whether we could see this soon? The suggestion widget has had resizing enabled since v1.51 in October, 2020. Is this tooltip widget considerably harder to add this feature for or are there additional considerations to be made? Whether it's a click to resize, or a manual adjustment in settings, could we have an update on the status of this addition? Opening new editor tabs just to properly read code annotations for some more descriptive components on my large monitors does feel like an unnecessary extra step.


might be very related and close to what you did here:
Hi, Instead of configuring the max width as the title says, could the tooltip hover be resizable ? (Also check for more info on what was done with the suggest widget)
It's sad to see that it's still not a thing.. I would really like to adjust the height of hover description tooltips.. The big brother Visual Studio does a much better job already. Let VS Code catch up a little..
another possible view for this issue
It is 2022/11/11. Christmas is close and I made sure Santa knows what I want!
"Excuse me, it's 2023"
This one will be my favorite. Copilot suggestions and TS errors just can't be seen in this tooltip. It's time to fix it.
If this is still open and no one is looking at it, I'll take a crack at it. Feel free to assign it to me if that's alright.
Hey all, thank you for your patience. A PR has been made which is currently under work but nearing its completion. You may find it here: Once this PR is merged, you will be able to resize content hovers within Insiders.
Would you add "Reset Hover Widget Size" command in Command Palette? Like we have for suggest widget: "Reset Suggest Widget Size". It would be good if we could reset the size to the initial one.
Thank you very much. 1 Is it correct, that this would not stay across different sessions? 2 The default max width is very small, is there any consideration, of increasing that?
Will this feature also allow us to define the window size of a hover provider in a extension above the current limitations?
Hi if is is decided that the hover widget size should be configurable, there will be a command to clear the persisted sizes. This feature is still under discussion. Hi depending on the implementation, it is possible that the persisted sizes are persisted or not across different sessions. This is still under discussion. Currently the implementation is such that the maximum natural width is the same as before. Hi the current implementation does not provide this functionality. This could be addressed in a separate issue as it is related to the usage of the hover widget by extensions. The current PR that is worked on is the following:
Thanks a lot.


And do you consider increasing the default size, that is unfitting to most real world scenarios? The windows is so small, that I feel the need to increase it even on my WXGA Laptop.
Hey all, thank you for the patience. A PR has been merged in order to make the content hover resizable. The change should be visible in tomorrow's VS Code insiders version and in the next stable release which will happen in the coming two weeks. There currently is no mechanism to save the content hover - we are discussing how best to approach it. You may track the issue on persisting the hover content here: we are currently not thinking about increasing the default maximum size. However it is possible that we implement the persisting mechanism as follows: when you increase the content hover size to a specific size, this size is persisted, and it is applied as maximum default size on the next hover appearances. This potential implementation is still under discussion by our team.
Just want to say thank you you seem to have been tackling a lot of these high-level nitpicks that have been in the VSCode backlog for years, and for that I am very appreciative.
I can't find a command to clear/reset hover widget size, is this has been ?
Hi currently the command does not exist because a persisting mechanism has not been put into place as of yet. It will appear when the latter is .
Oh okay, thanks a lot


<!-- 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. --- Version: 1.46.0-insider Commit: Date: 2020-06-01T10:32:27.369Z Electron: 7.3.0 Chrome: 78.0.3904.130 12.8.1 V8: 7.8.279.23-electron.0 OS: Darwin x64 19.5.0 Steps to Reproduce: a new untitled notebook (using VS Code Python extension) you add a cell or the like, then VSC will invoke the save method on the Problems Adding cells should not invoke save (this happens when user has auto save turned on) Errors thrown in the method are ignored. VSC will assume the notebook was saved and mark it as not dirty (the dirty indicator doesn't exist on the tab anymore) I don't think VSCode should call the method for untitled notebooks. FYI - We create untitled notebooks with a scehme . If this isn't the way to indicate an untitled file (scheme), we might need some API or the like in the notebooks implememtation. /cc
Good catch, untitled file should not trigger save until users explicitly run Save, which will invoke SaveAs.
We should also improve the overall experience for creating untitled notebook documents, they can be created in two approaches: Users press cmd/ctrl+n to create an untitled file, switch to another view type (tracked in ) Users run a specific command to quickly create a notebook untitled file. command should take view type as arguments. cc we may also want to adopt this in Custom Editor world.
We now support opening a untitled file with specified editor view type through the existing new untitled file command (in master, and tomorrow's Insiders) When the command is executed, is invoked with an URI with scheme. is invoked only when users save so no auto save for untitled files as usual.


I find it strange that the entire area where the two action bars atop of notebooks are is focuseable: <img width="1007" alt="image" src=""Other action bars across the workbench aren't focuseable, only the actions themselves within.


debugging the loaded scripts view open debugging, notice exception in the console can not reproduce with Stable so it might be that my listener refactoring caused this If you pause on exception you will see that caused it.
did you have a chance to look into this? Or would you like me to investigate? I suspect this is breaking the loaded scripts view and is the root cause for
no, please investigate since this and was working before, and I haven't touched this code for two weeks.
end session events are not arriving in As a consequence the tree for the session is not properly removed.
I see something differnetly, the end sessions are arriving however when the last session end arrives view starts refreshing the tree and while that is in progress the view gets disposed which throws an exception. Looking into a fix...
I have created a PR which address this issue


VSCode Version: 1.17.2 OS Version: Win10 Steps to Reproduce: Terminal to bash <Ctrl+<Shift+<Pand type "run active file" command not work because path to the file is windows-style and <.is missing in front.
I would like to fix this.
Looks like the util was introduced in Windows


Repro Steps: install VS Code native menubar has no keyboard shortcuts Alternative Repro Steps: a keybinding the menubar does not reflect the change.
Must fix.
Reviewed, tested, merged and cherry picked to . See
since you tested this can you please add a verified label


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.82.2 OS Version: MacOS 12.0.1 Steps to Reproduce: our extension (Evidence), create a new project using the VS Code command palette which pages open automatically text file is opened automatically on the left walkthrough is opened automatically on the right This was working until one of the more recent VS Code versions I believe. text file is opened in full walkthrough is opened in full, taking over the editor pane from the text file (i.e. you can only see the walkthrough in your editor) This is the function we use to open the walkthrough: Where maps to I was under the impression that the in this function will open the walkthrough "to the side", which was happening successfully before, but is no longer working.
I had an older version of VS Code running on another computer and have confirmed it used to work in VS Code version
should this command be documented here
I did update our docs last week to include this command. Waiting for the newer changes to be published.


have an eager comments controller extension (see below) open a notebook create a new cell leak warnings are printed
This seems to be rooted at  It looks like a new is created without always disposing the old one. The looks highly suspicious. <img width="1586" alt="Screenshot 2022-10-26 at 14 09 41" src="https://user-"
Suggesting to tackle this for October because after a short while VS Code was crawling due to excessive listening
thanks for good reproduce. The comment thread equality check is wrong, it's an oversight during refactoring iirc. I pushed a fix for this memory leak. Though with it fixed, I found there are issues with "Editing" state of comment thread for cells (focus issue), will look into this next week.
Thanks


a folder in WSL and show logs the error log !
Are things broken in this case or just a bad stack trace. I'll take a look to see if I missed a module include somewhere
Just a bad stacktrace from what I see, though I didn't intentionally go test things thoroughly


It's used in , this would be easiest after that's merged.
I wish instead of explicitly checking whether proposed API is enabled in in the implementation, we could check it when checking distro for whether an extension is allowed a proposal instead.
the list of allowed extensions is not available in code - oss though on local or in CI
That's fair but do we really need to check in code - oss when developing? I would think is being tested out in the final build that's published.
not my area but being strict is good for proposals and it's good to align oss with the product in areas like this. Consider a fork of VS Code that does not have the check, extensions could use the proposals without warning which could lead to easy breakages.


Testing Add a git pre-commit hook that sleeps for 120 seconds Make a change to a file, and commit the change Switch to another VS Code window Expected behaviour: Window should be active while the source control operation running Actual behaviour: Window becomes inactive even though the source control operation is still running
Can this be adopted in SCM? Holding an activity lock is fairly easy, just call this method
these commands are being contributed by the git extension. Should be wired into the so that in case there is an on-going progress indicator the window is considered active?
Yea, I think that's reasonable, thanks for the suggestion. Will take care of it


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: 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.69 () OS Version: macOS Ventura (13.0) developer beta 2, Firefox 102.0 Steps to Reproduce: an Insiders Codespace with any repository on Settings Sync until extensions are installed many walkthroughs being opened Here is a video demonstration: Something else that I took note of (also seen in the demo video) is that: Sync is turned off for every new codespace I create the extension setup, the page reloads every time in some stage of the process (this could be expected though) I have tested this both on Brave and Firefox with various different repositories. Original issue:
The respective component owner has to opt into syncing the state.
This user is stating it only happens in codespaces and not on or I'm not sure if settings sync is treated differently here but we do sync walkthrough state
Yes indeed, In addition, this does not happen for me in 1.68.1 (stable).
Created a PR fixing this Can it be cherry-picked to the release branch before tomorrows release :pray: ? This also affects workbench theme as it flashes from default theme to the theme from settings sync which is really annoying, in 1.68 workbench starts with the theme from sync server directly cc
It seems the newly created codespace is not getting initialised with synced data because the workspace says it is not new.


Issue Type: <bBug</bnew VSCode window new Terminal terminal: terminal: in Cmd and mouse over the two listing name. Only the /tmp/Foo.h will be clickable. won't be because of the . VS Code version: Code 1.43.0 (, 2020-03-09T19:34:44.548Z) OS version: Darwin x64 19.3.0 <!-- generated by issue reporter --
/duplicate


<!-- 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?: Not sure --the only reliable way I know how to reproduce it is by creating a spelling error with Code Spell Checker. If anyone has any tips how I can try to repro this with all exts enabled, I'm happy to take that on and post a new GIF. <!-- 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.59.0 (user setup) Commit: Date: 2021-08-04T23:13:12.822Z Electron: 13.1.7 Chrome: 91.0.4472.124 14.16.0 V8: 9.1.269.36-electron.0 OS: WindowsNT x64 10.0. Steps to Reproduce: exactly one information status to be reported in the status bar and observe the tooltip tooltip will read instead of !
It shows up in plural form for all 3(errors, warnings and infos) even if only 1 of them is present. Source
If you want to implement different cases, this would involve having separate translation strings for the singular and plural, as well as a third case for the 0 value. But is it really necessary? One could easily avoid the grammatical discussion if you put like this: , , .
Seems very reasonable to me
This looks better and is understandable
Can I take on this issue( If it is not assigned to someone else )? It looks fairly simple to me. But as I'm quite new to this so I might need some guidance.
I have made the changes to correct the typos. Should I make a PR or it is already completed?


This looks like a bug in VS Code, I'm seeing a lot of weird behaviors Basically sometimes the 2nd progress is not visible (but when i scroll or add a new cell it magically appears) The output is not displayed at the end (but when i scroll or add a new cell it magically appears) Originally posted by in
Verifying the corresponding bug on jupyter and I found there's still a problem. VS code shows this: ! Jupyter shows this: !
The difference being there seems to be extra lines in the VS code output.
See


Open VS Code insiders Open the following ipynb file in vscode <details<summaryipynb</summary</detailsOpen the same notebook sideways (on the right) in a text editor Now set focus to the text editor (on the right) and hit the save key (CTRL+S) Watch how the error output in the notebook (on the left) gets duplicated !
The reproduce steps are very impressive


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


I found the easiest to reproduce is with this integration test: This correctly opens a group at the ninth column but the scrollbar is still showing as if it was not scrolled even though it is. !
Very likely an issue in et al.
Just submitted a PR.
I see the scrollbar on the right, but it also looks like there is a second shorter scrollbar behind it <img width="1042" alt="image" src="https://user-"


Logging errors from the file service I notice that the terminal seems to stat the terminal prompt multiple times: ! Notice the at the end of the file path.
When you hover a line in the terminal links are resolved, one of the link providers gets confirmation on whether it's a file or directory and gives a high confidence link (underline shows when you hover without cmd) and on macOS we treat as a valid path character. This is how it's always worked. but we could cache this stat result with a TTL (10s?) so it doesn't spam so many stat calls and will be able to return the link faster on successive hovers.


Type: <bBug</bThe keyboard focus doesn't move to the "SOURCE CONTROL GRAPH" view, it only opens it, but without actual focus (can't move using the keyboard arrows between commits or open their context menu via keybaord) VS Code version: Code 1.93.1 (, 2024-09-11T17:20:05.685Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (8)</summaryExtensionVersion ------ vscode-markdownlint0.56.0 prettier-vscode11.0.0 vscode-pull-request-github0.96.0 rainbow-csv3.12.0 vscode-docker1.29.2 mssql1.24.0 remote-containers0.384.0 sqltools0.28.3 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --I saw and created this issue anyway because I think that issue is a) too old b) has too many other things going on. <!-- Describe the feature you'd like. --For me, personally, I'd like a simple way to enable/disable automatic extension updates per extension. I really care about updates for many of them and want to read the changelog before I update but for some, like Copilot, who get several updates a day, I really just want to always be on the latest. Copying section 7 from the above: Users could opt-out of Auto-Update for specific extensions, with toggle button next to Disable/Uninstall in Extensions Sidebar (under gear icon menu) and next to those buttons in Extensions Detail Page. This could allow users to stick with previous versions before new high-risk permissions became required This could allow avoiding updating to problematic versions of extensions until issues are resolved. This could allow users to manually review/approve updates based on reviews and changelog for higher (security or reliability) risk extensions This could be controlled per extension without disabling globally as may be desired by default for most extensions. Can be set per extension to "Default" vs Auto-Update vs. Disable Automates, like with Firefox, with Default behavior controlled through global setting. Could provide Undo Update button or choose from version history (like with Chrome/Firefox extension stores) on extension details page, to enable rollback to previous version after an update causes issues, instead of just disabling until if/when ever fixed.
Have you tried to select specific version for extension? This should effectively force version and prevent updates.
No, would that still show if there was an update available?
It should show. Also September 22 update had few updates to including . Check it out
Supported auto updating options per extension/publisher <img width="550" alt="image" src=""This is enabled when auto update mode is disabled or set to (new config)


VSCode Version: 1.6.0 OS Version: OSX 10.11.6 *.ini files comments-line starts with the SEMI-COLON. but VSCode has insert (or remove) the HASHMARK.
Pull request pushed, thanks a lot !


VSCode Version: v1.2.1 OS Version: Windows 10 Steps to Reproduce: file type to INI "A=b;xxxx" in file content Expected: "b;xxxx" colored as white Actual: "b" in white but ";xxxx" in green ";xxxx" should only be regard as comments when there is no other contents in the line before ";"
This issue was moved to demyte/language-cshtml


VS Code Version: insiders/from sources Task terminals don't respect setting so decorations cannot be disabled.
thanks for creating this issue. I remember noticing this then got distracted by some other issue
we're separating the task decorations from terminal decorations (shell integration), so will have a setting
Verified that works


fyi
Verification: opt into edit sessions using , then ensure the edit sessions view does not appear in the sidebar until you run the Show Edit Sessions action in the command palette.


Issue Type: <bBug</bWrite http://192.168.1.7:3000/ into a text file. Command-click it to try to open the link. You will get an alert asking whether you want to open the external website. Click “Configure Trusted Domains”. <img width="1025" alt="link and dialog asking to confirm opening external website" src="https://user-"Look at the second option in the menu. It says “Trust 1.7:3000 and all its subdomains”. But 1.7:3000 is not a valid address. <img width="1024" alt="link and menu with buggy entry “Trust 1.7:3000 and all its subdomains”" src="https://user-"I can only guess that VS Code thinks that “7” is a TLD and “1.7” is a full domain name. What I actually want to do is whitelist opening all links to IP addresses like . In other words, white-list the subnet . At least, I think that makes sense. But I am not a network engineer, so if it makes more sense to recommend to the user whitelisting some other subnet such as , or whitelisting only the address but on any port, that would be fine too. VS Code version: Code 1.40.1 (, 2019-11-13T16:47:44.719Z) OS version: Darwin x64 18.7.0


Type: <bBug</bPinning a terminal editor does not set some of the context variables that are normally set when pining a text editor. Here are the ones I've noticed: activeEditorIsDirty activeEditorIsFirstInGroup activeEditorIsLastInGroup activeEditorIsNotPreview activeEditorIsPinned In the case of activeEditorIsPinned this makes it impossible to detect if the current terminal editor is pinned. Since there is no command to toggle the pin on an editor this means it's not possible to create a single keybinding that can intelligently pin and unpin the current terminal editor. In the case of activeEditorIsLastInGroup it means it's not possible to create a keybinding to move a terminal editor out of the "pinned section" of editors in the current group. When editors are pinned they are moved to the left side of the current editor group. When moving an editor to the previous position in the current group if it happens to cross into the pinned section it will become pinned. But the inverse is not possible: you cannot move a pinned editor out of the pinned section unless there happens to be something else unpinned to the right of it. So I have a keybinding to unpin the current editor if it's the last editor in the current group. Since terminal editors don't set the required context they break this binding. Steps to Repro: Open a terminal in the editor area Pin the terminal editor Inspect context keys Notice activeEditorIsPinned is not set VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-10T16:22:19.445Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
The type of editor should not play any role in this. I somewhat doubt this is a bug in our code, so setting label that we need confirmation. Open for help, investigation, suggested fixes, PR.
This one I cannot confirm or reproduce. See this gif where I open a terminal, pin it and then inspect the context keys: ! What are some exact steps?
Looks like it depends where you click when inspecting context keys.


I'm clicking inside the terminal, where my cursor is, because I'm attempting to make keybindings that work when using the terminal. You're clicking the editor tab. So it appears the context is set for the editor, but when you focus the terminal within it that context is removed. Interestingly I still see some of the context so not all of it is removed.
Quite likely that the terminal itself sets its own context keys.
<!-- 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, but while confirming the fix I noticed more issues with these context keys


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.85.0-insider OS: Linux (codespaces) Steps to Reproduce: in the terminal prompt is contributed via env collection by Python extension. Normal terminal: ! Hovering says that collection is applied. Hidden terminal: ! Although it says that no environment collection is contributed upon hovering, collection is still applied as can be seen in the terminal prompt.
it seems like this is actually a bug where the initially hidden terminal doesn't show the applied environments but should? Making a terminal hidden was just meant to be about visibility, not environment?
I'm fine if we change hidden terminals to also apply environment collection, as long as we get support for Python extension decided not to send activate commands to hidden terminals: , as hidden terminals are considered private terminals belonging to a specific extension. One could probably argue similarly for not applying environment collection to such terminals.
Based on offline discussion we're continue to go with NOT applying environment collection to hidden terminals, due to it affecting remote scenarios.
We investigated that env collection from shell integration in unix is still being applied on hidden terminals, i.e is still being applied when it should not. Any further updates?
Code to disable for terminals: Where vars are set:
I cannot reproduce this on Windows or macOS. Steps: Code - OSS a terminal and verify the environment does not include terminal-sample from vscode-extension-samples via symlink a terminal and verify the environment does and select the new terminal and verify the environment does not include Maybe you had the variable set in the parent environment (main/server?) which is why it showed up?


Please try it on Linux (codespaces), stated in the original report, this issue doesn't exist on Windows. And I don't have a macOS to verify.
Thanks, missed the remote bit
Seems like this behavior has now changed with: So we should either reopen this one or , to accomplish
you can accomplish by using
I see, suppose if is , but no is passed explicitly, I assume system environment variables and shell initialization scripts are still applied? What does window's environment mean here and will it be applied if is , but no is passed.
We don't have any environment to provide, all we want to do is skip applying env collection while the rest of the environment stays as-is, can you guide us on how to exactly use to achieve that? Also, we would expect shell integration to be active.
basing the environment on should do the trick
Gotcha, will try that. I assume shell initialization and integration scripts are still run?
looking at the code, I think shell integration does activate even when strictEnv is set
What are some verification steps for this issue? For example, how do I get Python deactivate to show up?
steps at , remote only
Actually we reverted the change made in this issue with , so even hidden terminals have environment collection applied by default now.
:+1: So the steps are: a terminal and verify the environment does not include terminal-sample from vscode-extension-samples via symlink a terminal and verify the environment does and select the new terminal and verify the environment does include
How do I do step 3? Am I opening the terminal-sample workspace after cloning and creating a symlink to it?
you can build the extension and do it in the insiders extension development host


Testing comments view open and scrolled to the top of the file enter in the node :bug: I get scrolled to the first comment
This also happens if I expand the node after collapsing it, which I found a bit surprising, as I didn't hit enter on a specific comment, just the file node
There are a couple problems here: We should only expand/collapse the file node when the twisty is clicked/entered (we should have both an action and an expand/collapse with the file is clicked/entered) We should just open the file and not scroll to a comment when the file node is clicked/entered.
Actually, since you're opening the file from the Comments view, it makes sense to reveal the first comment. I'm just going to fix the expand/collapse + action issue.
I just verified this by making sure that clicking on the node doesn't expand/collapse the node (only the twistie can). Please lmk if that's sufficient!
That is sufficient!


Performance Issue When using VS Code to debug a java program with many threads (~500) the UI becomes generally unresponsive and sometimes freezes for about 10-20 seconds when hitting/continuing from a breakpoint. The problem seems to be that VS Code tries to refresh the "Call Stack" very often (and each refresh takes 100-200ms with that many threads) VS Code version: Code 1.20.1 (, 2018-02-13T15:23:28.607Z) OS version: Darwin x64 17.4.0 <details<summarySystem Info</summary </details<details<summaryWorkspace Info</summary</details<details<summaryExtensions (10)</summaryExtensionVersion ------ vscode-eslint1.4.6 tslint1.0.28 prettier-vscode1.1.3 python2018.1.0 debugger-for-chrome4.1.0 java0.19.0 lwc-vscode0.11.2 perforce3.1.0 rewrap1.7.1 vscode-java-debug0.6.0 (1 theme extensions excluded) </detailsReproduces only with extensions VS Code example stack trace when freezing: <img width="349" alt="stack-trace" src="https://user-"
fixes this
once the insiders build is out on Friday you can try this out with your PR and let us know if all is good now - thanks
Will do, thx!
tried with the 2018-03-09T05:17:20.534Z insiders build and it worked great
great, adding verified label.


Type: <bBug</bCC [I cannot easily find my authored issue so I am creating a new] Ctrl+LeftArrow and Ctrl+RightArrow does not work in the Output View (Ctrl+Shift+U) area. This happens on Windows. This means screen reader users cannot navigate word by word within the output view. Ctrl+Shift+U to focus in the Output View Choose any output (e.g., terminal) if you can navigate word by word via Ctrl+LeftArrow or Ctrl+RightArrow VS Code version: Code - Insiders 1.92.0-insider (, 2024-07-12T05:08:08.550Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (125)</summaryExtensionVersion ------ vscode-openapi4.27.0 zotenote1.0.1 android-dev-ext1.4.0 aiprm-lang0.0.2 Bookmarks13.5.0 openscad1.2.2 spellright3.0.134 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.6.0 external-pdf1.2.0 doxdocgen1.4.0 vscode-markdownlint0.53.0 vscode-eslint3.0.10 vscode-quick-select0.2.9 vscode-deno3.38.0 gitlens14.6.1 EditorConfig0.16.4 prettier-vscode10.1.0 figma-vscode-extension0.3.5 vscode-firefox-debug2.9.10 shell-format7.2.5 vscode-google-translate1.4.13 codespaces1.17.1 copilot1.213.0 copilot-chat0.18. remotehub0.62.0 vscode-github-actions0.26.2 vscode-pull-request-github0.93.


cloudcode2.14.0 overleaf-workshop0.13.0 cslpreview0.2.2 path-autocomplete1.25.0 latex-workshop10.1.0 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 commitlint2.6.0 language-julia1.90.1 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 language-matlab1.2.4 zotero0.1.11 git-graph1.30.0 azure-dev0.8.3 vscode-azureappservice0.25.2 vscode-azurecontainerapps0.6.1 vscode-azurefunctions1.15.1 vscode-azureresourcegroups0.8.3 vscode-azurestaticwebapps0.12.2 vscode-azurestorage0.16.0 vscode-azurevirtualmachines0.6.5 vscode-cosmosdb0.22.0 vscode-docker1.29.1 vscode-edge-devtools2.1.5 black-formatter2024.3. debugpy2024.9. flake82023.13. isort2023.13. python2024.11. vscode-pylance2024.7.1 jupyter2024.6. jupyter-keymap1.1.2 jupyter-renderers1.0.18 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.377.0 remote-ssh0.113. remote-ssh-edit0.86.0 remote-wsl0.81.8 vscode-remote-extensionpack0.25.0 azure-account0.12.0 azure-repos0.38.0 cmake-tools1.18.43 cpptools1.21.0 cpptools-extension-pack1.3.0 js-debug-nightly2024.7.517 powershell2024.3.2 remote-explorer0.5. remote-repositories0.40.0 remote-server1.6.


vscode-github-issue-notebooks0.0.130 vscode-node-azure-pack1.2.0 vscode-selfhost-test-provider0.3.25 vscode-serial-monitor0.12.0 vscode-speech0.10.0 vscode-speech-language-pack-ko-kr0.4.0 vsliveshare1.0.5932 windows-ai-studio0.3.3 autodocstring0.6.1 pandocciter0.10.4 publisher1.1.3 shiny1.0.0 shinyuieditor0.5.0 quarto1.113.0 r-debugger0.5.4 java1.32.0 vscode-xml0.27.1 vscode-yaml1.14.0 r2.8.4 multi-command1.6.0 AudioQ0.0.2 vscode-deepl1.1.1 abc-music0.4.0 lua3.9.3 latex-utilities0.4.14 cmake0.0.17 vscode-terminal-here0.2.4 windows-terminal0.7.0 errorlens3.16.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-conventional-commits1.25.0 vscode-arduino0.6. vscode-java-debug0.58.0 vscode-java-dependency0.23.7 vscode-java-pack0.27.0 vscode-java-test0.41.1 vscode-maven0.44.0 zotero-cite0.8.6 markdown-all-in-one3.6.2 grammarly0.25.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
do you know why this isn't currently supported?
It seems to work for me in Mac, are you seeing it otherwise?
It does work for me, although sometimes with the screen reader enabled, it's reading the word then a whole chunk of text. I'll try on windows.
It’s not working in Windows.
Can reproduce on windows. I see that this is happening because there's a part of the when clause for and of for windows
Removing that from the clause fixes it. Looks like that condition was to fix this can you try removing that condition from the clause and seeing if you experience any consequences of doing so?


This looks and reads a bit weird to me: <img width="262" alt="image" src="https://user-"This does not really do anything when I am in Column Layout which I think is even the default.
Can context menu entries be hidden when a context key condition fails?
I think or the clause of the command, I always forget: knows for sure
precondition just disables that entry, it doesn't hide it
try with:
It is the clause that defines if an item appears in the menu
In addition to hiding this when it doesn't apply: can we find a better solution for when it applies. Can we have for column mode Show Base for mixed mode (radio-logic for these two) Show Base At Top Show Base In Middle
Fixed <img width="167" alt="image" src="https://user-"
I still find this weird: <img width="198" alt="image" src="https://user-"Throwing in some ideas: Column Layout I would think just a toggle for the base is fine so that it becomes a single entry. Mixed Layout A radio group of 3 entries: "Hide Base", "Show Base Top", "Show Base Center". Alternatively if we worry about too many entries, we could also do a submenu for "Base" specifically with these options.
Jo's suggestion in is also fine, but I think we need that third entry to allow for hiding when in mixed layout.
Verification steps: Open a merge conflict and verify these menu entries: ! !


Upstream:
It's not true that it takes very long. It does not get visible at all. I have to downsize the terminal pane to a certain size to make it visible again. In my case it's about 5-10 lines. Seems to me that the canvas is not resized properly. There are no problems if I disable GPU rendering (code --disable-gpu). Also without any noticeable performance issues. Would be nice to have a flag in the preferences to disable GPU rendering as a quick workaround. One of the reasons for using code (instead of Atom or Sublime) was the integrated terminal which seems to be broken since the new canvas rendering was introduced. My System Config: OS X 10.11.6, GPU: NVidia 8800, 4GB RAM
that will probably get fixed as part of this as well, it's probably something to do with your GPU/Chromium not liking the texture sizes above a certain size.


enable sticky scroll open a diff editor in a TS file toggle inline diff observe that the original line numbers are garbled We could disable sticky scroll in the original editor when the diff editor is rendered to be inline here --


Type my long commit message Type and suggest widget for issues pops up aggressively Press esc to get rid of it All the commit text is gone I think this is new?


open explorer select a file press and to copy paste a file in place :bug: nothing happens, in the past I would get a copy of the file
Hmmm. I cannot repro this and am able to copy and paste. Do you have any custom keybindings? What is your setting?
It's the default, this is from the keybindings log
Hmmm I wonder what has happening with your keybindings. Here's mine triggering the explorer specific ones with the proper when clauses. Is your explorer in a non-default position (i.e. not the activity bar)
This gets more and more interesting... The keybinding is there and not (re)configured but it looks like something is wrong with context keys. The seems AWOL. Maybe that's because I moved the explorer around very much last endgame? <img width="2819" alt="Screenshot 2023-03-01 at 16 55 16" src="https://user-"
Think I found the bug. the folders view to the right sidebar the remaining explorer view container in the activity bar Can't copy and past in the explorer anymore
I know this is very early into the next release cycle, but could this be released in a patch to stable VSCode? I have been bitten by this in stable VSCode after the February 2023 update, by dragging Explorer over to the secondary sidebar. Or is there a workaround to restore functioning of these keys, other than resetting the user profile altogether? I've tried dragging the Explorer menu back, and also right-clicking and selecting "Reset Location". Neither seems to "restore" the functionality of these keys. This affects any command using in , such as deleting a file with the Delete key (hopefully people find this issue instead of creating a new one for every such broken key). The workaround I've managed to apply is to manually remove from every expression possible, which may have side effects, but it works in a pinch. Copy all the keybindings below (expand for details, grab bindings between the comments) into your to fix this in a pinch. <details</summary</details
Does the command in the command palette not fix it for you? This will reset all your views to their default positions.
My keybindings workaround bypassed the issue on my home computer yesterday.


Now I'm at work (both are Windows machines, VSCode up to date), and I went to try your approach. However, I have a lot of menus in my secondary sidebar, so I didn't want to on my main profile, so I did the following: Ensure my workaround from before is commented out Export the profile as Import the profile Switch to that profile Verify that the key doesn't work First, try the less invasive, right-click on Explorer button in secondary sidebar and click key, and others, works again, even when putting the Explorer back in the secondary sidebar Curiously, switching back to the profile, the key, and others, works again, even when putting the Explorer back in the secondary sidebar Never had to go the nuclear option and So, some funny business related to one of the steps above, probably the settings profile shuffle, restored basic functionality of those keys, without having to manually tweak the expressions as before, and without having to go nuclear and . It's possible to work around this with some UI shuffling, but your mileage may vary. My initial request to backport the patch to stable VSCode is not so serious since there are a few workarounds documented here. Also, thanks for the quick work in the PR! I'm looking forward for this behavior to stabilize in future versions, since secondary sidebar Explorer view (without the compromise of moving the whole primary sidebar over) is great!


mac select an entry in the explorer press to trigger rename the file is being opened, no rename log
tested on windows and this doesn't work for me - not sure if it's necessarily platform specific
Steps to verify explorer that keybindings still work for the explorer
Mac Pro (Intel 2019) user here. I also have the same problem. Before pressing can rename files but now it just navigates to the file editor window.
This will be fixed in the next release which comes out sometime this week. In the meantime -should fix it for you.
Thank you for prompt reply. Yes, it works fine now!!


! Which causes the output bg to look slightly off: ! This should be , probably happened after the color token name changes during endgame testing.


While helping Marketplace improve extension search I noticed that for most queries there are no more than 5 good results. And we currently show an infinite list which depending on Monitor size would show 10 - 20 extensions. Also we sometimes struggle with the small size of extension items in the list - not enough space for all the decorations we would like to render. Based on the two above, I suggest we explore with increasing the vertical size of the extension items in the list. Ideally this would allow to present the information in a cleaner way when users search for extensions. I am not sure how this would effect the list of installed and recommended extensions. Ideally we would also increase the size of those to be consistent, but for those cases I am not convinced if it would be a win. what do you think? for ux thoughts Example from my screen !
From a visual standpoint it makes sense to explore giving these some breathing room. As far as solving for quality results, I don't know if making them bigger will necessarily solve that problem alone. It could be that we have a sort of "Top Results" section up top with the remaining results in another section. Just one idea off the top of my head.
I agree its worth exploring it give more space for an extension in the viewlet. But this might impact if the size of the screen is smaller.
We closed this issue because we in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider. If you wonder what we are up to, please see our and . Thanks for your understanding, and happy coding!
I see this is merged and should be latest VS Code Insiders but I do not see any changes in my VS Code Insiders. am I missing something here?
I'm seeing the latest after updating: <img width="320" alt="CleanShot 2023-01-03 at 08 48 48 src="https://user-"<img width="328" alt="CleanShot 2023-01-03 at 08 49 32 src="https://user-"
I just got the update. Looks ok to me - I will need some time to adjust. Let's see what insiders users and the rest of the team says :)


Testing Why is the setting name linked once and once it just shows the ID? Both should be linked, or maybe you can rephrase it to just use the setting name once like <img width="548" alt="image" src=""
That's a good point yeah


There is a injected text that is left over on line 52: <img width="883" alt="image" src=""Saw this stack-trace, I'm not sure if it's related or not:
I am trying to reproduce this issue but am currently not able to. Do you know what is the file you were triggering inline completions on, and what inline completions you saw ?


https://user-
Related ,
happening bc the first line's marker isn't disposed of (and thus the decoration isn't either) !
so maybe we should have some API on xterm like so that can be handled specially?
oh here's the issue that solved but looks like that actually wasn't solved anyway
Just to confirm, to verify this issue, are you typing commands followed by the clear command in between? Or are you clearing the terminal another way?
Typing and clearing
Pretty sure this is the command, not run in the terminal


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.50.1 OS Version: 10.15.7 Steps to Reproduce: system input source to shuangpin, before which add shuangpin as an input source. ! caps lock, with caps lock unlock, you will input Chinese character, which is an expected behavior. something in the integrated terminal, I can only input upper case letters. But when I input something in editor or some other application, I can input lower case letters. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes. Actually I think it might be the problem of might decide the letters by cap lock. This is not as expected with shuangpin mode.
This looks like an upstream issue in
Thanks for replying. Opened an issue for


Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.88.0-insider OS Version: MacOs Steps to Reproduce: In the python and python debugger extension we use the QuickPick, we add an option to accept the value in the input. It was working in stable, but in insiders it doesn't work. Steps: a picker some text in the input box, make sure that it match with one option at first. enter, to select the text in the input box. last value that appeared in the list is the one that is selected. You can check the implementation . I was debugging the code a little bit, and found that in stable when you press enter, the function is called. But in insider when you press enter instead of call that function, the function is called.
Verification: Install Python extension Open a python workspace with no Open the debug pane and click the "create a file" Choose Python Debugger Choose Django Type ONLY 'b' and notice that "Browse Files" becomes the active item Type then, 'z' and notice that the list is empty hit ENTER and notice that the gets created with "bz" in the
The fix fully resolves as well!
Resolves my issue as well.


re focus SCM input show context menu the is a entry "Command Palette..." which is awkward <img width="703" alt="image" src="https://user-"
Related to this, on my system that context menu also gives me entries that have been contributed by a couple of my extensions.
Same issue on macOS as well
This happens across all our inputs which use the Editor. IMO we should not include all those contributions and should just have , & in that menu. What's the simplest way towards this
The "Command Palette..." should potentially have a better context key for , not :
Thanks! But this is actually only half of the story. As mentions, extension contributed commands show up: ! Should we file issues to these extensions, suggesting to change their clauses?
It might be better/simpler to have another menu id, something like or even something SCM specific
To reproduce, you can use:


Testing The description of 'git.branchRandomName.dictionary' could be improved to say that each value represents a segment.


Testing Open the settings UI for the settings and add new values. Observe that you can any input (not just , ...) and there is no warning when a value is mistyped. This can be easily improved by adding an enum to the items: This will limit the items to the given values and show as a combo box in the settings UI: !


Type: <bBug</bWhen pressing to collapse all nodes in a list view it leaves selection in such a state that you cannot expand nodes with until you do something to change the selection. ! I believe what's happening is is leaving the originally selected node selected. So after executing the command you end up with 2 selections, your original selection plus the last root node in the list. The original selection is the primary selection, and if it has no children does not have anything to expand and is a no-op. As a user it looks like you have the root node selected, which has children to expand, but pressing does nothing. Pressing then expands the list to reveal your original selection and you see that you unexpectedly have multiple selections. The current behavior of appears to be: Leave the originally selected node selected Add a second selection to the last root node in the list The expected behavior here is: Move selection to the root node of your currently selected node Ideally this also retains multiple selection: each selection is moved to the root node of that selection. VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-10T16:22:19.445Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Looking at this again in the File Explorer it looks like the selection highlight is left on the where the original selection was despite the fact that the node is now in a different position. However, the "real" selection is still on the node. This means it looks like one thing is highlighted and pressing opens a different thing.
Just submitted a PR for this. Could you please review it?
What is the behavior supposed to be? Here's what I see: keyboard to focus a tree node that has a parent to collapse all moves to the whole tree and arrow down takes me to the first tree element. Right arrow does nothing.
The current behavior sort-of fixes the issue, insofar as is dodges it by doing something less desirable - moves selection to the whole tree. Imo, selection should remain on the root node(s) of whichever tree branch selection is currently in.


I think this is what the previous behavior was trying to do, it just had an issue with leaving selection in a bad state. A couple examples ([x] denotes current selection): Start state End state, after Stat state End state
I agree, feel free to send an issue for it. Your observations are the fixed state. Here's the entire story: Marking it as verified.


Testing focus on trusted URI list of items tab to navigate to the X to remove an item. Press to trigger removal nicely gets removed from the list, however focus is lost Focus should be preserved in the list on the neighbour item (example: checkout how Explorer does that when deleting a file). I thought this would be tackled via
The trust editor does a lot of full page re-rendering which I should improve (remove) so I doubt this is an issue with the table widget itself.


Those who are used to having the collapse button on the far right might accidentally hit the search tree toggle. <img width="502" alt="image (2)" src="https://user-"Ideally, move this icon to the other side to prevent confusion. cc
To clarify: I think any new position will have an impact to someones muscle memory, that is probably hard to avoid. For me personally the collapse action was heavily used in search results. maybe for guidance, I also feel like we have quite exhausted the number of actions for the viewlet, maybe about time to think about introducing a "..." and move some there?
That's true, it is getting a little crowded. What else would be in the ? Might seem odd if we don't have plans for anything else in there?
For reference, the button is here for source control (outside of the ) so I wonder if people will expect it to be an actual button with an icon in search? <img width="241" alt="image" src="https://user-"
Yeah I like the idea of keeping this in sync with other views, though we probably missed out on keeping some of the buttons in sync, like the refresh button...
Should we remove the "Open Search Editor" action? it is duplicate, there is a link action also from the results: !
cc
Eh, I think you might want to open a search editor before doing a search in the sidebar too.
! I did some thinking and I think it should go here because: shouldn't go in the far left or right because people probably have muscle memory as refresh/collapse as side-most buttons. shouldn't go on either side of because the icon for that and are too similar, may cause misclicks. So, by process of elimination, it ends up where I placed it in the photo. Any opinions?
I created to move it to the place that I mentioned, but I'm open to other options in the future. Just seems that the new position should be better than what we have now, so I wanted to merge it into insiders at least.
Thanks!


Here with the long path a "..." would help: <img width="673" alt="image" src="https://user-"


cc: Type: <bBug</bSteps to reproduce: at least 2 files in VSCode. orca. ctrl+tab to switch to the next open file. In my environment orca announces something similar to the following: Is this the expected behavior? VS Code version: Code - Insiders 1.78.0-insider (, 2023-04-06T05:21:17.374Z) OS version: Linux x64 6.2.8-200.fc37.x8664 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ doxdocgen1.4.0 vscode-markdownlint0.49.0 vscode-eslint2.4.0 EditorConfig0.16.4 copilot1.79. rest-client0.25.1 better-cpp-syntax1.17.2 docomment1.0.0 azure-pipelines1.208.0 vscode-docker1.24.0 csharp1.25.4 vscode-dotnet-runtime1.6.0 vscode-kubernetes-tools1.3.11 remote-containers0.289.0 remote-ssh0.101. remote-ssh-edit0.84.0 azure-account0.11.3 cmake-tools1.13.45 cpptools1.15.1 cpptools-extension-pack1.3.0 makefile-tools0.6.0 powershell2023.3.3 remote-explorer0.5. vsliveshare1.0.5834 oracledevtools21.5.0 fabric8-analytics0.3.6 java1.17. vscode-xml0.25. vscode-yaml1.12.2 sonarlint-vscode3.16.0 cmake0.0.17 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-boot-dev-pack0.2.1 vscode-spring-boot1.45.0 vscode-java-debug0.49. vscode-java-dependency0.21. vscode-java-pack0.25. vscode-java-test0.38. vscode-maven0.41.


vscode-spring-boot-dashboard0.12.0 vscode-spring-initializr0.11.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This is happening because of the fix for I think it is behaving as designed, though will leave that with
That's a bit weird. Since experience does not visually render a placeholder. So I would not expect it gets read out.
Question is, should it say nothing, or is the aria-label for not correct and it should be ? I'm leaning "nothing" because otherwise they might have to hold down until the actual quick pick option highlighted is read out.
I have a fix out with the "nothing" idea... but would love to know what you folks think before I merge.
In version 1.77, when I press ctrl+tab, orca informs me that the focus has moved to a list box and the name of the next file is read. Imagining the following scenario: two files, a.js and b.js. start editing the a.js file. press ctlr+tab. My screen reader reads the following information: List Box, b.js. In my view this behavior would be sufficient.
It is fixed, thanks.


Type: <bBug</btypescript server keeps crashing after the latest update VSCODE ! I can reproduce this with all the extensions disabled. LOG: ! VS Code version: Code - Insiders 1.76.0-insider (, 2023-02-03T05:23:17.202Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ ng-template15.1.0 atlascode3.0.1 vscode-markdownlint0.49.0 vscode-eslint2.2.6 githistory0.6.19 gitlens13.2.0 prettier-vscode9.10.4 vscode-yaml1.11.0 sonarlint-vscode3.14.0 code-spell-checker2.16.0 vscode-stylelint1.2.3 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Please try collecting the TS Server log from the crashed instance: VS Code and reproduce the problem the section of the output panel the very top, find the first line that prints to path to the semantic error log file. It should look something like: That file contains the typescript logs. Look through that log file for the first error or stack trace you see. If you can share the log, I can also take a look to see if anything stands out
, for some reason the log file location is shown as [Object object] (as pointed out by the pink arrow), I checked in the folder pointed out by the red arrow and the folder is empty. ! I have checked this for multiple folder I could see in the log prompt but all of them are empty.
a Microsoft member created same/duplicate issue , in case this could help with the debugging
Confirming that I also see when using verbose setting and all the log files are empty for me, which is also noted and shown on microsoft/vscode.
For me the directory under the object object is also empty, is that the case with you?
Yes, same.
should be fixed in the next insider release: microsoft/vscode
the object object issue is resolved, however, the file pointed by the log still does not exist. can you give it a try if you can see the logs?


i did some commenting in the file and found that commenting out setting stops the repeated crash. Note: I am not sure why I have /enabled this setting in the first place.
Oh wow, exactly the same for me. I also do not remember ever setting , but it was in my and removing it fixes the crash for me too!
Also confirming that with latest update is fixed but log directories are still empty. I've closed my bug as a duplicate of this one since it's pretty clear these are the same issue now. Are you able to repro using is Also do you know if this would ever have been set on user's behalf, which could impact the severity here if lots of people would have this in their settings?
Thanks and I can confirm that enabling cause the server to crash on windows. Oddly I don't see it on Mac. The server is likely crashing before logging can start too, which is why the log files don't exist I'm not sure how this setting got enabled for you. It's only meant for detailed performance investigations and should never be turned on automatically
Yay, thank you and


The stage is now a bottleneck to having the platform specific stages run: ! Each job compiles each target serially. We could further parallelize all targets across different jobs. !