Or would it be better to only tick the button when an installation of git is detected? The screenshot below shows that I clicked the button but didn't actually install Git. The item is ticked but attempting to run git in the terminal (or git pane) fails !
good idea, changed so that the item checks off when git is initialized.
Ohh yaa..I did not notice that Thanks for fixing it ! :)
I uninstalled git and reloaded to see the new "Install git" item. Then, I installed git, but the item wasn't checked off, and I wasn't sure what to run to get the item to check off. After reloading again, I didn't see the item. I uninstalled git again and reloaded. The item showed up, but checked off this time. I unchecked the item and reinstalled git, and ran git in the terminal, and the item still wasn't checked off. I switched workspaces, and I didn't see the item again.
Can we have which checks if git is installed when we reach this step?
No, it should work based on context keys, which have change events.
Ohh okay
Hi. What is the current status of this issue? Is there a bug for the current implementation? I can work on it if no one is working and someone gives me the context. Thanks.
Isn't it the expected behavior? If VS Code is open and git is installed, even Source Control tab doesn't notice this change; a reload is required for that. If this is not the expected behavior and automatic discovery of git existence is necessary, then this tab should also be fixed. I assume the item can be checked off by clicking the checkbox or Mark Done text below. This is also an expected behavior, I think. For example; you customized your shortcuts using Customize your shortcuts, then this item is checked off. After then you reset shortcuts but the item is still checked off. You probably doesn't expect the opposite. Because you understand how to configure the option this item provides. I think the key of checking off here is understanding the option. Otherwise most items may be reversed and should not be checked off after the reverse. On the other hand I think your statement shows that the natural flow of the Install Git item doesn't suit well to a checklist.


I am not able to test this at the moment due to some system issues, but I would consider the following sufficient for marking this complete: a user does not have installed, a tile is shown pointing them to steps for installing git and notifying of a need to reload the window to complete installation. A button/link could be shown to trigger a reload. completing the installation and relaunching VS Code, the tile for installing git is no longer shown, and the tile explaining git use inside VS Code is shown instead. I believe today we have this minus the part where we explain that a reload is required to complete git installation and provide UI to facilitate the reload.
Updated step to include link to .


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: V1.81.1 OS Version: Linux kkuser-virtual-machine 5.15.0-83-generic ~20.04.1-Ubuntu SMP Mon Aug 21 14:00:49 UTC 2023 x8664 x8664 x8664 GNU/Linux Steps to Reproduce: are constant changes in attribute states in the treeview calls to () functions result in memory leakage
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.82.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
<!-- 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!


<!-- 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 (N/A) <!-- 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.1 OS Version: macOS Steps to Reproduce: the shell, run , UPDATE: the system need to have a existing tunnel already running that the machine name is always inferred from Hostname instead of the machine name set through <img width="931" alt="image" src=""
Update: I noticed the "Connected to an existing tunnel..." line, and if I kill the tunnel first using and run the same command, it would correctly set the machine name. I'll update the issue description to reflect that.
Yea, if there's an existing tunnel we just connect to it and never enter the process in which the name would be set. Renaming a running tunnel is also possible but could lead to unpredictable side effects. We should just log a warning in this case.
I'm not seeing any warning:
still no warning. I made sure I was on the latest !
in your screenshot you can see the warning which is what I 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?: Unknown- repro uses a virtual workspace <!-- 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: OS Version: Version: 1.80.0 Commit: Date: 2023-07-04T15:06:02.407Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.80.0 Chrome/108.0.5359.215 Electron/22.3.14 Safari/537.36 Steps to Reproduce: a Github repository using "GitHub Repositories" extension, eg microsoft/vscode "Settings (JSON)" and add all tabs except Getting Started Extensions panel, search for " typescript" the Typescript and JavaScript Language Features extension and Reload Window "Settings (UI)" and search for typescript- no settings appear. Close "Settings (UI)" Extensions panel, search for " typescript" and re-enable the extension. Note, the extension activates immediately, the panel doesn't recommend Reload Window. "Settings (UI)" and search for typescript- Actual: no settings appear. Expected: settings appear


<!-- 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: Insiders 1.71 OS Version: Ubuntu 18.04 amd64 Steps to Reproduce: to install latest code-insiders packages from MS repository () The issue is that with the dependency on Debian derivatives changed to which only exists on newer releases (20.04 and later I think). I realise that support for Ubuntu-Ancient is low on the priority list, but I am sadly stuck with it, and would appreciate if there was a workaround. Installing newer libgcc releases as suggested in some places easily leads to a very broken system.
This is a side effect of now using bullseye sysroot, we should apply the following change https://chromium- to our debian calculate package deps.


empty profile open terminal, run or any other command that prints something press to clear the terminal :bug: the keyboard system is waiting for chord to be completed


When resizing the windows while the accessible help menu is visible, the help menu slides diagonally: !


Repro: Alt+F1 ! If should be in the center as that's the most obvious location Version: 1.80.0-insider (user setup) Commit: Date: 2023-06-28T08:01:04.380Z Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0.
Putting it here makes the most sense to me because that's where we put other components - like the quick pick. I want to get feedback from low vision users
That's fine, but if you're styling like the command palette we should position it in a similar way ! So below the title bar and not quite and maybe a little less wide
Re , we should also size the height similar to quick pick
But shouldn't the height be determined by the contents?
yes, but have a similar height cap to the quick pick
We should also use the same font as the quick pick
I think you've convinced me - this should be in the center.
Personally I preferred the top position, I'd just render it as the quick pick: Same position and same style. VS Code does not have many vertically centered dialogs. If you want to make it vertically centered, I'd suggest to align it with other vertically centered dialogs, like the trust dialog (notice the background shadow): ! ! Generally, I think, if there is no particular reason to be different, we should try to have a consistent UI throughout the entire product. I'm still in favor of the top position, as the workspace trust dialog is the only vertically centered dialog I know of and it is strongly modal (you have to click one of the buttons to make it disappear). FYI
Fading the background like the trust dialog is good imo, I like centered as it's a very special mode and it's modal as in clicking outside will always dismiss it, unlike the quick pick which may not dismiss when clicking outside. In the end the visual appearance isn't that important really, I just want it to be very obvious when the accessible view is up.
I agree that we should try to align with existing design. My personal preference is to have it positioned like the quick pick.


But in the end, it is not super important as pointed out.
One issue with doing it as the quick pick is it would look wrong being so narrow, and making is narrow would make it less accessible, say if a low vision user was using it.
Not sure it needs to be as narrow as quick pick. I just think the positioning of the quick pick is fitting. So the top and center. It could be wider or longer.
Now that we have the focus border, it is more obvious, so fine to be at the top IMO.
This is still not fixed imo, it should follow quick pick and look like this (native title bar): ! Not this (custom title bar): !
Verified off main :+1:


! The highlighting is important to understand which conflict in the bottom view corresponds to which conflicts in result. I think the change of the color of the dashed border is difficult to notice.


We can add the same regex validator for the terminal find widget input box if the underling regex engine is JavaScript regex. Close this one if we are using another regex engine somehow in
So in the terminal widget show things like this and reject the search? <img width="238" alt="screen shot 2018-10-11 at 11 58 06 am" src="https://user-"
I would like to try and work on this feature. Could someone tell me where to start working on this feature?
the terminal find widget code is here: It extends the SimpleFindWidget: Not sure where the validator is but I'd look around the and files.


Issue Type: <bBug</bWith the latest update, active and inactive menu in settings UI does not look any different from each other VS Code version: Code 1.66.0 (, 2022-03-30T05:50:14.623Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 3.10.0-1127.10.1.el7.x8664 <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ LogFileHighlighter2.15.0 remotehub0.28.0 better-cpp-syntax1.15.13 blockman1.5.7 jupyter-keymap1.0.0 remote-containers0.231.1 remote-ssh0.78.0 remote-ssh-edit0.78.0 remote-wsl0.66.0 remote-repositories0.4.0 material-icon-theme4.15.0 rewrap1.16.3 vscode-icons11.10.0 vscode-todo-highlight1.0.5 path-intellisense2.8.0 vscode-clock0.0.1 gitlens12.0.5 systemverilog0.12.1 prettier-vscode9.5.0 seito-openfile1.8.8 html-preview-vscode0.2.5 jira-plugin0.22.2 gitlab-workflow3.41.2 gc-excelviewer4.2.54 beautify1.5.0 path-autocomplete1.19.1 svg1.4.17 vscode-jira0.6.0 restructuredtext183.0.0 python2022.4.0 vscode-pylance2022.3.4 jupyter2022.3. jupyter-renderers1.0.6 cpptools1.9.7 veriloghdl1.5.3 subtle-brackets3.0.0 LiveServer5.7.5 code-spell-checker2.1.11 vscode-input-sequence0.2.0 simple-rst1.5.2 vscodeintellicode1.2.17 better-align1.1.6 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
/gifPlease
! ! ! !


By "active and inactive menu" I assume you are referring to the tabs labelled "User", "Remote", "Workspace" etc. Which color theme are you using? Do you also see the issue when using the default themes (Light+ and Dark+)?
Yeah, I am referring to "User", "Remote", "Workspace" etc. I am using Night Owl Light Theme
Does this problem occur when you don't have a multi-root workspace open?
The issue is seen only with a multi-root workspace. Is it a known issue?


<!-- 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.77.3 OS Version: Ubuntu 20.04.6 Steps to Reproduce: VSCode on an Ubuntu computer (or on Windows using WSL) the built-in terminal the command and paste the following 39-character string into nano: : nano shows the error message "Unknown Sequence". Can no longer interact with the terminal, need to kill it and open a new one More details: nano version 4.8 This does not happen in nano using an external terminal. Only in VSCode's built-in terminal This does not happen for any other length of string, even other multiples of 39 This does not happen in other CLI text editors, such as vim
I can confirm this issue on Windows using WSL.
It happens with other 39 long strings as well. It also happens when not using WSL. Copying more characters solves the problem. For us it also happens with multiples of 39 (e.g. 156 characters, line breaks included)
When trace logs are enabled this is the exact sequence we send: Compared to 1 less : Note that the 200/201 wrapped around it is bracketed paste mode (which I just a way to disable so that may help ). So this seems to be either a problem with one of nano, conpty or node-pty.
I also just ran into this. I'm on Windows 10, using Remote - SSH plugin to connect to an Ubuntu 22.04 server. Right-click to paste in Nano, terminal locks up, have to Kill it.


Add/remove one character from the string and try again, works.
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 opened a bug on gnu nano's bugtracker:
I think I found a workaround, but haven't tested it: vscode , nano doesn't deal well with across writes and it is apparently difficult to fix in nano. vscode could split writes differently, using this algorithm that keeps escape sequences at the beginning and end unsplit (like bracketed pastes):
great info, we should definitely do this . I'll probably tweak your proposal a little to try catch escape sequences in the middle too.
I don't expect input sizes to be 50 bytes except when pasting, when pasting there should only ever be an escape sequence at the beginning and end, never in the middle (terminal apps are unlikely to deal well with pasting a string containing escape sequences anyway).
unless I missed something in the issue you linked, it's not that they need to be on the boundaries of the text but need to be included entirely in that string and not clipped?
yes, escape sequences need to be contained entirely in one write syscall. basically I am saying you shouldn't have escape sequences in the middle of a long input, so you don't need to look for them to avoid splitting them, they should only occur towards the ends of a long input or in a shorter input.
Nano's workaround was released in Nano 8.0:


Type: <bBug</bI have an extension that has been making use of the executeCommand API for "vscode.executeDocumentHighlights" to get the for different positions in a file. Essentially calling something like below: After a recent VsCode update, the API is no longer returning any values and simply returns . I'm not sure the best way to provide a reproduce for this. I originally encountered the problem with a custom extension/language server. However the problem also appears to occur when calling the same command on a simple typescript file so I believe it's a general issue rather than any thing specific to my environment. I've had a quick search in the VsCode sources and I have a feeling this commit might be responsible: I think the problem is due to now returning instead of . When it gets to the ApiCommand layer I think the function fails and returns as the function has been given a instead of VS Code version: Code 1.84.2 (, 2023-11-09T10:51:52.184Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (30)</summaryExtensionVersion ------ vscode-markdownlint0.53.0 vscode-eslint2.4.2 mfcobol1.0.53 mfenterprise1.0.53 vscode-language-pack-ja1.84. csdevkit1.0.14 csharp2.12.19 vscode-dotnet-runtime2.0.0 vscodeintellicode-csharp0.1.26 python2023.20.0 vscode-pylance2023.11.10 jupyter2023.10.


jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-ssh0.107.1 remote-ssh-edit0.86.0 remote-wsl0.81.8 powershell2023.8.0 remote-explorer0.4.1 test-adapter-converter0.1.8 java1.25.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-java-debug0.55.0 vscode-java-dependency0.23.3 vscode-java-pack0.25.15 vscode-java-test0.40.1 vscode-maven0.43.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks This is a good find!
To verify: make sure this test has passed:


Type: <bBug</b I am not sure whether the insiders version reflects the up-to-date patch though, does not seem to work in Powershell. I have noticed that this works in my remote z shell though. VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-03T15:11:12.179Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 4.18.0-477.27.1.el88.x8664 <details<summarySystem Info</summary </details<details<summaryExtensions (104)</summaryExtensionVersion ------ aiprm-lang0.0.2 Bookmarks13.4.2 spellright3.0.118 mermaid-markdown-syntax-highlighting1.5.3 vscode-firefox-debug2.9.10 codespaces1.16.2 remotehub0.62.0 overleaf-workshop0.4.1 easy-snippet0.6.3 scheme0.2.0 better-cpp-syntax1.17.2 lilypond-snippets0.1.1 vscode-edge-devtools2.1.3 jupyter-keymap1.1.2 remote-containers0.322.0 remote-ssh0.108. remote-ssh-edit0.86.0 remote-wsl0.81.8 vscode-remote-extensionpack0.24.0 azure-repos0.38.0 remote-explorer0.5. remote-repositories0.40.0 vscode-serial-monitor0.10.0 vscode-speech0.3.


multi-command1.6.0 errorlens3.15.0 Bookmarks13.4.2 openscad1.2.2 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.3 codium0.7.13 doxdocgen1.4.0 vscode-markdownlint0.52.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.26.0 gitlens14.4.1 EditorConfig0.16.4 prettier-vscode10.1.0 shell-format7.2.5 vscode-google-translate1.4.13 codespaces1.16.2 copilot1.133.531 copilot-chat0.11. remotehub0.62.0 vscode-github-actions0.26.2 vscode-pull-request-github0.77. cslpreview0.2.2 path-autocomplete1.25.0 latex-workshop9.14.1 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 git-graph1.30.0 vscode-docker1.27.0 black-formatter2023.4.1 flake82023.10.0 isort2023.10.1 python2023.20.0 vscode-pylance2023.11.10 jupyter2023.11.


jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 azure-repos0.38.0 cmake-tools1.15.31 cpptools1.17.5 cpptools-extension-pack1.3.0 js-debug-nightly2023.11.217 remote-repositories0.40.0 vscode-github-issue-notebooks0.0.130 vscode-selfhost-test-provider0.3.20 vscode-serial-monitor0.10.0 vsliveshare1.0.5892 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.5 shinyuieditor0.5.0 quarto1.106.3 r-debugger0.5.4 java1.24.0 vscode-xml0.26.1 r2.8.2 multi-command1.6.0 vscode-deepl1.0.6 lua3.7.0 latex-utilities0.4.10 cmake0.0.17 errorlens3.15.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-java-debug0.55.0 vscode-java-dependency0.23.2 vscode-java-pack0.25.15 vscode-java-test0.40.1 vscode-maven0.43.0 markdown-all-in-one3.5.1 grammarly0.24.0 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
it is working for me on windows with PowerShell. could you share a gif?
!
-- Also, I have noticed that sometimes the first letter typed in Accessible View is not bypassed as demonstrated in the z shell.
Thanks for the gif, yeah, it's not working for you. I cannot reproduce even when I use a terminal in the editor area. Could you pls set terminal log level to debug, repro, and provide me with those?
Looks like shell integration isn't working properly for you for some reason, which is why this isn't working. We run the open command , so that's not happening.
And yeah, I can reproduce sometimes the key not getting sent to the terminal.


It's a timing issue related to the context view that is shown.
I'll split that issue out
As expected, your logs do not show , which explains why it's not working for you.
I wonder if is loaded for you. That would be the only way that event wouldn't happen
Can you pls run and provide the output?
!
So is disabled for you, which is why this isn't working.
If you add this line to your , it will work
is disabled by default when screen reader is used, and enabling it does not resolve the issue. Please see the gif: !
oh, seems we'll have to use instead for this case then.
I still cannot repro. I have the likely fix, so you'll be able to verify it tomorrow.


Type: <bBug</bVS Code (with or without extensions disabled, makes no difference) File -Preferences -Settings blank UI with no actual settings in it. ! If you leave the settings tab open and restart vs code (such that it reopens the settings tab automatically on restart) the settings GUI will be there, but all the extension settings will be missing (observe that it is missing from the menu here): ! If I then close and reopen settings they will again be empty. VS Code version: Code 1.84.2 (, 2023-11-09T10:50:47.800Z) OS version: Linux x64 6.2.0-36-generic (Ubuntu 22.04 LTS) Modes: <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
I also tried with to run this on the nVidia GPU instead of the built in Intel GPU. Makes no difference.
After running the command "Developer: Toggle Developer Tools", do any errors show up under the Console tab?
Yes I got 3 errors, they all seem related to that I'm behind a corporate proxy though. Note that I ran this with , but I still get errors related to extensions. I find this very strange ! ! !
When I'm not behind the proxy, settings work as expected. I find it very odd that VSCode would need to call out to the internet just to open settings. Opening the marketplace for extensions I understand, but not settings. Especially since I can also open settings just fine if I'm completely disconnected. It is just if I'm connected via the corporate network that it falls flat on it's face. For some further debug information: We use Zscaler at my workplace, which acts as a transparent HTTPS MITM proxy (no need/not possible to set any environment variables, but you do need to install the CA certificate). The proper certificate is installed in the system certificate store () and that works as expected with other programs. Also, other internet features in VSCode work fine, such as github copilot. EDIT: I also tried some of the settings in the proxy section of the settings to see if it made any difference. They were all set to the default values before.


made no difference made no difference is set, but I doubt I want to uncheck it if I understand it correctly. is set to override (default), and it sounds like it only affects extensions, so I didn't touch it. I don't see any option to manually add a certificate anywhere in the settings.
Based on I found that does work. That is a bit of a sledgehammer though, and not really an ideal (or even slightly secure) solution.
The Settings editor currently recommends the Copilot extension when it's not installed, which lines up with the error messages you're seeing. I'll put up a PR that skips over showing that feature in case of networking errors.
Tomorrow's should contain the fix.
what about the bit where it seems to ignore the root system certificates though? It seems there were actually (at least) two bugs here: one you fixed, where settings can't open when there are network errors fact that a corporate proxy with correctly installed CA certificates in the system store doesn't work. Presumably it isn't picking up the system CA certificates correctly.
thank you very much my problem is solved after follow this step (Open VS Code disable all extensions disabled, and enable once again all extension then i am successfully able to see my settings))
Please see on how to add a root certificate for Chromium, that also applies for Electron-based applications like VS Code. The root certificate example is:
Thanks this works. I thought I had already it, since I it in Chromium. But of course on Ubuntu Chromium runs in a snap by default, so it didn't use the same store as VSCode...


Example block quote in the extensions page. <img width="375" alt="image" src="https://user-"


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.84.2 OS Version: Ubuntu 23.04 Steps to Reproduce: an editor the editor that a was created but not removed In Chrome devtools, the retainer chain points to : !
I discussed with and when an editor is closed it is not disposed unless it is the last editor in the group and the group isn't the default group, so in the scenario described in this issue, the is still expected to exist. Here's how to check if the is being leaked: an editor. Check how many s you have. a second editor in a new editor group. the editor in the second group. Check how many s you have. If there is no leak, there should be the same number as in step 1. I have tested, and I don't see a memory leak from .
Thanks a lot for the info, it's really helpful! And apologies, you're absolutely right! I was so focused looking for something that would explain the two and didn't really think about anything else. Your steps make much more sense and with that I don't see a memory leak from . No wonder it took me so long to find the apparent source, when there is none... xD Thanks again!


Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.


/duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders


When running unit tests:
Similar problem in
This is not coming from those tests, the ugly part is these errors just report async. I found the following tests to be the underlying cause: The best is to run and add a breakpoint here:
I think I may have found a central fix...


Repro: Windows open test resolver window folder everything except !
I'm not able to reproduce this, even when I select the entire series of subfolders before before deleting. Is this on a VM?
No folder, just test resolver. It's an easy repro for me: ! Code - OSS about: Version: 1.69.0 Commit: Unknown Date: Unknown Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0.
Your slashes are going the wrong way, which is suspicious. How do you launch Code - OSS?
and then new test resolver window command
I've repro'd the slashes, but nothing I try will cause the missing directories to repro. Only difference I see is that I am on Windows 11 and you are on 10. Can you try swapping the separator on the resource label formatter? If that doesn't resolve it then we'll set up some time to debug.
I'm on Windows 11 too, 21H2, .739
Regardless of the value above it doesn't work for both and . Is there anywhere of interest I can debug into? Where does the trigger character code live?
We debugged into this together, seems related to the being (or ) and not
After our debugging yesterday this started to feel familiar:


Issue Type: <bBug</b(I have fixed this myself and will send a pull request in a minute) Steps to reproduce: accessibility mode in settings. a new document and type: to the beginning and press Ctrl+Right. Expected behavior: Cursor should jump to the letter w - that is the beginning of the second word. This behavior would be consistent with word navigation in most other Windows programs, e.g. notepad, MS Word, Visual Studio - just to name a few. Actual behavior: Cursor jumps to the space immediately after the first word, and the screenreader announces "Hello". The biggest problem with this behavior is that screenreader users would have to relearn how they make small edits in text files. For example, if I want to delete the word "world" in my example, I would go to the beginning of the line and press Control+Right until my screenreader announces the word I'm interested in. And then, assuming that cursor at this point is at the beginning of the word, I would press delete 5 times. However, in VSCode the cursor would be at the end of the word, and I would end up deleting wrong part of the line. VS Code version: Code - Insiders 1.40.0-insider (, 2019-10-25T14:03:31.497Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
FYI, I found related discussion here: , but that thread is now locked.


testing It would be nice to have a link on this prompt to open the workspace . that way i can see what was done. !
Link in the text mostly is not possible, as that works only for actual links. We might have to add a button that says which opens the file that was edited.


Originally filed here Problem: Notebook kernel pre-load scripts are now defined statically via the contribution However VS Code throws a 401 error when loading resources from within the Jupyter extension, If however we have a dummy script file (in the Jupyter extension directory) that is defined as a in the VS Code API , then all resources from Jupyter extension directory are loaded I.e. using the above API in some way registers the Juptyer extension directory as a supported for scripts, and using the static contribution does not.
I have a work around in the Jupyter extension right now, i've a dummy placeholder script that does nothing,
Can you share steps to reproduce this with the fix in place? Also, does this happen on normal desktop too, or only sshe Unclear why this is not working as we should add preloads to the local resource roots:
Here are the steps Install Python Install VS Code insiders and latest pre-release versions of Jupyter and Python NOTE: Install the pre-release version of Jupyter extension that is 2 days old Add the following setting into vscode Create a python env and install the following dependencies You can use the command to create a directory with Pytohn in a particular workspace folder (optionally you can use Python extension to do this for you) Run the following code in a notebook pointing to the above venv (i.e. select the above venv as a kernel) You might get prompted to enable CDN download, hit cancel for that The widget will not load, network tab in vscode will display a 401 error Note: This is now working in the latest pre-release version of Jupyter extension
I believe the broken version is be but I'm having trouble reproducing this The output either never renders anything (but there is no network error) or renders as an image: ! ! Any other steps?
Not sure which pre-release to use anymore, as the pre-release has changed since Please use the vsixc from this build (check the artifacts for the vsix) here is the Install Python Add the following setting into vscode (reload VSCode) Create a python env and install the following dependencies You can use the command to create a directory with Pytohn in a particular workspace folder (optionally you can use Python extension to do this for you) Run the following code in a notebook pointing to the above venv (i.e.


select the above venv as a kernel) You might get prompted to enable CDN download, hit cancel for that The widget will not load, network tab in vscode will display a 401 error !
I'm still unable to reproduce this issue Are you running the jupyter out of sources by chance or have you patched VS Code/jupyter in some other way? The path to the resource we a trying to load looks weird: . This looks like an extension development path In normal installs, we should load resources from a path that looks more like: If you are able, you can also try and sharing the result of that function compared to the path of the js file we try loading in the webview
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
information was provided
lets you specific an additional set of localResourceRoots that should be allowed when loading the preload. Can you please try adding these for the python static preload contribution? Let me know if fixes the problem!
Thanks , seems to work,
Changes were made upstream in VS Code, marking as verified.


<!-- Do you have a question? Please ask it on --VSCode Version: 1.12.1 OS Version: OS X EI Capitan 10.11.3 Steps to Reproduce: some project from GitHub. a file A.cs which has no fresh changes at all. on the editor of A.cs, and notice the button of on the top right corner above the editor doesn't display as disbled! Clicking it has no effect of course, but it should display as disable in this case just like what in the old versions.
Can't fix without , closing for now.
since it connot be fixed without , should this be kept open and linked to then?
Sure.
To keep the number of issues in our inbox on a manageable level, we're closing issues that have been on the backlog for a long time but haven't gained traction: We look at the number of votes the issue has received and the number of duplicates issues filed. Thanks for your understanding. Happy coding!
Hoping to re-open this because I got this as a feedback item from a few CS educators. They notice their students clicking it accidentally and being confused when there is no apparent action.
I think this has regressed, I now miss this button when a file is staged.
Fixed regression with
There is another regression (), so I will be reverting this fix for this, and will refactor it.


takes much longer to render with file nesting enabled. Impact is lessened by disabling file nest auto-expansions. is not significantly slower to render with nesting, though I have not collected proper numbers yet.
closedWith
takes a comparable amount of time to render with file nesting enabled, though there is a perceptible delay for both. However, I do also notice that the window becomes intermittently unresponsive after expanding , e.g. when scrolling in the explorer. Is this known?
Yeah, same thing happens with nesting disabled. There's an open issue somewhere for ways to reduce that (like streaming the dir contents).


In Markdown preview with light theme, numbers in code blocks are not clearly distinguishable because of their color. It will be good if a different color can be switched in light theme mode ! It seems that in , the following part may add a switch. Thank you!
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.474 --- <!-- score: 0.457 --- <!-- score: 0.456 --- <!-- score: 0.451 --<!-- potentialduplicatescomment --
Please share the text of the code along with screenshots
Actually, code itself does't matter this issue. It influences on many kinds of code with numbers.
Hey, I am a new contributor here. I want to give a try on this issue.


I did this on accident, but it took a little effort to figure out how I did it. Drag file from Finder onto Explorer Get scrollbar in Explorer to be visible, like by dragging near the top/bottom of the Explorer The entire explorer becomes highlighted when you hold the file over the scrollbar Drop file onto the scrollbar The entire explorer stays highlighted. It stays highlighted through interacting with the explorer and even switching to another viewlet. Only can be reversed by dragging another file onto the explorer. !
Actually a much easier way to repro is to two-finger scroll while dragging the file to get the scrollbar to appear.
i'm able to reproduce it. will try to fix it
couldn't find where to start. help is appreciated
I gave it a go in this PR:


<!-- 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. After updating to VS Code 1.92, I noticed several scroll-related issues with the integrated terminal: exiting a full screen CLI app ( or ), sometimes scroll up or down doesn't work anymore until I press cmd+c - at which point I am teleported back to the start of the cli log. See the below video: start scroll works (though way too sensitive - see issue 2) press scroll up down no longer works press as soon as I try to scroll again, I am teleported to the top of the cli log output (though, at least scroll works after that)Note, while the above triggers the issue, sometimes the issue also occurs even without that (at one point I just run and this bug was triggered) full-screen CLI apps (, , ), the scroll sensitivity is way higher than when scrolling in non-full-screen apps. This scroll sensitivity is uncomfortably high, way higher than it was before, and remains high even if I set to a very low value like 0.1. scrolling through full-screen CLI app ( or ), sometimes the terminal will not let me scroll up. If I try to scroll up, I am "teleported" back to previous position. As soon as I scroll down, I can't scroll back up to the previous text. <!-- 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. --Relevant information: VS Code Version: 1.92 OS Version: macOS 14.5 Issues are reproducible in ZSH.


I was also able to trigger issue 1 in BASH In ZSH, I am using oh-my-zsh and powerlevel19k, BUT I was able to reproduce the issues even after I temporary disabled oh-my-zsh and powerlevel19k in my Issues are reproducible even if I start VS Code with empty user dir and empty extensions dir. A few relevant settings: is off. Enabling it does not make things better N/A as I am not holding the key - I am just scrolling using the touchpad is off. Enabling it did not make things better I am sorry if some of the above reproduction steps a bit vague - some of these don't happen each time so it's hard to see what triggered it. But these all started happening as soon as VS Code got updated to 1.92. I will keep updating this issue if I have more details. <details<summarySystem info</summaryGeneral: System info: System Information | -- | -- CPUs | Apple M1 Pro (10 x 2400) GPU Status | 2dcanvas: enabled canvasooprasterization: enabledon directrenderingdisplaycompositor: disabledoffok gpucompositing: enabled multiplerasterthreads: enabledon opengl: enabledon rasterization: enabled rawdraw: disabledoffok skiagraphite: disabledoff videodecode: enabled videoencode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off Load (avg) | 2, 2, 3 Memory (System) | 32.00GB (6.06GB free) Process Argv | /Users/mak13180/site/esri/arcgis-web-components --crash-reporter-id -0746-4857-a17b- Screen Reader | no VM | 0% Enabled extensions (BUT, issues are reproducible with all extensions disabled): Extension Version -- -- vite 0.2.5 shell-syntax 1.0.5 vscode-tailwindcss 0.12.5 vscode-eslint 3.0.10 apc-extension 0.4.1 gitlens 15.2.3 vscode-html-css 2.0.10 prettier-vscode 10.4.0 lintlens 7.5.0 copilot 1.219.0 copilot-chat 0.18.1 vscode-github-actions 0.26.


3 vscode-pull-request-github 0.92.0 gc-excelviewer 4.2.59 todo-tree 0.0.226 search-node-modules 1.3.0 nodejs-repl 0.5.15 rainbow-csv 3.12.0 remote-ssh 0.112.0 remote-ssh-edit 0.86.0 remote-explorer 0.4.3 vscode-css-peek 4.4.1 vscode-yaml 1.15.0 code-spell-checker 3.0.1 vscode-stylelint 1.4.0 vscode-mdx 1.8.9 vscodeintellicode 1.3.1 explorer 1.0.6 vim 1.27.3 pretty-ts-errors 0.6.0 markdown-all-in-one 3.6.2 A/B experiment info: My (BUT, issues are also reproducible when VS Code is started with empty user dir): The log when VS Code is started as : </details
Upstream PR fixing it


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- 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: Windows 11 OS Version: 1.75.1 Steps to Reproduce: Using the following settings: ! ! a typescript file within a method/function following gets output (might have to navigate through some of the suggestions) even though snippets are off: !
Thanks for the patience. I cannot reproduce, please share more of your settings that might influence this. Also share data in a copy-paste friendly way (text over images)
Here are the settings that I am using to reproduce (all extensions disabled ): Once typing and going to the 3rd suggestion, I get this as a suggestion: !
Thanks for clarifying, looks like we aren't passing the filter here:
I can't figure out how to get that ghost text to show up for suggestions to verify this. I've never seen that ghost text for anything but copilot completions Do I need a suggestion provider extension?
You are right. I made a refactoring after this fix and that broke this feature Thanks for the diligence on this one!
To verify, use the steps from Make sure no snippets completions are ghost-texted with and that they are when the setting is set accordingly
I still cannot get snippet completions to show up
You need to say what you are trying because I do see them working just fine <img width="922" alt="Screenshot 2024-01-26 at 18 14 32" src=""
This works correctly for me now, no snippets with , and they do show up without it.
Bang on.


The whole point is that the -setting is honored also for ghost suggestions
: <img width="1792" alt="Screenshot 2024-01-26 at 9 19 47 AM" src=""
this is about ghost text, please see and the comment linked from there
there was a syntax error in my file, so the settings did not get applied. Now it works


Type: <bBug</ban image file from the VS Code explorer into a md file Bug No markdown image inserted, just the file name VS Code version: Code - Insiders 1.88.0-insider (Universal) (, 2024-03-29T22:24:49.191Z) OS version: Darwin arm64 23.4.0 Modes: <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Closing for verification.


Type something so that the suggest widget appears Once it appeared and an item is selected, press on the left arrow key The text in the suggest widget disappears There remains a black box with nothing inside where the widget was positioned
hm... doesn't reproduce for me. can you check devtools console for errors?
nvm - I can reproduce running out of sources
regression from
Hi sorry, I just saw your messages. I think I didn't receive the notifications because the tab with this issue was open in chrome, and notifications were not sent. Anyway thanks for looking into this.


I think the border should be thicker and the color should have more contrast. <img width="881" alt="image" src="https://user-"
I think the thicker border is a little too heavy but agree that the light themes in particular suffer from a contrast issue. Do you think it's as much of a problem on the dark themes?
It works much better on the dark themes (maybe also because my code-oss uses dark theme)
Ok, I'll propose some updates this week
Before Light: ! Before Dark: ! After Light: ! After Dark: !


When tabs are enabled, the close button is slightly larger and unbalances the tab. This button should be different than when tabs are disabled and the close button is moved to the editor toolbar. !


"Add" text in these screenshots. JSX ! HTML !
That's just how it it. All depends on what scopes the differents grammars (html: no scope), jsx: ) use and the decisions of the themes on what to colors. The workround is to use a theme that doesn't color , e.g. the default light theme.
fixed by , thanks


<!-- Do Not Delete This! bugreporttemplate --Version: 1.66.0 (system setup) Commit: Date: 2022-03-30T05:50:14.623Z Electron: 17.2.0 Chromium: 98.0.4758.109 16.13.0 V8: 9.8.177.11-electron.0 OS: Windows_NT x64 10.0. New "striped" gutter decorations were in . These decorations do not respect the existing SCM: Diff Decorations Gutter Width setting: Changing the above setting has no effect on the new decorations.
I think this was an oversight and have a PR that can help address this. Thanks!


Type: <bBug</bAfter updating to v1.76.0 command "Show Next Change" () no longer works. My file has uncommited changes that are highlighted in a bar to the left of the file, and when I press the shortcut or trigger the command manually from Command Palette I expect my cursor to move to a line with a change and a panel with a diff to appear (as it used to before the update). But nothing happens. ! I tried testing this with all extensions disabled and in VSCode Insiders v1.76.0, same there. VS Code version: Code 1.76.0 (, 2023-03-01T10:22:44.506Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (18)</summaryExtensionVersion ------ overtype0.2.0 pascal-language-basics0.1.10 vscode-django1.10.0 vscode-eslint2.4.0 xml2.5.1 gitlens13.3.1 hoogle-vscode0.0.7 language-haskell3.6.0 isort2022.8.0 python2023.4.0 vscode-pylance2023.3.10 jupyter2023.2. vscode-jupyter-cell-tags0.1.6 vscode-jupyter-slideshow0.1.5 remote-wsl0.76.1 block-travel0.0.2 selectline-statusbar0.0.2 haskero1.3.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Same for me, neither the nor work since upgrading. & seem unaffected, but I want to see the context of changes quickly without having to click the mouse or change switch editors.
I'm having this problem too.
Something seems to be pretty busted in 1.76.0. The Show Next Change (Alt-F3) and Show Previous Change (Shift-Alt-F3) commands do nothing. But worse, the Git: Revert Selected Ranges (Ctrl-K, Ctrl-R) command completely messes up my file.
I believe that this should be fixed in the latest Stable release,, so I will optimistically close the issue.


Please reopen it in case you are still able to reproduce the problem with the latest Stable release. Thanks!
Unfortunately cannot confirm, the shortcut and the command are still broken both in 1.76.2 and in 1.77.0-insider. I cannot reopen the issue but I hope someone else will.
could you please take a look and see if this could also be related to your changes? Thank you!
Glad to see this fixed; for me however the diff peek that opens seems to always show several lines above the current change. Are there settings that might affect this?
I'm not aware of any settings that would affect this. Do you see this behavior 100% of the time? If not, do you know if there are any specific steps that cause it to happen?
Just found out that it's probably the sticky scroll that's causing this. I disabled all my extensions and still managed to reproduce this. I didn't pay attention at first, but now that I think of it, most of the times it's happened, I've had a bunch of lines showing in the sticky scroll header. I have this in my settings: Tried disabling it (or just lowering the number of lines shown) and now the diff editor shows the difference correctly (albeit a bit towards the bottom). So maybe the diff editor should either account for the number of sticky scroll lines, or not show the sticky header at all.
thanks for following up with your findings. I agree that we shouldn't use stick scroll in the quick diff: there just isn't enough vertical space for it to make sense. I'll disable it.


Testing Have the following code in an notebook cell. Run the code Scroll the output. Notice as your scroll reaches the top you can continue scrolling and it will scroll the whole notebook file. This is unexpected and I think no other widget in VS Code behaves this way. I suggest instead the following strategy when scrolling: If a mouse is in the Cell then scrolling it will only scroll that cell. You can not scroll the large notebook while the mouse is in the cell. Same way you can not scroll the Cell with the mouse unless the mouse is in the cell IMHO this is what makes the current experience feel weird.
We don't often have nested scrollable elements in VS Code workbench and also this is how browsers handle nested scrolling. Current behavior feels right to me. I can see the value of scrolling only when the focus is inside/on the output, there is a catch with that though, users need to move cursor to outside of the cell output to scroll the notebook, and the hit area for that is very narrow most of the time.
Thanks for providing more info. But what other UI element scrolls like the notebook does right now - so that you can scroll the element until it hits the end, and then if you continue scrolling that the outer element starts scrolling? This really felt unnatural to me, but I might have missed this pattern in other parts of the workbench. Or what do other Notebooks products do in this case?
the peek view actually behaves this way. That's the only other nested scrollable element that I know of.
Thanks! If I am the only user that it complaining feel free to close this one as designed :)
I tried using notebook in VSCode again last week, and came to GitHub to open this exact issue. I feel this scroll is extremely unintuitive. Here's an example. A cell is outputting more lines than , so we're currently viewing it's last line. I want to scroll to top. I speed scroll up, but this reaches the top and keeps scrolling the notebook, so now I'm all the way up. I have to scroll back down to my cell. If I go fast, I might miss it. If I go slowly, some other cell's output might catch my scroll and scroll that to bottom, before the notebook scrolls again. Same happens to my cell.


I need to be frustratingly precise to scroll this output to the top. Here's a recording to illustrate (I hope you can see it, recorded on MacOS, encoded as AV1; can add YT link if not viewable here): It took me 15 seconds to manage to get that top. And I knew exactly what I wanted to achieve, for the sake of the video. Now here's the same experience in native Jupyter Notebook (exact same notebook and cell). First, I can easily toggle the output scrolling. If untoggled, the output scrolls natively with the notebook, and since it expands downwards, without the notebook jumping, I can immediately see the top, which is right next to the cell. Then I toggle the scrolling again, to illustrate the behaviour compared to VSCode. I initiate scrolling inside the output area, and so only that area is scrolled. No matter the speed, or direction, I can easily reach the top or bottom as many times as I need, without losing context of my notebook. If I do want to scroll the notebook, I need to scroll outside the output area. This is easy because the cell does not take the whole width. This is in relation to what said above: Yes, but the cell does not need to take the complete visible width. In native notebook, cell's width is limited, and there's still plenty of space for code. But even if the cell does take the entire width, the user can initiate the scrolling outside the output area, i.e. over a cell. In this case, it scrolls the notebook, and never the outputs. The outputs do not steal the scrolling from the notebook, like it happens in VSCode. So: scroll initiated on cell or outside the cells area -scrolls notebook only, never output scroll initated in scrollable output area -scrolls only that output area, never the notebook
should we reopen this? What do you think?
sure, that's a reasonable request. It would be inconsistent with how the peek view scroll works, but the possibility for many scrollable regions makes these cases more noticeable in notebooks. - one thing that might help - you can toggle output scrollability per output in vscode as well with , by default
I have the same issue.


The usability of the scrollable element suffers greatly due to the current crazy behavior - when the scrolling inertia reaches the end of the scrollable output and scrolls the whole notebook! If different users want different behavior, this can be an option in the settings, e.g.: current behavior behavior like in the native Jupyter Notebook (in the video above), i.e. the notebook never scrolls if the pointer is inside the scrollable element there may be a 3rd option: the scroll that reaches the end of scrollable area doesn't scroll the notebook, but the subsequent scrolls in the same direction (even if the mouse pointer is inside the scrollable area) - scroll the notebook
for verification, please check with a mouse wheel and scrolling with a trackpad, since they behave quite differently. Hitting the boundary of the inner scrollable region will prevent further scrolling for that same scroll action. After a short pause you should then be able to scroll the outer region since the inner region can't be scrolled any further. (similar behavior to a browser)
Verified on trackpad. Still have to verify with a mouse wheel.
verified on mouse! there was a pause/delay, but wonder if there should be a larger delay - I find that sometimes I spam scroll and it moved up a little quicker than I anticipated. if it matches browser tho, should be all good ~
hello , thank you a lot for the work on this issue! I hate to say this, but I think it's not solved: It looks like only a certain "scroll length" is ignored, and the rest of the scroll inertia is still applied. Here I do: one fast scroll (as you see, the notebook moves) then I scroll back down then one fast (a bit slower) scroll (the notebook moves) Only if the scroll isn't fast enough the "scroll length" will be small enough to be completely ignored. <br /Here I do: one long scroll - all the way until the end of the video: <br /The behavior in the native jupyter notebook is certainly different. Here I do: one fast scroll - different than in VSCode (the notebook doesn't move) one long scroll- different than in VSCode (the notebook doesn't move) one after-scroll (the notebook moves as expected) Could this issue please be re-opened?
which version of vscode was this on?


Version: 1.88.0 (Universal) Commit: Date: 2024-04-03T13:28:18.899Z (1 day ago) Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Darwin arm64 23.3.0
ok, yeah. looks like I broke the behavior with a related bugfix
Version: 1.89.0 - still isn't completely fixed: If I scroll hard enough, the notebook scrolls.


Testing edit keybindings leave out args or have an empty array of commands trigger the command, nothing happens. This is expected but I wonder if an information/guiding message should be shown that the keybinding needs some commands to be useful?


Pick up final TS 2.1.5 for the bundled version of TypeScript. Insiders version of TS 2.1.5 is already in VSCode 1.9 insiders


Testing I wonder how well it scales to show multiple tag icons, why not find a new icon that resembles multiple tags: !
I like that. Adding as that would require a new Codicon...
!
Or just show one tag in the row, but show all of them on hover like you do now.
How about showing one badge pert type (ex: branch, remote branch, tag) and a number indicating how many they are. That way there is no need create new icons that would cause further confusion.
I am actually not entirely sure what value there is to distinguish 1 tag from N tags? I would just show 1 icon if there is any tag.
Seems reasonable. Let's start with that and see how things go.


Type: <bBug</bIn the "Source Control Repositories" view, if you have several repos selected, and then right click on one of them and choose "Open in Integrated Terminal", it will open the terminal in the directory for the first selected repo regardless of which repo you right clicked on. However if you right click on a repo under "Source Control" then it will open the terminal correctly. VS Code version: Code 1.90.2 (, 2024-06-18T22:33:48.698Z) OS version: Linux x64 6.6.15-2rodete2-amd64 Modes: Remote OS version: Linux x64 6.6.15-2rodete2-amd64 <details<summarySystem Info</summary </details<details<summaryExtensions (22)</summaryExtensionVersion ------ jupyter-keymap1.1.2 remote-containers0.375.1 remote-ssh0.112.0 remote-ssh-edit0.86.0 vscode-remote-extensionpack0.25.0 remote-explorer0.4.3 remote-server1.5.2 rewrap1.16.3 githistory0.6.20 gitlens15.1.0 go0.41.4 debugpy2024.6.0 isort2023.10.1 pylint2023.10.1 python2024.10.0 jupyter2024.5.0 jupyter-keymap1.1.2 jupyter-renderers1.0.18 vscode-jupyter-cell-tags0.1.9 vscode-jupyter-slideshow0.1.6 preview-vscode2.3.7 code-spell-checker3.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.91.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Is that option being contributed by an extension? Please use the command to investigate.
The menu option is there even with no extensions loaded by "Start Extension Bisect"
<!-- UNABLETOLOCATECOMMITMESSAGE repo --Issue marked as unreleased but unable to locate closing commit in repo history.


If this was closed in a separate repo you can add the label directly, or comment .
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased


Hei! Found issue with folder delete operation. The point is, when you delete folder (first time), no matter how, via mouse or keyboard combination, then select another folder and try to delete it, you will get popup message saying "Cannot read property 'isDirectory' of undefined" Only when you select another folder again (second time), delete operation will be successful. Tried several times with same results. And as i remember, this bug i found some time ago, so it is not introduced exactly in last insiders build. Visual Code Insiders 1.41.0 from 2019-12-02, commit: macOS 10.15.1
thanks for filling this great issue. You should have the fix tommorrow in vscode insiders
the problem was that it was happening that the tree would sometimes set the trait on one element two times. In this particular case Selection would be set on the element A and A. So if I say tree.getSelection I would get the same item twice. Instead of the array with one item. I decided to fix this with a workaround on the trait level. Repro steps: set compact tree to true. Go up and down with the focus always ending up with the focus on the one select item. Put a conditional breakpoint tree will try to set the double selection trait
This seems to be coming from Where the selection would already contain the folder, but as oldSelection/oldFocus also has the id, it will push the same object to the selection again. You could also fix it there by doing some sort of duplicate filtering or selection.indexOf to prevent duplciates being I could reproduce it consistently by: Putting a breakpoint there Creating a new folder Focusing on that folder Result: The function ends up setting selection to contain the same object twice.
great pointer. I think you are right, give me a sec and I will push a better fix. Thanks a lot!
I was planning to submit something along the lines of But I'm not sure if this is considered good code, it might be better to create a set of Ids (like oldSelection) does, but as selection is of type T, I could not access the id parameter.
If you would like to create a PR you are more than welcome to! It would be great if you could do it today since we are wrapping up the milestone and we need this fix asap.


Just make sure to remove my wokraound introduced with Thanks! And make sure to ping me on the PR


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: stable and from sources Steps to Reproduce: server vscode in safari simple browser :bug: Observe icons don't load (icons load if disable Cross Origin Restrictions in develop menu is checked)
How are you running the server? I see the icons loading in but not on localhost using : ! This seems expected since Safari seems more strict about loading content from localhost in this case
Try codespaces, it repros there too. (For running the server I use ) It works on serverless (i.e. and ) because they are served in a different way I think
I'd also like to see it fixed. It's still reproducible on latest Safari version. <img width="290" alt="image" src="https://user-"
This definitely seems like a webkit bug but I can't put together a minimal repo. The issue is the the codicon font face doesn't go through the service worker during loading despite it's parent css file being loaded by it: ! I also tried debugging the production code in codespaces but Safari's dev tools are pretty much unusable with our minified service worker Instead, I'm going to push a change that inlines the font in the css file to hopefully work around this issue
Looks to be working in latest insiders !
<!-- 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


<!-- 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 developing an extension, I sometimes mess around with versions, e.g. install an (unpublished) extension with different content using the same version, or going back a version. It can happen then that I can install the extension (via file) successfully, the extension appears, I get the notification to reload VSCode which I accept, and the extension is gone after the reload. It does not load, and it does not appear in the list of installed extensions. There is no warning nor any trace in the extension host output pane. I recently figured out that this appears to be caused by an auto-generated entry in the file, listing the installed version of my extension. There might be a bug here, since it also lists the highest version ever installed. However, this feature request is about the lack of notifications why the extension is not loaded. I would appreciate if you could tell the user, e.g. via a warning during install and maybe during every load, that an extension has been blocked because it's obsolete. Furthermore I suggest listing the extension as installed in the extension pane, as deactivated/obsolete with a warning attached to it.
Can you please provide exact steps to reproduce this behaviour?
I did not mean this as a bug report, but rather as a request to add additional messages telling the user what's going on. However, I've tried to reproduce it and it seems you can get this issue if you do: a for some extension E in version 0.0.1 E in version 0.0.1 from vsix (I'm doing this on a remote machine using the Remote SSH extension). . a for E in version 0.0.2 E in version 0.0.2 that now contains an entry making E in version 0.0.1 obsolete . E in version 0.0.1 . that now contains both an entry making E in version 0.0.1 obsolete as well as version 0.0.2 obsolete. that the extension is not loaded. At this point, you can also install E in version 0.0.2 and it still won't load.
I am not seeing this behaviour.


When I install 0.0.1, .obsolete file now contains 0.0.2 version only.
Sorry for taking so long to answer. I've now taken a fresh VM (Ubuntu 22.04) and a new extension (, just modified the so it would package) and could reproduce it. No "Remote - SSH" involved either. The steps: Generate two versions of an extension, 0.0.1 and 0.0.2 Install VS Code. At this point, does not exist yet. Install 0.0.1 and reload. Install 0.0.2 and reload. This creates the file with a single entry . Install 0.0.1 and reload. The file now contains . The extension is not loaded and does not appear in the list of installed extensions. Even if you "only" end up with an entry for version 0.0.2, this would still probably cause an issue if you try to re-install 0.0.2 since there are no diagnostics emitted - neither during installation nor during startup.
Ok there is a bug at the last step - Installing 0.0.1 shall not add 0.0.1 to the file. This bug happens only when the has no set. Can you please set the property in the and retry?
To verify: Formulate an extension without property in Generate a VSIX 0.0.1 with version Generate a VSIX 0.0.2 with version Install VSIX 0.0.1 and make sure 0.0.1 version is installed Install VSIX 0.0.2 and make sure 0.0.2 version is installed Again Install VSIX 0.0.1 and make sure 0.0.1 version is installed


the Settings editor. Notice the "Editor: Tab Size" setting has a link. over the link. :bug: There's no underline text decoration, and the cursor doesn't become a pointer.


Type: <bBug</bWhen I commit from the git extension, I frequently get an error message that "Git: Extention '' CANNOT use API proposal: telemetry". When I look at "Running Extensions", git reports 32 uncaught errors. I do not know if the two error counts are related. This only recently started happening (last couple of weeks). VS Code version: Code 1.85.1 (, 2023-12-13T09:49:37.021Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 5.15.90.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (13)</summaryExtensionVersion ------ remote-containers0.327.0 remote-wsl0.81.8 rewrap1.16.3 markdown-table-prettify3.6.0 vscode-markdownlint0.53.0 git-graph1.30.0 python2023.22.1 vscode-pylance2023.12.1 cmake-tools1.16.32 cpptools1.18.5 rewrap1.16.3 cmake0.0.17 markdown-all-in-one3.6.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
/gifPlease
Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, files are preferred as they are displayed inline on GitHub. You may find helpful as a browser-based gif recording tool. If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording ( in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue. Happy coding!
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Here's an example of the ruling.
This bug is still active. I can't get rid of the problem.


My version of VSCode is: Versión: 1.85.2 (user setup) Confirmar: Fecha: 2024-01-18T06:40:10.514Z Electron: 25.9.7 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 SO: Windows_NT x64 10.0.
are you able to reproduce this issue every time you try to commit? When the error occurs, could you open the developer console using the "Developer: Toggle Developer Tools" command and share all the errors/warnings in there? Are you able to reproduce this issue with all the extensions disabled? Thanks!
Yes, every time I commit I have this problem. ! ! I only have 3 extensions, I disable them and the same problem occurs. ! Sorry for my English. I don't know if you mean this. But it's what I see when I open Toogle developer tools.
still getting it too. I have dozens of git repositories across multiple versions of git (development containers with different Linux versions, Windows, etc.) Happens frequently, but not always, but does seem to happen consistently on some repositories and not others.
thank you! After you reproduce the problem, could you also please send me the contents of ? Also, are you able to reproduce this issue with all extensions disabled? The easiest way to try this is to use the "Help: Troubleshoot Issue..." command from the command palette.
It seems that way. Thank you
Ok. First i delete output of git. ! After. I disable all extensions. ! After. I can one time more to make commit. ! New commit ! After commit ! Git output complet: 2024-02-01 10:24:20.195 [info] No remotes found in the git config file.


2024-02-01 10:24:20.244 [info] git config --get commit.template [54ms] 2024-02-01 10:24:20.244 [info] git for-each-ref --format %(refname) %(objectname) %(objectname) refs/tags [49ms] 2024-02-01 10:24:20.286 [info] git status -z -uall [39ms] 2024-02-01 10:26:19.989 [info] git add -A -- . [56ms] 2024-02-01 10:26:20.264 [info] git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file - [269ms] 2024-02-01 10:26:20.308 [info] git config --get commit.template [39ms] 2024-02-01 10:26:20.317 [info] No remotes found in the git config file. 2024-02-01 10:26:20.364 [info] git config --get commit.template [49ms] 2024-02-01 10:26:20.372 [info] git for-each-ref --format %(refname) %(objectname) %(objectname) refs/tags [49ms] 2024-02-01 10:26:20.413 [info] git status -z -uall [38ms] 2024-02-01 10:26:20.480 [info] No remotes found in the git config file.


2024-02-01 10:26:20.528 [info] git config --get commit.template [51ms] 2024-02-01 10:26:20.533 [info] git for-each-ref --format %(refname) %(objectname) %(*objectname) refs/tags [54ms] 2024-02-01 10:26:20.579 [info] git status -z -uall [40ms] 2024-02-01 10:26:41.809 [info] git ls-files --stage -- C:UserssriccOneDrive - ICCADocumentosAngularSergieCodecargaPaginasAppsrcappcontacto [49ms] 2024-02-01 10:26:41.859 [info] git cat-file -s [43ms] 2024-02-01 10:26:41.908 [info] git show --textconv [42ms] I hope it's everything you've asked for.
SOLVED For me, I found out it was because I was on a detached head on Git. For some reason, reattaching to master solved it.
Thank you! I have to admit that it's not clear to me what is happening here. Let me chat with my colleagues and see if I can come up with an action plan.
+1 for gilad905's suggestion. I was able to easily repro the problem: new repo from command line. first commit. out main and commit from git source-control panel in vscode, works. out the new head (the second commit), detached. another change and try to commit it in vs code Expected: It works correctly Actual: The commit is created in the repository, but the "telemetry" error message shown above appears.
Thanks Fix for this will be in Monday's VS Code Insiders release. Apologies for the inconvenience!
thanks
I am not, and have not been using repos. Sorry this is not the only problem occuring.
please share your repro steps in case you are able to reproduce with the latest VS Code Insiders release. Thanks!


Steps that should work but don't (these will be verification steps): PowerShell for macOS if you don't have it what path was to () it as your default shell: VS Code from the dock/finder a workspace with the below task the task Actual Expected Something like: This is because we fail to get the UnixShellEnvironment. You can confirm this by looking in output, you should see:
another great verification step is replacing the command in the task and putting something like or . This will likely fail saying it couldn't find the command ... because the environment wasn't set up properly.
I'm still getting the actual output instead of the expected output when I repeated the verification steps on my Mac.


<img width="377" alt="image" src=""
Verification step- just use a variable in a multiroot workspace, and check that you have the right blue background when it's rendered in the request.
Works great. Slightly related - why do we just render the blue background while I am typing the request, but do not render it blue when the request is sent. This was always the behaviour and is unrelated to MR workspace. I am just curious !
If it was used correctly, it will have the blue background. Did you pick the file from the picker, or just type the text?
Picked from file picker.
Oh no!
Apparently I didn't test this as thoroughly as I should have. Some files now break the markdown link. Need to rework this in main for debt week but there is an easy fix for now.
For verification, we should test with Files in a multiroot workspace In single folder window Files at the top level of the workspace And under a folder
Since the PR has been merged yesterday, this issue will be closed, for verification.


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --I found that once the [Activity Bar Position] is set to [Top], i can't find the activity bar at the top anymore, when i click [File-New Window] to open a new window. Therefore, i suggest display the activity bar by default when opening a new window.
<img width="1068" alt="" src=""As shown in the picture, the new window does not display the activity bar.
I like this idea, I will look into it.


Testing Just a small change. Believe the casing is off in the hover hint for the button. When going to a running cell it's "Go To.." and in the new error command its "Go to..." with the rest all caps. I believe the "to" should be "To."
The convention for commands is to use "Go to...." lowercase "to". !
Got it. I was basing it off of seeing this for the other Go to cell command. So is the bug on that text instead? <img width="191" alt="image" src="https://user-"
I think "Go To", both words capitalized, is good to match the other notebook titlebar casing (for example "Run All"). Using simply "Go" in the titlebar might be ambiguous and people would confuse it with "Run". The hover in the image above, should be "Go to Running Cell"
just checking, but would be proper fix for this to change the casing in "Go To Running Cell" to "Go to Running Cell"?


Testing Links to overridden settings (here is shows as Modified in User) to show as links nor are they affected by the setting. !
As in, they don't use the typical link color? is that intentional? Agreed that they should pick up the setting, in any case.
Here's how it would look ! !
I don't remember whether it was on purpose in order to not make the link stand out too much. I'm alright with changing the colour of the link and keeping the underline for improved accessibility.
Agreed. Merged the change and we can tune it from there if needed.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.86.2 (system setup) OS Version: Windows 11 (Windows_NT x64 10.0.) Steps to Reproduce: the built-in extension "CSS Language Features", which has an identifier of settings, search for "hex color length" See that it says "Hex colors must consist of three or six hex numbers." when it should say "Hex colors must consist of three, four, six, or eight hex numbers." to accommodate the alpha channel. The extension already allows for all four lengths, but the setting description is wrong.


going to keep track of examples here to see if there's a pattern <img width="1112" alt="Screenshot 2023-01-23 at 2 12 18 PM" src="https://user-"
far right terminal <img width="1120" alt="Screenshot 2023-01-23 at 3 07 17 PM" src="https://user-"
middle terminal !
far right terminal !
far right terminal <img width="1076" alt="Screenshot 2023-01-24 at 1 59 40 PM" src="https://user-"
right terminal <img width="1644" alt="Screenshot 2023-01-24 at 2 22 27 PM" src="https://user-"
right terminal !
here are the lines when there's not a quick fix result - it contains after which we don't account for here !
Seeing this frequently: <img width="726" alt="image" src="https://user-"
I think we just need to include the to fix this
or better yet, remove and just look for the link
ok I see the issue. when lines are wrapped a lot, we need to search more lines - setting the length to 10/15 fixes it even when the terminal is quite narrow
I see it on non-wrapped lines, I'm not sure I understand what you mean with the To?
The to comment above was actually wrong. What's happened in the screen shot above is we abort the search early - after looking at only 5 lines. When it's actually on line 9
this goes wrong when we break before reaching the content IE when line count length
I tried pushing up a new branch using pwsh in the integrated terminal on Windows, and the lightbulb did not show. !
you have shell integration disabled, it won't work at all there.
also make sure to not move issues to the next milestone, this one was marked important
Working much better now, but just reproduced !
Just happened and captured the trace log (escape sequence log would be better): <img width="806" alt="image" src="https://user-"
I've seen this not work twice today already for create PR !
even though the lightbulb didn't appear here, there was a match found !


the match always happens, the lightbulb doesn't show up though until I resize the terminal
this happens when the have not yet been resolved by the time occurs ! !
I think we should be calling at the end of
have seen the create PR not show up 3 times today. resizing doesn't cause it to show up, which means our match range is wrong/ there isn't a match
this says unreleased, but was merged before the current version of insider's (5 hours ago) was released. create with PR still failing !
insider's is based on the release branch, so I was confused
<!-- UNABLETOLOCATECOMMITMESSAGE issue --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased


start inline chat in the content widget author multiple lines :bug: the widget's height doesn't change
still kind of running into this kinda - height changes, but the prompt layout after querying is unreadable since there's only one or 2 line height worth of space also, seems like there is a weird horizontal scroll element on the bottom left of the widget?
I see. This is because the height of the zone is limited by the overall height of the editor. It doesn't want to take more than 42% - that's something we can tweak but you might be facing a bit of a special case having a multiturn convo and accessibility viewer enabled as well.
The first prompt handles a long string nicely. A long string for the follow-up prompt results in content overflow. !


Testing For this issue I used a notebook with one cell that contains the following code: <details<summaryfile </summarydata= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) </details- Stage this code Make a change Open the diff view in the SCM pane Open the metadata view Type into the metadata view The metadata view closes before anything can be typed Is this expected?


Would be great to see a tooltip on links, showing the target. Or popping it up in the status bar or elsewhere, like Chrome.
: Could you please explain the preview functionality bit more with screenshots of Chrome? I am new to open source community and this project. I use vscode often and would love to work on this if someone can guide me a little.
Lower left corner of the Chrome window when I hover the link to your name: ! But I think a normal tooltip would be easier.
Ah yes. I understand what you are talking about now. To verify, where the link is leading to. Seems like a beginner friendly feature. I can pick it up this weekend if anyone can nudge me towards the right direction. :)
Sorry for the delayed response. It seems that tooltips are only shown if the element has a attribute, but not for links that only have a . I wasn't able to find if there is an electron setting to enable tooltips for links without . I think we may have to implement this ourselves. To get started, take a look at this PR that a similar feature to another electron app: Here's where our webview code lives: I believe you should be able to attach a handler to the webview handler. Please let me know if you have any questions about the code or want to discuss potential designs
I m happy to receive help! :) I was facing issues while trying to build and fiddle around with the source code. Will definitely look into this PR and the code you pointed out this weekend. Thanks for taking your time to post this info. I ll post any questions or designs which I have.
Hi , I will create a PR to add attribute to every .
For verification: this was implemented as tooltip when you hover over links in a webview


Testing Not sure if actually caused by welcome page bug In dev tools, see:
I can't repro this on my mac. Please feel free to reopen this issue if you see this again on your machine.
Yes I still see this every time I open the welcome page. Maybe it's because of an extension I have installed that is getting parsed oddly or an experiment? The exception is thrown here:


VSCode Version: Code 1.18.1 (, 2017-11-16T18:32:36.023Z) OS Version: Windows_NT x64 10.0. Extensions: none Git Bash is not included in the list of defaults if Git Bash is installed as the current user. However, adding the path manually to the user settings works just fine. eg. Steps to Reproduce: sure Git Bash isn't already installed the latest version from https://git- as current user to ~AppDataLocalProgramsGit


! quick search. over a file name pick item and click the button to open the file. happens :bug:


Issue Type: <bBug</bI am not sure if this was something I accidentally enabled, but it looks like it appeared with the latest VSCode version. Hovering over lines now shows a + symbol in the gutter, and it's highly distracting. Is this a bug, or can it be disabled? VS Code version: Code 1.67.0 (, 2022-05-04T12:06:02.889Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ vsc-material-theme33.2.0 vsc-material-theme-icons1.2.2 prettier-vscode9.5.0 copilot1.19.5865 gc-excelviewer4.2.54 vsliveshare1.0.5561 material-theme3.13.25 (5 theme extensions excluded) </details<!-- generated by issue reporter --
https://user-
The "+" on line hover indicates that you can leave an extension comment on that line. We used to only show the "+" when you hovered over the gutter itself, but now we show it over the whole line so that it's easier to find. This means that you have an extension installed that let's you leave comments in files. The extension might have a way for you to disable this. I would like to add a feature to VS Code that just disables all commenting. Assigning to June to work on this.
great to know, thank you. i'll see if I can figure out what the extension is and will disable it in the meantime. it's very distracting - can you consider an option that preserves the old symbol behavior where it is only displayed when hovering in the gutter? comments are useful but there is now too much distracting movement on screen. it also shows in Zen mode which I believe is counter productive.
Good point, this should be disabled in Zen mode.
Bit more thoughts on this: Maybe a setting wouldn't be the right fit for this, since a user might forget that it set it and forget about it... or worse, it could be set at workspace level and the user never even knew it was set. Maybe runtime UI state would work best since it isn't as sticky.


Additionally, it would be great if there is some indication that comments are indeed hidden as opposed to the current file not having any comments at all. What do you think?
Having some indication that there are comments, they're just hidden, makes sense. We should do this. We can start with some runtime UI state and add a setting later if there's a desire for it.


down in the button, then move outside the button and mouse up You get this border: ! Weirdly enough that's not the same border you get when tabbing onto the button: !
Weird, by performing this gesture you get to focus the inside the button itself. Will see what the best fix is.
It's a bug in the as it does not happen with the "Publish Branch" or "Commit" buttons.


VSCode Version: 1.0 OS Version: OS X 10.11.4 I just upgraded my VSCode to 1.0 release. Since it supports Traditional Chinese now, my default language was set to so that some of comments in the newly config file is in Chinese. As you can see in the following screenshot, a Chinese character "", which is equivalent to the period "." in English, was matched as part of valid URL, and it caused VSCode direct to a incorrect URL. ! I have a working fix for this issue, the naive solution is to check if in is greater than 128, which means a non-ASCII character. Why to match only ASCII character? Because when you copy a URL from most of web browsers to clipboard, it will be automatically converted into ASCII-only string. Also, I came up with another idea to modify the to let it cache all the result of ASCII characters (0~127). In this way, we only need to modify the default case of the switch clause in the state machine. Which solution is more preferable? Please give me some advice then I can submit the patch ASAP.


I don't think the state of walkthrough progress is synced between machines, so I see this on each new machine I setup: !
Again, we do try to sync the state but there may be a race where it's not available in time. I'll investigate more..
Fixed it by adding the context to the installation event when extensions are synced by settings sync. Walk through component shall simply ignore walk through for those extensions which are installed by settings sync (irrespective of the walk through state is synced or not).


Issue Type: <bBug</bIn VSC, load a small image, zoom in a lot, close the image. Resize the small image by 10 times. In VSC, load the resized image. VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ Bookmarks10.4.3 npm-intellisense1.3.0 vscode-eslint1.8.2 githistory0.4.6 EditorConfig0.13.0 rainbow-csv1.0.0 dotenv1.0.1 vscode-typescript-tslint-plugin1.0.0 vetur0.19.2 github-actions-vscode2.6.1 rust0.6.1 RustyCode0.19.1 vscode-hexdump1.7.2 sort-lines1.8.0 markdown-all-in-one2.3.1 (1 theme extensions excluded) </details<!-- generated by issue reporter --
I would like to take this. I think we can store more information in . In my opinion, we can add the size or add the SHA1 value of the image? Do you have any suggestions?
can i work on this?
i didn't know that already started working on this, both prs work. as far as mine considered, i'm resetting scale to 1.
I'm sorry that I didn't reply to you immediately. Do you reset the scale every time you close the image? It makes the editor cannot remember the scale and offset even the image isn't modified.
yes you are write. let me close mine. :+1:


VSCode Version: 1.27.1 OS Version: Windows 10 (Build ) Steps to Reproduce: a simple (build) task setting presentation.showReuseMessage to false the task a blank line where the reuse message used to show up, instead of no extra line displayed at all Does this issue occur when all extensions are disabled?: Yes I was expecting this setting to reduce the overall lines printed by running the task, but all it does is prints an empty line instead of removing the line completely.
Able to reproduce.
I currently set . I can't simply set it to false since this would close the terminal. Any advice how to avoid the blank line?
I guess you want to pass in and handle it here:
OK. I will change the code as follows: if waitOnExit is a boolean honor it and never print a message if it is a string wait and print the provided message. Is this OK for you ?


Testing !
I just noticed that is not localized and is not meant for display. That means that "Label" was not a good name for that function, but we can either just remove the state or find the code that drives the state label in the callstack.
Actually, it seems that only displays , , or , which is probably not super useful to the user anyways. It seems like the info like is only available on each thread, and a debug session can have multiple threads. Perhaps we should just remove the state for now.


Type: <bBug</ba git repository on a UNC path the folder in VS Code the repository as safe ! repositories will be shown instead of one. ! The issue is ephemeral and only one repo shows after reloading the window. ! VS Code version: Code 1.84.2 (, 2023-11-09T10:51:52.184Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ 2sxc0.0.1 vscode-tailwindcss0.10.3 dart-code3.76.1 flutter3.76.0 xml2.5.1 batch-rename-extension0.0.6 csdevkit1.0.14 csharp2.10.28 vscode-dotnet-runtime2.0.0 vscodeintellicode-csharp0.1.26 python2023.20.0 vscode-pylance2023.11.10 remote-ssh0.107.0 remote-ssh-edit0.86.0 remote-explorer0.4.1 sqltools0.28.0 postman-for-vscode0.13.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
are you able to reproduce the issue with the latest ? I went through the steps, but in my case only one repository is being shown. If you are able to reproduce with the latest VS Code Insiders release, could you please go through the steps up until the point where two repositories are shown and share the contents of ? Thanks!
<!-- 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!


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --Steps to Reproduce: a vscode extension repository (e.g. ) to contributes commands (e.g. ). "command" and observe the tooltip <img width="857" alt="Screen Shot 2020-09-05 at 21 07 16" src="https://user-"<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Does this issue occur on Insider?: Yes