jiebi/CodeConvo huggingface dataset:
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: !
<!-- 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 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.
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.
<!-- 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.
<!-- 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
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.