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 into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.


has indicated that the diff inserted / modified audio cues are hard to differentiate and that the sounds are not as fast / singular toned as they should be
what do you think of this?
I agree with the suggestion. At least for me it is very difficult to identify the difference between the sounds used.
Sounds good -- will start on this asap.
I don't hear the cues as often anymore. I also noticed that when using up/down keys on the right diff editor, no audio cue shows up for a deleted section. Example with .gitignore file: Left: Right:
I can reproduce
it's getting to the line I expect it to (see logs) but no sound is produced - thoughts? 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.75.1 OS Version: macOS 13 Steps to Reproduce: the following settings to : suggestions still show up: <img width="766" alt="image" src="https://user-"
what you are looking at is the hover. to disable that use this setting
Hi, I want to remove the three dots, disabling hovering doesn't help, these two settings , now they don't, a recent update broke that, please reopen this and take a look .
Oh, you mean "hint" diagnostics. Forwarding to for comment
Thanks for fowarding, I got the term from the : !


With new API type was but that type isn't used anywhere and looks like a leftover. We should remove it before releasing stable.
fyi
My bad, I must have it and forgot to remove it.
Thanks for the quick turnaround


With Dark High Contrast theme, everything is clear except for warning and errors... Error is shown with an orange x: ! While warnings are exclamation mark in blaring red: ! I mean there's no two ways about it... RED is error, RED+certain amount of yellow(orange is fine) is warning.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.76.0 OS Version: macOS 11.6.2 Version: 1.76.0 Commit: Date: 2023-03-01T10:23:45.993Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin x64 20.6.0 Sandboxed: No Summary When creating a profile with a name such as "Typescript / Javascript", the following happens: When exporting as a Gist, no result dialog shows ("there was trouble" / "created profile successfully") and a validation error is outputted in the logs When exporting to a local file, the text after the last forward slash is set as the filename. With the above example, it'd be " " To reproduce: a profile: Settings cog -"Profile ([...])" the profile: Select "Export Profile..." -"Export" the "name the profile" step, enter a name with a forward slash in like so: "Typescript / Javascript" either method for exporting: gist or local Expected results: If you select local: a system save prompt with the name you entered pre-set in the filename field If you select gist: A success dialog with a link to the website prefilled with your config Actual results: If you select local: only the text after the last forward slash is in the filename field If you select gist: No dialog shows. The following error is in the "output" window, under "Window": I can only test this on a macOS device, I haven't tried this on a Windows or other Linux device and I feel like (with the area in mind - filesystems etc) these issues could manifest differently or not even be an issue there. I'm assuming validation on the inputbox for the name will be required because filesystems (and Gist? not sure) don't typically support forward slashes in file names. Thanks and if you're reading this, have a great weekend :)
Gists do no accept in the name. Replaced with .


When fails to get a mac address it still returns a generated mac id, but uses to log the error. That's a bit risky as it rely on VS Code to already have installed a . The default handler throws an exception in a timeout that can crash the process. (see issue ) IMO the better way would be to pass a logger to , e.g. the -move to -add to
if you support the idea I can provide a PR
that all sounds fine to me, thanks for looking into this. I didn't know this could cause a crash since it had been in desktop for so long.


<!-- 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. --Is it possible to have a setting that would automatically replace the local tags rather than always prompting? Thx
Even, I am also looking for a similar functionality.
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
+1
We are now "moving" a tag to track the last successful build in our CI/CD process for users who don't have a lot of CI/CD or Git experience. We want them to naturally see the tag slide up as the team makes changes and the server succeeds in processing them. It's very jarring to have this modal pop up and have no way of hiding it.
Tomorrow's (2024-02-14) VS Code Insiders release has an updated dialog that has an "Always Replace Local Tag(s)" button. Pressing the button will toggle the so if you wish you can proactively enable this setting in your users/workspace/folder settings. Please give it a try and let me know if you run into any issues. Thanks! <img width="265" alt="image" src=""


Look at telemetry and if not a lot of users are using the Install and Do not Sync extension action remove the action to simplify the Extension Install flow. is the action name. fyi
Ok was run on 59K distinct machines. For comparison extensionGallery:install was executed on 10.4M machines. So Do not Sync is used in 0.5% of cases. I think it is fine if we remove it - we keep it somewhere but not so prominent. what do you think?
Any suggestions?
We already have the "Sync Extension" check in the Extension context menu when it is installed - this is great. ! And we already have the "Sync Extension" check in the same context menu when it is not installed. Just currently if I click this, there is no effect. So ideally the experience would be that I can uncheck this before installing the extension. And thus we need no new actions. !
Lets try this in insiders already and see if we get any hit back.
Awesome - thanks!


repro: in settings notebook search filter to look at outputs all editors for something that only appears in outputs on the result and wait for the results to convert to rich notebook results list focus has shifted !
Hi - I'm attempting to replicate this bug, but cannot generate the output from a notebook because my build (Code - OSS Dev) crashes when I select a kernel for my notebook with the message . I am getting the extension form How were you able to get the Jupyter notebook running in your build?
I installed the Jupyter extension via the vsix that is in the marketplace install page.
Thank you for the reply! I still run into the same error after installing the extensions from vsix when I select the kernel. Console output
Hmm, I'm not sure why this would happen. Since this is not really related to this issue directly, could you file a new issue?
I believe the issue is related to this line in folderMatch.allDownstreamFileMatches() is returning a set of notebook files that excludes the parent file of the current selection.


a notebook and run a cell that produces an output long enough to scroll, e.g within the output element :bug: the output element scrolls to the top to select the first link


Testing Up / down, go to top / bottom always targets the editor's scroll position, not the cell's scroll position. (Related: )
It actually only navigates the input cells. I can then tab into the input cell, but not the output cell. I think for accessibility there would have to be a way to focus the output cell, so that can be scrolled too?
I also see this, page up/down, ctrl+home/end act strangely
We didn't update when clauses for arrow keys and page down/ups so when the focus is inside the scrollable output, it scrolls both the output and the editor.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.76.2 Commit: Date: 2023-03-14T17:57:21.103Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Linux x64 5.19.0-38-generic Sandboxed: No Steps to Reproduce: a git diff view and delete one of the lines. the right pointing arrow in the diff view. https://user-
I cannot reproduce this. Do you see any errors in developer tools? Does this reproduce with any file and with any change or is it specific to this particular file? https://user-
I can't reproduce it anymore either. I just updated to 1.77.0. Maybe it just happened to get fixed in that version? I can still reproduce though.
Hmm no I can still reproduce it in 1.77.0.
Found it! Seems like the issue only occurs after line 99
Hmm and another requirement is that the file has 1000 lines in total or more I think.
I cannot reproduce. I tried with a file which has 1353 lines and I do an edit at line 600. Do you see any errors in Developer Tools (Help Toggle Developer Tools)? https://user-
I don't think the devtools console contains anything of interest: WARN Via '' extension 'ms-' wants API proposal 'contribEditorGutterMenu' but that proposal DOES NOT EXIST. Likely, the proposal has been finalized (check '') or was abandoned. WARN Via '' extension '' wants API proposal 'contribEditorGutterMenu' but that proposal DOES NOT EXIST. Likely, the proposal has been finalized (check '') or was abandoned. WARN Via '' extension 'ms-toolsai.jupyter' wants API proposal 'notebookControllerKind' but that proposal DOES NOT EXIST. Likely, the proposal has been finalized (check '') or was abandoned. ERR Extension 'github.copilot-nightly' appears in but enables LESS API proposals than the extension wants. (LOSES): inlineCompletionsAdditions, interactive (WINS): inlineCompletionsAdditions INFO [perf] Render performance baseline is 62ms I've found that the line 100 rule doesn't completely hold for me either, when make the right panel very big it becomes clickable again.
So far my hypothesis is that you need a long word wrapped line above the one you're trying to reset. But honestly I'm not sure anymore at this point. https://user-
Hooray, this reproduces when using word wrapping! The root cause is that some properties on the mouse event are not converted from view coordinates to model coordinates. This reproduces with the following word wrapped .txt file:
Seems like I can still reproduce (with and w/o word-wrapping): https://user- https://user-
I ran git bisect and I had to skip a few commits due to build problems, but I believe this is caused by The first bad commit could be any of:
So merging the PR will make the arrows work but will also bring back the issue of also setting breakpoints? That is unfortunate but I think I'd rather have the arrows working.
:+1: I think it's better to go back to the state we had in 1.77 and the risk is minimal as it is a simple revert.


It seems the extension's raw is used for the text here. To combat this I had to restate my extension's name in the extension description, which probably isn't the desired approach. I think ideally the extension name would be featured prominently, and the extension description would be below it or something. <img width="1040" alt="image" src="https://user-"<img width="777" alt="image" src="https://user-"Demo:


Type: <bBug</bdark v2 theme files from the explorer and drag then in to an editor bug There's no background to the dragged element label so it blends into the editor text ! VS Code version: Code - Insiders 1.78.0-insider (Universal) (, 2023-04-17T12:50:42.586Z) OS version: Darwin x64 22.4.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (51)</summaryExtensionVersion ------ tsl-problem-matcher0.6.2 comment-tagged-templates0.3.2 docs-view0.0.11 emojisense0.9.1 folder-source-actions0.2.1 markdown-mermaid1.18.1 vscode-eslint2.4.0 kusto0.4.3 typescript-notebook2.0.6 EditorConfig0.16.4 codespaces1.14.5 copilot-nightly1.82.24 vscode-pull-request-github0.63. vscode-drawio1.6.6 vscode-postfix-ts1.12.1 search-editor-apply-changes0.1.1 latex-workshop9.8.2 vscode-tree-sitter-query0.0.1 vscode-position1.1.2 template-string-converter0.6.1 vscode-docker1.25.0 vscode-language-pack-de1.77. vscode-language-pack-zh-hans1.77. isort2023.9. python2023.7. vscode-pylance2023.4.21 jupyter2023.4. jupyter-keymap1.1.0 jupyter-renderers1.0.15 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.290.0 remote-ssh0.101. remote-ssh-edit0.84.0 azure-account0.11.3 cpptools1.15.2 hexeditor1.9.11 js-debug-nightly2023.4.1317 live-server0.5. remote-explorer0.5. remote-server1.1. test-adapter-converter0.1.7 vscode-github-issue-notebooks0.0.128 vscode-js-profile-flame1.0.5 vscode-marketplace-extension-browser0.0.7 vsliveshare1.0.5857 code-spell-checker2.20.4 ayu1.0.5 luna-paint0.16.0 sort-lines1.9.1 fast-arrow1.0.8 (2 theme extensions excluded) </details<!-- generated by issue reporter --
I believe the background normally comes from this line:


This throws the exception below. This happens when logging objects without prototypes, e.g . Instead of the property access should be used


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


Testing !
Looking through the code, it seems that it comes from returning multiple from my for the search editor. The problem is with the functionality that allows certain lines to be underlined for mouse definition hover. Instead of underlining the lines individually, it underlines the whole range starting with the start of the first range and ends at the end of the last range. cc
I think the underlines are by the go to definition feature and not by the link provider. Do you think the API is used incorrectly or is there an issue on the UI side?
The UI receives two locations for the definition request. To draw the underline it merges both into a combined range. Looks like it doesn't check if the origin ranges actually contains the position at which the request has been made - I am unsure if that's on purpose or not. So, there might be something in the UI side to fix but the extension also return bogous data. It looks like it return all results when being asks for the definition . That's not how it is intended to work and either a the file itself should be used or no definition should be provided <img width="1461" alt="Screenshot 2023-06-13 at 15 32 19" src=""
I'm not sure if I understand this correctly. What is the position at which the request had been made and what would be wrong with this being the origin? Makes sense. I haven't actually editing anything in this extension before, so I'll take another look at what was intended when it was first implemented.
I'm taking another look at this and I have a few questions about the API. I think that the original intention of using a definition provider was this: so that double-clicking the filename in the search editor would pop up references to the code snippets that are directly below it. Given this, I'm wondering: If I want multiple references listed like this, do I get the provider to return more than one and they would all have the same ? What is the difference between the and ? I read the docs and I don't know the difference between the full target range and the span.
The has two ends - the origin at which it starts and its target to where it goes. The origin defaults to the word at the current position (cursor) but can be refined if that isn't good enough. The two target ranges are the whole target and its focal point, think of a function where the whole function (comment, signature, body) is and its name is - when navigation a definition link the cursor is placed at the target selection range but the whole targetRange is reveal and/or highlighted etc.


<!-- 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. --. However, it is very long and explicit and thus decreases readability: I would like to request a new variable, , that would be its shorter alias that also stands out visually due to no alphanumeric characters: This is inspired by .
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
<!-- -c9e0-7adb-d31b- --:slightlysmilingface: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our . Happy Coding!


Testing I'm not clear on what unforwarding a port means so this maybe expected, but we do detect that the process is no longer running but it still appears in the list: !
can you please provide the steps you used to get here? If port forwarding is properly set (setting + reload) then yes, the port should be unforwarded and no longer appear in the list.
Run the above Python script in integrated terminal when using Remote-SSH, it should start appearing in the list along with process ID under "Running process" column. Kill process using in a separate terminal.
Also confirming I made sure this was done as well.
Thank you for the steps!
When verifying, please test that the port is unforwarded with both and are used.
The port is not unforwarded when is used. It is however unforwarded when is used. I'm testing with the vscode-remote-try-node repo and the default launch config.
The fix works for me though, with the original Python script I provided.
I'm not able to reproduce this. It's possible for what you describe to occur if the process is terminated before we have a chance notice that it's running. If you see this again can you please set the log level to debug, repro, and share logs from Remote Extension Host and Window? Closing again for testing.
I am unable to reproduce the issue with vscode-remote-try-node on Codespaces or Dev Containers, though it did take a bit longer for the port to close on Codespaces. Marking as verified.


<!-- 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. --Codespaces Visual Studio Code - Insiders Version: 1.78.0-insider Commit: Date: 2023-05-02T11:17:01.989Z (10 hrs ago) Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36 Edg/112.0.1722.68 Steps to Reproduce: a GitHub Codespace from an existing repo the "Developer: Set Log Level..." command and set it to "Trace" there's no "Telemetry" channel there, only Extension Telemetry: !
Do you have any ideas I assume there would be nothing special needing to be done for codespaces, I register this output channel the same as the extension one and the same as the other output channels.
Where do you register Telemetry logger in codespaces, is it in server or on client side?
It's registered client side.
May I know where it is registered in sources?
Can you please check if this code is being executed in the codespace?
It seems to be missing from web too. I can confirm when debugging the web bits locally it is called and registered, but nothing shows up in the output channel list.
Can you please provide me steps to enable this locally from sources?
Sent instructions offline
Still not seeing the telemetry output channel in Codespaces (on desktop if it matters)
Actually this is a bug in web, but I can confirm that this is working for me in both web and desktop. Wondering if you have any additional steps to repro.


Type a multiline commit message Scroll away Scroll back When the row gets rerendered (I assume) it is sized to one line. If I type a newline in this box, the size gets fixed !
Possibly a regression introduced with


Just saw , this goes against the design. It's meant to only add the status if it doesn't already exist, if the status changed then it should use a different id and/or remove the old status first.
I'm not clear on the solution. There're a limited number of Terminal Status IDs: In this case status ID hasn't changed, it's still , only the description which comes with it has updated.
working on it, I'll send a PR to you in a bit
Validate still doesn't happen.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.78.1 (system setup) Commit: Date: 2023-05-04T09:48:08.683Z Electron: 22.5.1 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0. Sandboxed: No Steps to Reproduce: a workspace at a UNC path that isn't set in security.allowedUNCHosts. "Yes" when prompted to temporarily allow working from that host. changes to one or more files without_ saving them. VSCode without closing the workspace (may require specific settings to automatically re-open the previous workspace). time, click the "Learn More" button when prompted to allow working from that host. Note that any unsaved editors remain, but the rest of the workspace is not loaded as though the user clicked the "No" button. I'd argue that "Learn More" doesn't constitute a decision from the user and shouldn't proceed as though it was. Depending on the nature of the changes, this may cause a problem for safely saving those changes because if the user tries to re-open the workspace, they are asked to either save or close these orphaned editors. Perhaps a link among the text in the dialogue box would be more appropriate than a button which closes the box.
I agree that the dialog should not close and/or make a decision when you click "Learn More". Unfortunately the dialog closes when you press that button, so best I can do is to open it again asking the same question.


Run the command . Nothing happens Can we show the dev tools or open an output view that gets focus? From describing a user how to help us debugging an issue with storage:
The action also runs in browsers where we cannot open devtools automatically. We cannot use the output view because we actually show a real table: <img width="1394" alt="image" src=""But we can inform the user via dialog.
For the other action "Log working copies" I will reveal the window log where it is logged to.


Type: <bFeature Request</bDepending on the extension we are using, when code suggestion information appears, it is not read by screen readers. Steps to reproduce. Install the codeium extension. Open any project, and start typing or commenting the code; You will hear a sound when a hint appears, but this hint is not read by screen readers like nvda. I suggest that it is possible to activate a configuration in vscode, so that this type of information can be transmitted to screen readers. VS Code version: Code - Insiders 1.79.0-insider (, 2023-05-20T01:18:53.811Z) OS version: Windows_NT x64 10.0. Modes: Remote OS version: Linux x64 5.15.90.1-microsoft-standard-WSL2 <!-- generated by issue reporter --
I can reproduce. We must not be getting the line content here
I would like to inform you that I also tested it with the copilot and when listening to the sound that a suggestion was given, the screen readers also do not read.
You need to set to and it will work for copilot
do you think we should now set that to by default?
Nice defined it and it actually worked for the copilot. My suggestion is that it would not be possible for these settings to go to the accessibility feature? I know that it makes sense to stay where they are because it has to do with the editor, but they are difficult to find, or maybe we have some dock where all the accessibility features are and their respective paths where they should be activated, you get the idea.
Yes, we actually have help menus now for the copilot chat view / interactive editor session. When you focus those inputs, using reveals/focuses the help menu for each. I think for this case, we should enable inline suggestion by default
Sorry, just found out that by enabling the setting, it also worked for codeium. Should I then close this issue?
I think we should enable this by default, so will use this issue to track that
I agree with the idea setting the inline suggestion announcement to TRUE by default as it is now stable.
Verified the setting default is flipped


Type: <bBug</bOpen terminal Use Terminal Copy Selecton as HTML command () after selecting text in terminal Expected: Selected text in the terminal is copied as html, so formatting (such as color) is kept. I am then able to paste this text elsewhere, outside of VS Code. Actual: [object event] notifcation] & text isn't copied to clipboard at all, clipboard contents remain unchanged VS Code version: Code 1.78.2 (, 2023-05-10T14:39:26.248Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ npm-intellisense1.4.4 vscode-eslint2.4.0 vscode-npm-script0.3.29 prettier-vscode9.12.0 npm1.3.0 vscode-ansi1.1.6 python2023.8.0 vscode-pylance2023.5.30 jupyter2023.4. jupyter-keymap1.1.0 jupyter-renderers1.0.15 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 vscode-react-native1.11.0 vscode-react-native-preview2023.5.821 es7-react-js-snippets1.9.3 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This was working at some pt, not sure why it doesn't anymore
Can reproduce: ! It's also a little weird having in the precondition as that makes it never show up in the command palette (I'm guessing that's set to false when the terminal is blurred?)
Something's wrong with getting the serialize addon: !


Testing I might be doing something wrong, my contribution: I see no status entry that I can click on. I also tried with an existing command such as . ! Extension code is a hello world: Full :
not implemented


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


Type: <bBug</bIn previous VS Code version 1.78 when I pressed if inline suggest was visible with suggest widget it hides only inline suggest, if I press again same shortcut it then hides suggest widget. Now with 1.79 it hides both inline suggest and suggest widget. KeybindingService logs: My custom shortcuts to hide inline suggest & suggest widget: I even tried to add to clause and still it hides both. VS Code version: Code 1.79.0 (, 2023-06-07T14:31:03.317Z) OS version: Darwin arm64 22.5.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (12)</summaryExtensionVersion ------ vscode-eslint2.4.0 gitlens13.6.0 prettier-vscode9.13.0 copilot1.88.132 vscode-graphql0.8.13 vscode-graphql-syntax1.2.0 symbols0.0.11 vscode-react-native1.11.0 vscode-thunder-client2.7.6 vscode-fileutils3.10.1 vim1.25.2 quokka-vscode1.0.543 (1 theme extensions excluded) </details<!-- generated by issue reporter --
full text search doesn't reveal the context key anymore. Has that been removed/renamed?
It is
sorry I was writing that instead of copy-pasting. Already updated the issue.
Does it work when you swap the keybinding configurations? (Like literally exchange the positions in the file)
Still the same issue even if I swap places :(
So, its either the or context key. Can you investigate with the F1 Inspect Context Key Tools to see if those context keys are set. Note that it will print context keys on the console of DevTools
<details<summaryContext keys</summary</details
as you can see is and is , but even though inline suggest was visible it returned false.
Same in the monaco, if the suggest widget is visible, the inlineSuggestWidgetVisible will always be false no matter there is any ghost text or not
<!-- 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!
Now I see us hiding the suggest widget first and the inline suggest second, is that expected? This is true regardless of what order I declare the keybindings in (I do have the Vim extension installed)
It should hide first inline suggestions and second time you press it, it should hide suggest widget. Try to swap places of keybindings to see if it fixes it (order maybe matters?). Because previously this is how it worked (in 1.78, but regression was introduced in 1.79). EDIT: Oh I see you mentioned that order doesn't matter. Try to add in clause for command (I hope it works).
is it fixed for you on the latest insider builds The following does not work for me either
It works! !
Great, thanks for confirming!


Steps to Reproduce: Copilot Chat the file in VS Code +i It takes like 2s for the UI to show up. One time when I was doing a lot with VS Code it took so long (like 10s) that I thought I didn't have the extension installed. Not sure if this is on the UI side or the extension side, but even still, I think the UI should be instant (even if it's perceived fastness) since all I'm seeing is an input box that I will type in.
I have done a bunch of tricks, most importantly to showing the UI while asking the extension to create a session. Also the UI is more lazily created which helps. However, once there are changes the bottleneck is setting up the embedded diff editor. There isn't much I can do about it <img width="726" alt="Screenshot 2023-06-15 at 16 10 35" src=""


<!-- 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, actually this issue has nothing to do with extensions <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- Version: 1.79.1 (user setup) Commit: Date: 2023-06-12T16:14:05.102Z Electron: 22.5.7 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: Connect to WSL(Ubuntu ) Profiles =Show Contents... <img width="286" alt="image" src=""As you can see, the extensions of the profile are duplicated. The reason I found is I installed the extensions in WSL again. Maybe It's not a bug. But, the profile should distinguish between extensions installed in the host and WSL. Maybe like this: ESLint - host Disabled ESLint - WSL So that I know which place I install the extension and its enabled/disabled status. When I open the detail page of the duplicated extensions, both of them display an "Extension is enabled on 'WSL: Ubuntu-22.04'" message. What I expect is: The extension is installed and enabled on the host, the message should be "Extension is enabled". The extension is installed and enabled on the WSL, the message should be "Extension is enabled on 'WSL: Ubuntu-22.04'". Does it make sense?
Related on Stack Overflow: . Let me know if there's any debugging steps or details you'd like be to solicit from people in my answer there.
/duplicate
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
what's it a duplicate of?
I am sorry, I remembered this bug and thought there is an issue already, but there is not. Reopened it.
I guess duplicate only shows for extensions installed in both local VS Code and remote hosts. !
Fixed: Contents show only one instance of the extension


Add the possibility to persist the content hover sizes
To test, please read the following. Currently the implementation of the persistance mechanism of the content hover works as follows: The content hover has a default maximum size which is defined as follows: const defaultMaxHeight = (().height / 4, 250); const defaultMaxWidth = (().width 0.66, 500); Whenever the content hover is resized, the last hover dimensions are stored. Next time the content hover is shown, the maximum dimensions are updated as follows: const currentMaxHeight = (().height / 4, 250, lastHeight); const currentMaxWidth = (().width 0.66, 500, lastWidth); The content hover is rendered naturally within these constraints. If the lastHeight and lastWidth are smaller than the default max dimensions, then the current max dimensions are unchanged. Therefore the next rendering of the content hover will be the same as the initial rendering. Test that the content hover works according to these constraints. There is some discussion going on about how to better implement a persistance mechanism. We could also persist the size for example on a per-token basis in the editor. Let me know what you think is best!
Do you have an example of how it should work? Regardless of how I resize it, it is not remembered.
You may see an example of how it works here. The content hover is resized to a bigger size in the gif. The current max width is increased to a higher value and at the next rendering of the content hover, the widget takes on a bigger size. To see this behavior you should choose a content hover where the content does not fit in the visible widget, where there is a horizontal scrollbar. I opened an issue for persisting the content hover on a per-token basis here: as an alternative idea.


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


Testing After clicking the "Install" entry in the quick pick, there's progress for a few moments, then the quick pick flashes back to showing all the previous entries again, before finally landing on the setup options for the remote extension. !


Testing Format of keybindings is particularly ugly ! !
Does this question accept PR from outsiders?
yes. VS Code does accept PRs!
Thanks!, and I'm going to refer to styles for other widgets, or if we already have styles we like?
It's more complicated than just styles, sadly. We need to use our rich hovers instead of the native hovers... thankfully we did some work recently to plumb a all the way down to the QuickPick. To fix the title bar buttons, you can probably add the hover delegate in into the options of these s: The list will be harder has the buttons get created here: but we can be iterative here and focus on the title bar buttons first. the other issue that has to be addressed is that Monaco: currently doesn't have a HoverDelegate implementation here: so either we need to implement a HoverDelegate in the "standalone" code (aka Monaco) or we need to pass in the right value to tell quick pick to not use a hover delegate and use native hovers instead. So yeah... it's a bit more complicated than styles unfortunately
Sorry to reply late, thank you for your help! I will start learning the relevant code here over the weekend, hope it goes well!
It is very convenient to create rich hover based on the clues you provide!(Please ignore his style and content) I'm using method for the time being to set the style: I would like to ask for help, is it the right choice to use this method? If yes, I will continue to improve ps:For Monaco, I haven't started looking at the relevant code, but I will as soon as possible !
On the VS Code (non-Monaco side) we already pass a hover delegate in here: So you should be able to just reuse that instead of
I adapted the title bar, but the buttons in the menu options cannot be easily adapted because they are not available e.g. 'Learn More' in screenshot, next I'm going to learn monaco-related code, for monaco's tabbar, do you know which pages can be easily called show?
we can start with just fixing the title bar buttons if you'd like and then fix the Learn More ones later. We can be iterative :) We still for sure need this before that PR of yours comes in: from
Thanks for your help, I'll go investigate the monaco related code, but it may be later, I'm also stuck with this issue
If you use Node 18, you shouldn't see that issue.
It works for me, I would also like to ask for a simple question: In addition to calling api, is there any scenario in vscode that directly runs monaco? I'm trying to find a link to a monaco input call, but failing
Good question. Here are the steps for running Monaco: What I would recommend is maybe temporarily adding a button to an existing quick pick like the command palette: add a line like: and don't forget to import it:
Thank you for your patience! I will start learning the code
I investigated the existing code and found some problem if I wanted to implement a HoverDelegate in the "standalone" code: We need to use related code, but they are in the , and should not be import this layer, do we need to re-implement a standalone with hover? or lower the code hierarchy to the level, I'm not sure if the conclusion I got is correct, so I still need to ask you for help, thanks!
so before, I provided a default implementation of the here that does nothing: I think what we should do is remove that and allow to be /optional. If it's don't pass it in to the s so that the native hover is used as fallback.
It's better to handle it this way, otherwise it's really difficult to achieve the current situation (especially for me), I'll submit the PR later
I submitted an initial PR, but I'm not sure if I missed some details, and found that one of the tests timed out
Verification on macOS would be easiest I think: Open up a few pickers Hover over different components: description detail quick pick buttons quick pick item buttons None of them should be using native hovers. They should all be using custom hovers.
Is there anything I can do to help? Do we need to replace everything that needs to be replaced with a custom hover,I'm willing to submit a PR to modify these if I can
It's already done! Now we verify everything is working as expected before :)
Are these the old tooltips or the new ones? <img width="275" alt="image" src=""<img width="306" alt="image" src=""This is what I'm seeing.
Yes those look like custom
Actually, the keybinding one isn't... let me capture this in another issue as the class doesn't actually support a hover delegate.


Testing Steps: Open locally cloned vscode repo with any branch Welcome page Connect to... Continue Working in Nothing happens after this for me... but I do see the commands get run:


Testing a file +enter to run cell in interactive window window GitHub Copilot classic installed and signed in something into the input box and ctrl+enter, this opens a third editor group with multiple synthesized Copilot solutions (feature from GitHub Copilot) close that editor :bug: now there is an empty third editor group which really shouldn't happen AFAIK, also there is screen cheese, it shouldn't really be possible for Copilot to cause this kind of layout issue <img width="1256" alt="image" src=""<img width="1245" alt="image" src=""
I assigned you for grid layout and I assigned you for editor layout, please feel free to unassign if this isn't relevant to you
empty editor groups are not a bug per-se, if you configure , groups will remain open when the last editor closes. Also, empty groups can explicitly be created, e.g. via . However, the fact that you cannot get rid of the empty group when you press the X button sounds like an issue to me. When you try to close, is there anything printed to the console?
Ohhhhhhhhhhh good bug! There is definitely splitview/gridview breakage here.
Wait. I could repro once... but not anymore. Can you still repro?
Yes I reproed twice
I cannot see anything in logs when clicking on the X unfortunately (fwiw, I do not have that setting configured) When I repro this, here's what's in the log (this happens right after closing the last editor in a group that results in the group not also being closed)
I wonder if this could possibly be a regression from the auto-sizing feature you did?
We just need to be able to repro on demand so we can attempt to repro on a version before my changes to confirm this. But I can't seem to repro no more. Can you ?
I cannot reproduce this, I never get an empty editor group. This is with fresh user data dir and extensions dir.
if you have a reliable repro that you can share, including your settings if any. Here is what I do: !
I did some more messing around and was able to repro a similar problem ! <details</details
OK, I have a trivial and consistent repro. TLDR it looks like the interactive window does not play nice with split view. an interactive window (you can even do this with the Jupyter: Create Interactive Window command) the Settings UI the Settings UI onto the right of the interactive window :bug: the split view is very unhappy Logs <details</details
This also repros for notebooks opened in the second group Right click a .ipynb file -open to the side open another editor and drag it to the right side of the first
Oh wow. So it looks like the call to throws an exception when done in the interactive window and that means the Grid will indeed be unhappy!
for surrounding some of the calls with .
Arguably, the grid/splitview should also protect itself...
Yeah, maybe. There could be other cases.
I can't repro any of these now but it would probably help for to verify too
I still do not have a functional cursor/trackpad so cannot drag/drop maybe you can verify?
Verified it's working great


The steps are simple: settings editor in one group untitled editor in the group next to it sizes are equal drag the untitled editor to the left of the settings editor the sizes end up not to be equal. Insiders ! Stable ! Maybe this is related to the settings editor wanting a larger size? I can reproduce this in a small window size (the default one when you open a fresh user data dir).


<!-- 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.79.2 (user setup) OS Version: Windows 10 22H2 To fix the issue please update the native-is-elevated package. It was fixed two months ago.
Could you maybe verify using our insiders? You can give our preview releases a try from:
It seems working properly now. Thanks!


in VS Code :bug: sticky scroll has no syntax highlighting <img width="691" alt="image" src=""
Hey I update my insiders version and tested on the file you sent, I am currently not able to reproduce this error: ! I'll try to reproduce this issue. I think I may have seen this happen for a very brief moment.
It appears this is due to the following PR which attempted to fix Since the state was no longer recomputed when the new state was equal to the old state, this means that the rendering was no longer done when the model tokens changed but the state remained the same. A fix will be made to revert this change.


create a folder with a task that uses: update an extension and use "Reload window" or use Reload window directly from the command pallette observe that the task now runs twice: <img width="328" alt="image" src=""
Likely a regression from one of the task fixes this iteration.
Not able to reproduce Do you have task.reconnection enabled? Would be helpful to see each of the terminals
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
This problem still exists, I'm afraid I'm not sure the repro steps are as Alex described, but I still get duplicated tasks
It seems for Alex's repro steps to work, the terminal panel needs to be hidden
When the panel is hidden, the tasks don't run at all for me atm. I'm going to merge something that will fix this part of the issue, but in order to truly test it, I'll have to first


Verification steps: Make sure you are on diff editor version 2. Enable whitespace only diffing (the reversed P in the toolbar). Diff two identical documents, change indentation. Verify that a notification is shown.
I cannot find your reversed P, nonetheless, with diff version 2 and removed "ignore leading/trailing whitespace", I get this: <img width="1384" alt="image" src=""and TBH, why should have an option to ignore any diff view? Isn't the purpose of the diff, to really see the diff? Git extensions -more logical diff: <img width="551" alt="image" src=""


enough cells in the interactive window that it needs to scroll "interactiveWindow.alwaysScrollOnNewCell": false to the bottom of the IW and execute another cell :bug: scrollbar height changes and is at the bottom, but the new cell isn't visible


Testing Repro: screen reader mode the editor the show notification command, :bug: the editor is still focused the show notification command, the notification center is now focused?
My notification was read once fully, then the screen reader started reading it a second time. Part way through that second time, the notification no longer seemed selected (didn't have a blue box around it), and the screen reader just stopped reading it.
the looks correct here, but I can repro the focus getting stuck in the editor any thoughts would be appreciated


a md file: between the html elements bug This inserts markdown syntax even though markdown typically isn't supported inside of html like this:
Likely requires a proper markdown parser to fix
I don't know if this is the expected result, since I don't see any difference pasting in the tags. I tried using two versions of .
Thanks for testing. I think there's still a bug with . In this case it should likely not paste as a markdown link. Somewhat weird case because it's the pasting itself that makes the html span multiple lines. With the newlines it's two entirely separate html blocks according to markdown


I was just looking at the field of our event and I noticed that a lot of the durations are negative. Looking at the code here It looks like we are computing the miliseconds since 1970. I guess that we are hitting some overflow, and thus the numbers are negative. I suggest that we instead use the class that Joh is using here for example I can go ahead and push a fix for this.
I am not 100% sure if using would fix this. at the end of the day uses , and you were using . It looks like getTime treats timezones differently. So my proposed fix might fix the problem or it might not. What do you think Here's the Kusto query to see the events with the negative durations
I have pushed a potential fix for this. To verify run the above query in kusto Make sure that no events are happening in the latest VS Code Stable / Insiders version (thus that the fix indeed fixes it). I am assigning this to September to give it some time for the data to settle in.
Thanks for the fix. Using is the right thing here.


Type: <bBug</bOn Mac, in terminal, press Option+F1. It says: Go to Next Command (Command+DownArrow) Go to Previous Command (Command+UpArrow) This has been recently updated as: Option+Up/DownArrows. VS Code version: Code - Insiders 1.81.0-insider (Universal) (, 2023-07-28T12:09:45.183Z) OS version: Darwin arm64 22.5.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (90)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 dscodegpt2.1.15 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.13 copilot1.99.294 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.3 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.12.0 vscode-pylance2023.7.40 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.2417 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 chatgpt1.1.2 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Yes reported this, but I cannot find that issue, so we'll track it here. This is because of this line


Type: <bBug</bIn editor, I can't use and alt+[` do not have specific "when" clause and conflict against inline suggestion view in keybindings. VS Code version: Code - Insiders 1.81.0-insider (, 2023-07-28T12:08:04.472Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.19.1 gitlens14.1.1 EditorConfig0.16.4 prettier-vscode9.19.0 vscode-google-translate1.4.13 codespaces1.14.13 copilot1.99.297 copilot-chat0.5. remotehub0.60.0 vscode-github-actions0.25.8 vscode-pull-request-github0.68.1 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.3 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.12.0 vscode-pylance2023.7.40 jupyter2023.6. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.80.2 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.7.2417 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.15 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.90.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.12.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.52.0 vscode-java-dependency0.23.0 vscode-java-pack0.25.12 vscode-java-test0.39.0 vscode-maven0.41.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --


When exporting a profile, a SR user has to navigate the whole list to reach the button. We should either move the button to the top or have a keybinding/command which does this. cc <img width="293" alt="Screenshot 2023-07-31 at 11 30 34 AM" src=""
Is not the tab should take to Export button when the complete tree is focused instead of focusing the check box?
I'm not following
Try to get into the state where Tree is focused not any of the elements of the Tree. For eg: <img width="662" alt="image" src=""See the outline focusing the tree. Press <tabnow. This should focus the Export button right?
correct - pressing tab when my screen looks like the above causes focus to be lost rather than going to the button.
Tab at this state is taking focus to the checkbox in the tree. IMO checkbox should be focused when the row is focused and you tab then. Is it possible to change this behaviour?


VS Code Version: 1.82.0-insider OS Version: Ubuntu 22.04 The path is missing the first character in the path for a specific file on the 'git show --textconv' lines 'ub-folder' vs 'sub-folder' If the command is run manually, with the correct path there are no issues Working (Non-root folder) 2023-08-03 19:10:33.264 [info] git show --textconv [4ms] 2023-08-03 19:10:33.267 [info] git ls-tree -l HEAD -- [4ms] Not Working (Root folder) 2023-08-03 19:12:26.351 [info] git show --textconv [20ms] 2023-08-03 19:12:26.386 [info] git ls-tree -l HEAD -- [35ms] Expected (Root folder) 2023-08-03 19:12:26.351 [info] git show --textconv [20ms] 2023-08-03 19:12:26.386 [info] git ls-tree -l HEAD -- [35ms] Originally posted by in
could you please share repro steps that I could use to reproduce this? Or the complete contents of the git output window would also help. I have a suspicion where the issue is but I need the logs to reproduce and fix the issue. Thanks!
Hello Ladislau Szomoru, open vsc go to Source Control (Ctrl+Shift+G) look under "Staged Changes" and click on notice left side is always empty and right side shows entire file changed. Thanks, Gregory Porras


hover over editor tabs observe some kind of shadow dropping over the text
This only reproduces with set to and tabs enabled in general. Hovering over any tab shows the white shadow at the end of the label. With this setting, every tab label has a element to draw a linear gradient (): <img width="400" alt="image" src=""A tab itself is a container of a label and the toolbar with the close button. The close button is set to to not take more space than needed. When you hover, the toolbar is made visible, actually pushing the element into view having the described effect: <img width="504" alt="image" src=""I actually think this is an OK behaviour for when the tab is small enough that the label cannot full show, and that was the intention. However, it is a bit strange that this would happen even for a tab that shows fully and has enough space. If someone wants to chime in to take a look with a reasonably small change, opening for help wanted. But may decide to close out of scope as this does not seem like it was ever a regression.


Insiders 1.82.0 Looks like the command center and associated toolbar buttons aren't functioning when clicked. Weirdly it seems like I can sometimes(?) get a hover state but it doesn't always work. Repeated clicks minimizes the window which makes me think the events are going straight to the titlebar and being handled as such.
I can reproduce
Maybe an Electron 25 update regression with draggable regions and custom title bar? //cc
looks like behavior on macOS is now aligned with windows and linux, the region no longer emits events. Behavior changed with this commit and verified with the following fiddle Looks like we would need to revert this change to align with Windows and Linux.
Yeah, looks like drag and click isn't working for macOS anymore. It always seems like an oversight/bug but a wanted one. To enable clicking again I have the for the CC even for mac. On the downside it means that the window cannot be repositioned from the CC anymore
Slack is the same, you cannot drag from their command center either.


Settings: !
How it should be: <img width="442" alt="image" src=""
Hm, strange. I haven't made any changes here lately. I'm noting that is not having an effect on the foreground color used on the tree within Explorer. It does however affect other lists like the one used in the quick pick. I also noticed the terminal tabs tree flicker to use that red before being stomped on again. Not sure what's going on here yet.
Looks like this is from
Gotcha I might just revert the change and switch it to something more specific - I didn't consider all the other applications of the list widget and checking other themes (it was okay in a couple of the themes I checked)


Type: <bPerformance Issue</bIn a bash terminal with Shell Integration, execute the following command, which is 5k characters long: On both my machines (Linux native and Windows + RemoteSSH), this commande takes 1s to execute. Make it 10k characters and it takes 4s. At 15k, it takes 8s. I'm using bash version 4.4.23 (the one shipped on SLES15 SP4). It appears to be related to the Bash Shell Integration, specifically the function located . This can even be reproduced outside of VSCode, in plain bash. Just define this function in a shell and execute it with a long argument. As a workaround, it is possible to disable Shell Integration in the settings and open new terminals. With a newer bash 5.2 built by myself, performances are better, but still non-negligible: 5k: 0.5s, 10k: 1.5s, 15k: 3.5s. Note: I get similar numbers with a bash 4.4 compiled by myself, so better performances with newer bash might just be related to different compilation options/optimizations. VS Code version: Code 1.81.1 (, 2023-08-09T22:18:39.991Z) OS version: Linux x64 5.14.21-.24.28-default Modes: <details<summarySystem Info</summary </details<details<summaryProcess Info</summary</details<details<summaryWorkspace Info</summary</details<details<summaryExtensions (1)</summaryExtensionVersion ------ remote-ssh0.90.1 </details<!-- generated by issue reporter --
Thanks for the report, hopefully a bash expert will spot this and help optimize the function
Unfortunately this still seems to be quite slow for me. Normal bash runs quicky (). Bash in VS Code has had a core stuck at 100% CPU for a few minutes now with no signs of letting up... <img width="790" alt="image" src=""Doing some binary searching, it's "fast" until the echo hits 1989 characters (a total command length of 2001 characters), at which point it stalls as above
Actually, it seems any command over 2000 characters in bash stalls and takes a long time to run. Doesn't have to be an echo. It seems like time taken is somewhat exponential, 2001 characters take 21s to run for me while 2100 characters jumps that up to 29s. That seems to be the point at which we use a 'fast' implementation. In reality this seems much slower on macOS at least
Hi. Could you check that whether you have command and on your system? Since I actually provided two fast impl in the PR, I would like to know which is problemetic for subsequent troubleshooting. Edit: never mind. I have reproduced the hang and propose another fix.


Workaround This is an issue in Chromium itself. For now there are the following two workarounds: ### <blockQuote</blockQuote1. ### <blockQuote</blockQuote## Bug <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. -- <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --1. ### VS Code Version Per: affected version is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.82.0-insider Commit | Date | 2023-08-11T17:10:45.392Z Electron | 25.4.0 ElectronBuildId | Chromium | 114.0.5735.248 | 18.15.0 V8 | 11.4.183.27-electron.0 OS | Linux x64 6.4.9-1-default </blockQuoteHowever, per: that , that is: <blockQuoteType | Data ----------------|----------------------------------------- Version | 1.81.1 Commit | Date | 2023-08-09T22:18:39.991Z Electron | 22.3.18 ElectronBuildId | Chromium | 108.0.5359.215 | 16.17.1 V8 | 10.8.168.25-electron.0 OS | Linux x64 6.4.9-1-default snap ### OS Version <blockQuote</blockQuote</details## Steps to Reproduce 1. The GUI is invisible: the menubar continues to operate correctly.
82 updated to Electron 25 and doesn't work on older OS.
I'm using cpe:/o:opensuse:tumbleweed:, which updated 2600 packages yesterday (which I have installed) yet this problem remains. Nobody in their right mind would consider that to be old. Additionally, I am using which means that no independent part of the OS should be considered old. This is the most bleeding edge system for miles. Regardless, should I perhaps open a linked issue at
Oh, sorry, I thought it's an old OS issue. Before reporting in the electron repo, what is Help Toggle Developer Tools bringing up? Have you tried to do a clean reinstall of VSCode Insider? Perhaps it was just a bad build. Or, alternatively, you could try to download the latest Insider installer and install over your existing broken version (which I assume it's 3-4 days older than what you'd get right now) - that should effectively update it.
No problem. Thanks. Apologies for being curt. ! ! Appears that it's reproducible.
Very strange, indeed. I'm out of ideas. Would be interesting to be able to test with a previous Insider version, but for that you would need to have the old package and disable automatic updates. Electron was updated from 22 to 25 on August 8, so the last version with Electron 22 is the Insider from August 7, which is also the last version that I've tested and still working on Windows 7. Anything after that doesn't start anymore on Win 7. I'm not sure whether the Electron update on August 8 is causing your issue, though...
does the log file explain anything? To me, it seemed a little too verbose to be of much use. I can try other methods to get relevant diagnostic data if you are able to instruct me.
I see many GPU-related errors, such as: Errors: link failed but did not provide an info log [(48)] (checkLinkStatus): Program link or binary loading failed with no info log. [(81)] Skia shader compilation error Found these: So it's definitely something related to the new Chromium included in Electron 25 and these issues seem relatively recent. The first link recommends to disable hardware acceleration, you could try searching how to do that from command line in the new Insider. Unfortunately, I don't have the time to dig deeper right now.
per , do you know whether VSCode contains a directory? I haven't been able to locate it.
remediates the problem. Because indeed this issue is dependent upon , before this update is rolled out, there needs to be remediating measures (or the update needs to be temporarily halted) lest it break a great many peoples' installations.
Can you please take a look at this? It's Chromium/Electron 25 related, so I immediately thought of you. Please see the response just above for a possible solution. Thanks!
Thanks for investigating the issue, given there are workarounds in place this is not necessarily a release blocker. I will wait for chromium to address this issue and backport the fix to Electron 25.
could a patch at least be to the affected releases to delete the relevant directory? Surely users shall be affected otherwise? I doubt we can expect them to diagnose a known issue if the solution is so simple.
We don't want to delete the GPUCache for all users and the affected scenario described in is not possible to detect from the application layer. I think the best I can do is to add this issue to the release notes and document the workarounds for visibility.
Why?
It will have impact on startup performance, for now I would wait to see the impact of this issue across our users and decide on a fix forward. The upstream issue has also been open for a while now, signifying its low impact.
Just happened again. !
This is mentioned in the 1.82 release notes I guess the issue remains in 1.83-insiders, haven't tried it yet.
It appears weird to me that solely VSCode appears to be affected by this (on my system) because Discord has been very happily updating frequently, and obviously has its own Electron-provided directory. !
Related on Stack Overflow: Related on Reddit: ,
Got this installed via fedora yesterday This wasted quiet some time on my end, as I first went searching for changes to fedora itself and finding this issue on vscode wasn't trivial.
Leaving this here for future me, as I now have that problem on a different PC
This also happens for other Electron based programs like Element and also chromium and firefox. see
I'd disagree, . It doesn't read like pragmatism - more like "didn't want to do a good fix". Startup time after the workaround felt normal. Super aggravating that this wasn't resolved with a one-time installation task to clear the GPU cache. Hard to know the aggregate cost incurred by people encountering this issue, but "not small" is probably an underestimation. Linked-issue count wouldn't be a good proxy for that metric, in that product-support's practice as shown in seems to be linking to the known-issue buried in the release notes, not to this issue. Sorry for the flames, but there you have it. When one's coding environment gets fsck'd, it's no fun, and erodes trust. Please consider.
I, for one, find great enjoyment in my coding environments.
This issue has reemerged with the latest version 1.82.3 for Ubuntu 20.04.1: Removing after the upgrade still works to get vscode running
It occurs for me almost every update of the package. It's ridiculous.
Same.
As mentioned before, this is caused by the new update in VSCode I have personally reverted to until this issue is properly solved
I was under the impression from the chromium bug that this is one time change and not required for every startup. I see that you are using snap version of VSCode, can you check if you are required to delete the cache for every start using the instead ?
I must rectify my comment: with the snap of version v1.82.1, it was required to clear the cache every startup, with v1.82.2 I don't remember having to do it, while with v1.82.3 it was needed only once on upgrade. I will edit my previous comment to fix it.
We had a runtime version bump between to , which seems like a trigger in the snap case. Can you setup deb package, we will have release this week. It would be good to confirm if updating requires to clear the cache in the deb package as well.
For what it's worth, I haven't encountered it on the rpm again
I've tried the following: removing v1.82.3 (snap) and installing v1.82.3 (deb) did require clearing the cache. removing v1.82.3 (deb) and installing v1.82.2 (deb) did not require removing the GPUCache. upgrading v1.82.2 (deb) to v1.82.3 (deb) using apt did not require removing the GPUCache. hope it helps
I'm not using the snap any more. I use the package provided directly by Microsoft from
Encountered this problem on Fedora 39, probably after upgrading my vscode rpm which is currently on version 1.82.3. Problem disappeared after running .
Not with VSCode specifically: but when updating to electron v28 alpha, had this issue. Also solved with (or just deleting the entire Electron dir within ).
Also ran into this, thanks for this workaround, it worked.
I also ran into the issue in VSCodium (which is a special build script for this source code) after an upgrade to 1.83.1 on Debian Trixie and XFCE 4.18. The worked like a charm (which is the equivalent folder on Debian for VSCodium). I did find that I only ran into the issue on my RX 550 (Lexa) and not my Radeon RX 580 (Polaris); I found that the bug disappeared when running the program with appended to it to run it on the latter graphics card.
This has happened a second time in 1.83.1.
Got it again on fedora using the rpm on a system, where I already dropped the cache once Version 1.83.1
Just installed an update with no vscode update but had a mesa update. VSCode broke again. I assume this is going to happen every time a mesa update is installed (I'm assuming because of what others are stating, could be something other than mesa but seems to be the biggest suspect).
Getting it after every mesa update. But may be "GPUCache" need some harder refresh or detection of brockage?
This issue has been fixed upstream via . It might take a while before it trickles downstream though, since it needs to be picked up by Electron first before it can go into VSCode. I did attempt cherry-picking the commit and generating a local build and it seemed to fix the issue.
The commit is fairly trivial and can probably be safely backported to all supported Electron trees. This is a very widespread issue, affecting virtually every Electron app running on Linux. It would be great to get the fix as widely disseminated as possible considering how slow the app ecosystem is to update versions. Is there a linked Electron issue for this? Do we need to create one if not or does the Electron project accept drive-by backport PRs?
I haven't found any linked Electron issues yet. Based on , since the patch is temporary, has been committed upstream, and will eventually be removed, I think the Electron folks will accept the patch. However, do take note that the commit has dependencies on previous commits. On my working local build, I have these 3 commits cherry-picked in chronological order: Therefore, if anyone is going to bring this up to the Electron team, all 3 patches would need to be merged. Add the patch files to the and append the filenames of said patch files to the . Depending on the Electron build version, there might also be some merge conflicts. Based on my experience, those conflicts should be resolvable, but I did not test all of the older Electron major version release branches. For each branch, we would need to double-check if the 2 dependency commits are already included in their respective Chromium version or not.
Thank you for the backporting work to Electron versions 25-28 over the past few days. Downstream applications should now be able to pick those fixes up. Once VSCode picks up the fix, we should be able to close this issue.
<!-- 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!
I'll verify when the next release reaches me on openSUSE.
by chance, were you able to verify the fix for the issue yet?
the time period hasn't been quite long enough to be certain. This usually occurs on an update or after approximately two months. However, VSCode did update recently, and this didn't occur (not that it was guaranteed). Consequently, if upstream has fixed the issue, and we're using the patched version, because it hasn't appeared yet, I'll keep this completed until it occurs (and we can reasonably consider this complete).
Considering the issue as verified on 1.85.x. 1.86.0 will go out in around a week. Feel free to comment on this issue thread if the issue comes up again after that.


Type: <bBug</bPort forwarding over ssh is not working using vscode-insiders. It is working using vscode. How to replicate: some http server on the remote the port to be forwarded and select http as a protocol opening in browser / doing a curl from your local machine the request is stuck pending VS Code version: Code - Insiders 1.82.0-insider (, 2023-08-21T05:32:43.957Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 6.1.38-59.109.amzn2023.x8664 <details<summarySystem Info</summary </details<details<summaryExtensions (54)</summaryExtensionVersion ------ Handlebars0.4.1 vsc-python-indent1.18.0 dotenv1.0.1 remote-containers0.305.0 remote-ssh0.105.1 remote-ssh-edit0.86.0 remote-wsl0.81.0 vscode-remote-extensionpack0.24.0 remote-explorer0.4.1 remote-server1.4.2 material-icon-theme4.29.0 indent-one-space1.0.0 vscode-todo-highlight1.0.5 nugetpackagemanagergui2.0.6 Handlebars0.4.1 vue-peek1.0.2 vscode-markdownlint0.51.0 vscode-eslint2.4.2 gitlens2023.8.1905 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-jest-runner0.4.66 copilot1.104.347 copilot-chat0.7. vscode-github-actions0.26.1 todo-tree0.0.226 terraform2.27. vscode-test-explorer2.21.1 vscode-nuget-package-manager1.1.6 roslynator4.4.0 vsc-python-indent1.18.0 vscode-python-test-adapter0.7.1 dotenv1.0.1 vscode-scss0.10.0 vscode-docker1.26.0 csharp2.0.376 vscode-dotnet-runtime1.7.0 black-formatter2023.5. flake82023.7. isort2023.11. python2023.15. vscode-pylance2023.8.31 test-adapter-converter0.1.8 indent-rainbow8.3.1 material-icon-theme4.29.0 prisma5.1.0 vscode-scss-formatter3.0.0 indent-one-space1.0.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-conventional-commits1.25.0 volar1.8.8 vscode-typescript-vue-plugin1.8.8 vscode-todo-highlight1.0.5 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details


<!-- 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. --This would replace . Proposal: ts /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ declare module 'vscode' { // export enum RelatedInformationType { SymbolInformation = 1, CommandInformation = 2, SearchInformation = 3, SettingInformation = 4 } interface RelatedInformationBaseResult { type: RelatedInformationType; weight: number; } // TODO: Symbols and Search export interface CommandInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.CommandInformation; command: string; } export interface SettingInformationResult extends RelatedInformationBaseResult { type: RelatedInformationType.SettingInformation; setting: string; } export type RelatedInformationResult = CommandInformationResult | SettingInformationResult; export interface RelatedInformationProvider { provideRelatedInformation(query: string, token: CancellationToken): ProviderResult<RelatedInformationResult[]; } export interface EmbeddingVectorProvider { provideEmbeddingVector(strings: string[], token: CancellationToken): ProviderResult<number[][]; } export namespace ai { export function getRelatedInformation(query: string, types: RelatedInformationType[], token: CancellationToken): Thenable<RelatedInformationResult[]; export function registerRelatedInformationProvider(type: RelatedInformationType, provider: RelatedInformationProvider): Disposable; export function registerEmbeddingVectorProvider(model: string, provider: EmbeddingVectorProvider): Disposable; } }


Repro: a perf profile a ~100mb TypeScript file (duplicate the contents of a large TS file to make this) perf profile ! It doesn't end up working properly anyway: !
After delete and undo: !


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.81.1 OS Version: server 2022 Steps to Reproduce: is a system install. Users login using redirected appdata folders launch code with appdata redirected to a unc path or can launch 'code --user-data-dir servershare$code' error Unable to write program user data , code trying to write to c:share$ Users do not have access to write to c: grant full control to root of C: and launch code a new folder is created c:share$ file created c:share$codeUserglobalStorage is created and code launches does not use the unc path while all other files are written to servershare$code fine with version 1.79.2
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.81.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
based on the above steps looks like the sqlite database is not using the unc path, passing the issue to you.
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
Same issue. installed 1.82.0-insider build. Still creates the in the wrong location.
excellent finding! I think this is a regression from partitioning state per profile. Specifically: When using , UNC paths only work for scheme but now I think we have as scheme. I am not sure when we made that flip.
I think this is spreading to a lot more places, the code is very old and was always assuming scheme to be used, which will not work anymore if a UNC path is used: I think we will have to make a pass over usage and find those that potentially use a non-file scheme...
I think I start to understand the issue better, it seems quite specific to global storage only, the other in the seem to be mainly of scheme. I believe this started with moving out of the environment service and into the profile service:
The change to scheme started happening from this change - - I started using this scheme for all user data to adopt atomic write. Since I had reverted atomic write for user data in this commit - - I can revert to use file scheme for user data on main. But going forward, I will bring back user data scheme and probably we should our file service and uri identitiy utilities instead of using fspath and path join.
but there is a point where our file service is no longer in charge: when we hand of a to SQLite3 module, we really have to give it a proper path that is a UNC path if the user picked a UNC location. So just using will not help here, we need to find a way that is not breaking UNC paths in all places where we need it.
Thats right, I also observed that we browsing the storage code. May be we should convert this back to file scheme before using in those places?
yes, doing seems right to me, even though ugly. Curious: with your custom file system provider on , are you converting back to a URI and then handing the off to the disk file system provider? Or do you convert one level above on the level of the file service? Asking, because I wonder if there is already a bug in your provider where we potentially loose UNC paths.
Thinking a bit more about this, I wonder if should statically allow us to register a scheme to behave like a scheme. Because, we do take an existing well defined of scheme and turn that into . This in turn means, every client that deals with such a would need to ensure that the scheme is converted back to before using the . That seems fragile. If we could tell to treat like a scheme, maybe the change would be easier and less fragile?
IMO this is as ugly as using on URI, because it can cause issues anytime. Even if you know the scheme of the URI converting to file scheme is always safe. Here is the conversion logic: This is handled in the FSP of vscode-userdata. I just change the scheme and pass it to the native FSP.


It should be just "Copy Output", the "to Clipboard" is obvious? This then aligns with other copy actions across the product Testing


Testing open execute a cell that shows issues select copy output no output is copied I'd except that this "just works", at least for its text/markdown output representation


Going through the error logs showed the error below . No steps but it is rooted at this line
verification - Perform a few actions in a notebook, add cells, run cells, close/reopen the tab, run more cells Open the dev tools and ensure the error is not in the console


Testing Should be exposed using a code action (specifically a source action) instead of as a setting? Some advantages: We can reuse the existing setting instead of adding a new one Sorting will play nicer with other source actions since users can configure the order in which the actions run Users can trigger source actions through the context menu or with keybindings
Hey that's a good idea! I'll discuss it with the team. What do you think ?
Yes, makes sense!


Type: <bBug</bI am developing a VS code debugger extension by inheriting from DebugSession class. I implement disassembleRequest method to support disassembly view. But now there is a strange bug which I am not sure whether it is the bug of VS code or not. When disassembly view is firstly open, it shows wrong addresses and instructions. But after I scroll mouse up and down to manually refresh disassembly view, it shows correct addresses and instructions. So it seems it is a refresh issue. I have inspected the returned data to VS code and I am sure data is correct. BTW, if the returned data deos not contain source information, then the address and data is correct. I also post a question in stackoverflow: The question contains two picutures which should be able to describe my issue. Thanks! VS Code version: Code 1.82.0 (, 2023-09-06T22:07:07.438Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (9)</summaryExtensionVersion ------ biosdbgv44.1.2 vscode-eslint2.4.2 workspace-storage-cleanup1.1.5 isort2023.10.1 python2023.16.0 vscode-pylance2023.9.10 cpptools1.17.5 hexeditor1.9.12 memory-viewer0.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Could you try this in the latest VS Code Insiders build? A bunch of disassembly view fixes just went in
I test on the latest VS code insiders 1.83.0, and the issue still exists. Please see below pictures When disassembly view is firstly open: ! After scroll mouse up and down to refresh disassembly view: !
Can you please either share your extension/a reproduction, or share a log of the DAP messages sent and received by your debugger?
Hi Connor, I have sent disassembly message to your email Thanks! Bill Zhang
Hi Connor, below is the implementation of disassembleRequest: protected async disassembleRequest(response: DebugProtocol.DisassembleResponse, args: DebugProtocol.DisassembleArguments) { try { const baseAddress = args.memoryReference; const offset = 0; const instructionOffset = args.instructionOffset 0; const instructionCount = args.instructionCount; const input = { baseAddress: baseAddress, offset: offset, instructionOffset: instructionOffset, instructionCount: instructionCount }; const instructionList: BIOSDBGInstruction[] = []; const output = await callRpcMethod("Disassemble", input); for (const item of output) { const addressHex = '0x' + item.address; const instruction = new BIOSDBGInstruction(addressHex, item.instruction, item.instructionBytes); if (item.sourcePath !== "" && item.lineNumber 0) { instruction.location = this.createSource(item.sourcePath); = item.lineNumber; } (instruction); } = { instructions: instructionList }; } finally { this.sendResponse(response); } }
Yep, got it, thanks. My plate is full right now but I'll look into this within the next couple weeks.
<!-- 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!
Tested with 1.84.0-insiders, it seems that this issue is fixed. Thanks!


Repro: Open multiple terminals Select multiple terminal tabs Right click and change color Change color only a single terminal is changed Real context stored with the action was done recently as part of Related:
/duplicate
Tracking each action separately
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I'm not sure this is worth fixing as color is meant to differentiate between tabs. Same for the icon/ renaming.
you might want multiple red though, right now it doesn't work as expected. We were actually doing this wrong by querying which tabs were selected also, after we get the actual instances this was triggered on passed into the action, so we can probably remove the special tab instance command as part of this.