<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66 OS Version: ArchLinux Shell integration doesn't work with oh-my-zsh and powerlevel10k. The indicator is only shown for the first line and the disappear. Another problem is the warning from powerlevel10k about instant prompt (see attached screenshot) Steps to Reproduce: zsh oh-my-zsh and powerlevel10k theme vscode and start new zsh terminal to run some commands Screenshot: !
Having the same issue.
Refs Out of curiosity, P10K explicitly disables the integration (as it does not work anyway and yet makes the prompt slower). So, if someone tries to debug this situation, make sure to comment out the following line before testing: P10k is extensively used (has almost 30k stars), so it would be very nice if VS Code can manage to make the Shell Integration work with it.
We'd like to support it, the summary of the discussion/situation around this was: We're using custom sequences to control everything and extend the shell integration. Since we launch the process we can guarantee we're in VS Code (except for edge cases). VS Code's shell integration will eventually be enabled by default, it works by wrapping your PS1, PROMPTCOMMAND and eventually . In order to have the most impact, we aim to support most_ shells so more users get it by default, with a manual setup option for complex shells and sub shells. This will come in the form of essentially running the script manually in your rc file and disabling the automatic injection. Powerlevel10k is complex, it handles shell integration used by other terminals manually. I don't blame for not being keen on our solution if it means he needs to implement a VS Code-specific solution. After a bunch of back and forth I recommended we all take a step back, disable it explicitly for now and let us stabilize more so we don't rush into something we will regret. We will probably at some point document the sequences (it's still getting stabilized and subject to change) or maybe support the more common sequences which would let it just work without additional changes. My main concern with supporting multiple shell integration protocols is them conflicting with each other, but that's probably the right thing to do and we could have a switch which disables the other protocol.
Haven't tested this much but this seems promising after some trivial changes: ! Not sure yet why we're not getting the cwd sequence, I'm forcing shell integration on via
Another problem is there doesn't seem to be a nice way to extract right prompt or continuations so this ends up happening: <img width="486" alt="Screen Shot 2022-06-10 at 1 41 39 pm" src="https://user-"We could make some guesses by examining the content of the cells but that's not ideal. It would be a shame if we lost the fairly reliable extraction of the command since a lot of the interesting future functionality will be built on that like extension APIs and autocomplete.
In general in zsh it's impossible to extract the command from the data written to the terminal. The command isn't always visible. For example, try entering a command that's taller than the height of the terminal (use ESC Enter or Alt-Enter to insert a line break). Or try running and entering a command that's longer than the width of the terminal. If a terminal needs to know the command being executed, it'll have to provide an extension so that zsh can supply the command explicitly.
I'm willing to implement a VS Code-specific solution but I would need you to provide a spec of VS Code terminal extensions and promise backward compatibility.
The feature that exposes the commands is not particularly discoverable but it works pretty great for the general case in all shells at the moment, I know there are edge cases when it will fall apart though. For pwsh the column and line are not reliable because of conpty so we do pass through the command line there and it works well: ! Great, I wouldn't want you to without us committing to it . We're still not at the stage where reliability will become more important so we're just passively thinking about this problem atm. I'll let you know if we'd like you to do that. For now we can just disable the parts that need the command which will still give us the markers/command navigation. I have a couple of questions that would save me a bunch of time if you know: I see the window icon/title is coming through in and , is there a trick to getting the cwd to be sent via something like , or ? Is the right way to test against?
Sounds good. Powerlevel10k doesn't set terminal title and doesn't report the current directory. These things aren't related to prompt and can be done separately. Powerlevel10k provides only prompt. The best way is to set . No need to export it. is normally set by the native integration of iTerm2. It doesn't work with Powerlevel10k, so Powerlevel10k undoes that and enables its own integration.
I put a PR out which should make the upcoming release With it, shell integration should work with powerlevel10k if it emits the more common standard OSC 133 A, B, C, D sequences. This won't give all the features but it will turn on command decorations with exit status, command navigation (ctrl/cmd+up/down) and the overview ruler. if you could emit the OSC sequences for VS Code that would be great, checking $TERM_PROGRAM = vscode should be a reliable way of doing that. I'll let you know if we end up committing and documenting the sequences we use, in which case a command line sequence could light up more features.
Awesome! Have you tried it? Powerlevel10k emits OSC 133 if you set . It's a good idea to verify that it works with , too. Powerlevel10k emits OSC 133 if users explicitly request it with , or if they activate the built-in shell integration in their terminals. Powerlevel10k detects the latter, undoes the damage if necessary, and turns on its own OSC 133 implementation. Currently this is implemented for iTerm2 and Kitty and I could implement the same logic for vscode: If is set when powerlevel10k is sourced, unset it and enable OSC 133. Does this sound reasonable?
I installed the stable build of powerlevel10k and never seems to work, turns on OSC 133 though. when the one is set works fine. That's perfect . We have started using that variable to prevent recursing or calling the scripts multiple times, ie. so it works when it's injected by VS Code and installed manually:


When I press Ctrl+Shift+P to open the command panel and type "", it shows "No matching commands". So I can't execute this command by Ctrl+Shift+P. I can only bind a shortcut key to this command and then execute it via the shortcut key. I think this is a bug that the command panel search is incomplete.
Please edit this issue title to become:
indicates it may already be there and you just need to know what the command text is.
OK, but according to my observation, there are other commands that cannot be found in the panel. For example, "".
The issue I raised is different from him. His issue is that the shortcut key does not work after binding. My issue is that I can't find the command in the command panel. In fact, some other commands cannot be found, indicating that the search of the command panel is incomplete.
Some commands never appear in the Command Palette because they define their clause as
I open the page where I set the keyboard shortcut and see that their when clause is - not false.
Sorry, I wasn't clear. This is what I am referring to.
I read your link and I probably understand. Please set the when clause of "" to "inDebugMode" instead of false. This is more in line with our needs.
Looks like that command is missing from here: is also missing.
/confirm
I will submit a PR
Thanks!


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66 OS Version: Windows 11 Steps to Reproduce: diff view to revert the output changes :bug: after reverting the diff view still says there are deletions/additions output changes using the diff view :bug: stage the file and reopen the diff view, all the changes I reverted are back


Ref: I would expect the comment editor to behave just like a regular editor window, but in my case it is not. I don't hear screen reader feedback as I move through words and lines with the keyboard. Also, when I press a routing cursor key on my braille display, it does not move the cursor to the desired character. Tested with NVDA and JAWS. Invoke the action to leave a comment in the current line Write some text Use ctrl+left and ctrl+right to move through words Use up and down arrow keys to move through lines If you have a braille display with routing keys, press a routing cursor key to move to a specific character in the text


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.66.1, 1.66.2 OS Version: Ubuntu 20.04.4 So the issue I'm having is as an extension developer (). I've had users report an issue that I have tracked back down to vscode - I can confirm the issue on the above versions, but don't know the full extent on other os versions. () The error being received is: "Input is not valid base64-encoded data." I've tracked this down to getting the secret from secret storage (). I use the SecretStorage api to securely store credentials used by my extension. The api docs don't seem to indicate a change - but something appears to have changed (whether by design and the docs need to change, or by introducing a bug). The issue does not appear to affect vscode 1.66.0 - reverting to that version allows it to work. I do not know whether it affects whether it affects secrets - but can confirm on secrets. Steps to Reproduce (with referenced extension - so far): In vscode 1.66.0 - with extension, create a db connection with pwd to store creds (without pwd won't use store creds so it won't use the SecretStorage) Upgrade vscode to view the connection explorer and it will error when attempting to pull the secret from storage.
can you help me triage this. Not sure who owns it.
was the above steps tested with snap build or Debian build ?
Snap
The problem is that encryptionService was not working with snaps before as seen in , with we made some changes to our native dependency that now enabled the encryption service for snaps as well. So previously unencrypted data are thrown as error. Migration: 1) At the encryption service layer, encrypt before decrypting for snaps 2) At the extension level, store the secrets again with before retrieving it (not sure if this is possible unless the extension could retrieve the stored data outside the service)
Ok, that may explain the issue, and I can confirm this is not broken on Windows. Is there a way in the extension to detect installs via snap?
I have a fix^^ out for this. It will be included in 1.67 which should be released early next month. If you want to workaround this, first catch the SecretStorage Error and do one of two things: Ask the user for the thing you stored in SecretStorage again. Easiest to implement... inconvenient for the user. Temporarily (just for 1.66) include in your project and read the secret directly using the service will be: (exactly) and then the account is whatever your key is. Once you get that secret value, store it back using the API to prevent future errors. Very inconvenient for you, but the user doesn't have to do anything. Personally, I recommend the first one, because the second one can be very tricky... and you probably generally wanna be robust if getting the secret fails (like if the user locks their keyring for some reason... keyrings are very tricky).
Verification (on Linux): install stable Snap v1.66.2 Log in to GitHub for settings sync or extension Close vscode Update to latest snap (v1.67.0) When you launch VS Code, you should still be logged in to GitHub
those steps didn't work for me, I was signed after installing that snap <img width="979" alt="image" src="https://user-"
updated to a newer stable build liked above. Can you share whats in GitHub Authentication Output pane?
doesn't seem to work for Will need to investigate further but don't think this needs to be a candidate.
Maybe this revealed other issue - but I can confirm with 1.67.0, my extension appears to be working again.
and now I am seeing (in 1.67.1) a new error "Cannot get password"
Can confirm the issue from Github Authentication log fails with the error
Ok I have a fix for this. Unfortunately due to the nature of this fix, I was unable to migrate secrets from older versions forward... but at least going forward, we shouldn't see any issues where secrets can't be decrypted after an update.
Verification is weird but here it is: On Linux remove all VS Code stables snaps or debs Now install the latest unreleased main stable candidate snap (Like on the builds page) - Open it, log in to anything (GH/MSFT for settings sync for example) Close vscode Now install the stable build that is built on my branch () (all this branch does is revs the version to 1.69) Open it, and verify that your login persisted across versions
Ok, just got the update to 1.68 - this is still an issue. I'm not familiar with your merge process, but it looks like the PR that was linked here for excluding from the snap package was closed without merging. Is this still coming? It's almost been 2 months since my extension has been working properly for Snap users.
maybe my message: wasn't clear. You will see this issue in the 1.68 update. However, going forward, you shouldn't see it. 1.69 should not have this problem.
Thanks, so right now the password hasn't gotten migrated, and right now we are getting the , if I understand correctly in 1.69, this issue should disappear - will it still attempt to decrypt the password and then error, or will it just starting working. If it's going to error, what should I tell the users of my extension? I would assume that the password would have to be re-entered and then it would get stored in the new way and start working.
Ah that's a good point... I did not clear the password after the fact. I should do this. That password is essentially dead at this point so it should be cleaned up. Yes that's correct. If you overwrite the password using the SecretStorage API you should be good to go. I think this is generally a good practice to handle when SecretStorage doesn't return an expected result because there are a lot of layers all the way down to the OS that need to work.


The issue is that when I resize the page to see it along with other content, I can see some text over the scroll page area. I think it wasn't supposed to work like this, that's why i'm reporting it here. ! ! .
The scrollbar is intentionally transparent. We have a color that is used only when the minimap is enabled. We could potentially use it always if set to allow defining opaque scrollbars.
Oh. Thank you for explaining :) In this case, sorry for bothering! Best, Alvaro
To verify, configure the color and that will be applied and will make the overview ruler opaque. e.g.


Import following settings profile Timeline and Outline views are not updated. Refreshing the window updates the views. Expected that Timeline and Outline views shall be moved together into sidebar as a separate viewlet
Reopening this and making this a dup of because this is not completely fixed.
/duplicate


Issue Type: <bBug</bany command line run or pipe another process that runs indefinitely to that a window does not open and the command does not return. The file should open and update as new data is piped to the code cli command. This works on the Mac when you run but does not work on Windows. This is not a 1.67.0 regression VS Code version: Code 1.67.0 (, 2022-05-04T12:06:02.889Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
This is probably related to the file watcher not recognizing changes to the file on Windows, have to debug why that is the case but might be a limitation of the single file watcher.
The underlying reason seems to be that writing to a file via stream API where the file handle is not closed does not trigger file events on Windows at least. Maybe as a workaround we have to use the less efficient method that opens a file handle each time and closes it.
<!-- 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 am still experiencing this issue on the version of insiders below. Version: 1.69.0-insider (user setup) Commit: Date: 2022-06-24T06:32:08.615Z (13 hrs ago) Electron: 18.3.4 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0.
Here is how to verify: ensure you are on latest insiders from a terminal on Windows run verify output is updated
I tried on the latest insiders with that command and vscode-insiders still does not not open for me. If I run it hangs and never opens vscode-insiders If I run without the -t flag, it will open after the command completes. Version: 1.69.0-insider (user setup) Commit: Date: 2022-06-27T07:59:47.622Z (10 hrs ago) Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0.
This works for me on Windows 11 with both Powershell and , but may need further investigation


Issue Type: <bBug</bthe editor language to C++ to to /paste the Sample code below the editor window so that it is narrower than the line of code provided that the horizontal bracket underline stops at the end of the first line, when the (soft-wrapped) line break occurs. to that the horizontal bracket underline now continues onto the wrapped second line. VS Code version: Code 1.67.0 (, 2022-05-04T12:08:42.978Z) OS version: Linux x64 5.17.4-200.fc35.x8664 Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
! !
Update: Note that this only occurs if the wrapped line starts in the left-most column. Indented, wrapped lines are not affected, regardless of setting.
Thanks for reporting this! I think it shouldn't be too hard to fix. If you like, we'd be happy for a PR that fixes this!
Hi, I found the snippet that produces the bug: The if statement controls if the first character of the wrapped line is in column 0. If so, then it ignores the guides for that line. By simply removing the if statement the result is the following: ! It seems that this solves the bug. Given my limited knowledge of the codebase, before opening a pull request, it would be better to clarify the purpose of the if statement as it is not fully clear to me. Should it suppress possible vertical bracket guides in case of wrapped lines? Was it to address a specific bug?
I don't know anymore. Since unfortunately I didn't link that comment against any issue nor git blame helps here, lets just remove it and see if someone complains.
I think I've solved it. You the comment in ("Implement line scopes."), which was a month before the implementation of horizontal guides (in ). So, at the time, it made sense, but horizontal guides invalidated the logic the check was based on.
(Oh, and nice find, Thanks for finding and fixing this.)


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --<!-- 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. --In Visual Studio Code 1.65 and earlier, icons by extensions to the debug toolbar were dimmed when disabled: ! But in Visual Studio Code 1.67.0, icons by extensions to the debug toolbar are no longer dimmed when disabled: ! I am working on an extension which adds icons to the debug toolbar, using the . The icons are disabled while the program is running, and enabled when it is stopped. A typical icon definition looks like this: with a corresponding definition in the : It seems that Visual Studio Code 1.67 no longer provides a way for extensions to vary the colour of toolbar icons when they are disabled. Looking at the Visual Studio Code source, it seems that the built-in toolbar icons are created like this: and then styled like this: but I cannot see any way for extensions to access this functionality.
I see this, hey this is from . Seems like this will work for codicons but not svgs. Any idea how to deal with that? We could add a new class to svg icons so we can keep the opacity rule, if that helps. This probably applies to all toolbars, besides the debug one.
In the short term, restoring the opacity rule for SVG icons makes the most sense. But in the medium term, it would be nice if extensions had a way to access codicon-like behaviour, perhaps via the . At the moment there is no way for extensions to vary the colour for icons defined via this contribution point, but built-in icons use in their SVG, with the colour being specified via CSS.
Thanks for catching. Raised a PR to revert back to a slightly updated opacity rule for the moment. can you clarify what you're hoping to achieve re: codicon-like behavior? Are you hoping to use theme tokens in your contributed SVGs?
Let's take this as a candidate. Could you also prepare a PR against the release branch?
Thanks for the super-quick fix! Look forward to trying it out in 1.67.2 (I assume). Concretely, what I would like to achieve is to be able to put icons in the debug toolbar that look like this when the program is stopped: ! and like this when the program is running (where grayed-out icons represent commands that are temporarily disabled): ! In these screenshots, six of the commands are using bulit-in icons (Continue/Pause, Step Over, Step Into, Step Out, Restart and Stop), and the other eleven commands are using icons defined by the extension. I would like the two sets of icons to match in style if possible. If I can choose colours from the user's theme, that would be perfect, but I don't mind exactly how the functionality is provided: you know better than me what implementation would make the most sense.


<!-- 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. --Same issue as , the tag is being to the repository again. Breaking automated tools like Renovate Bot thinking that there is a new version to update. <img width="934" alt="image" src="https://user-"
Is there a way a GitHub action could help identify who pushed the tag and delete the tag automatically? /cc
We can id the tag and ping the creator, we don't give our Actions git write access so can't go and delete the tag automatically.
Deleted tag manually, action to ping the pusher upon pushing it back to the repo.


Issue Type: <bBug</brun in the terminal where is the path to an existing directory see VSCode open the workspace as expected run in the terminal where is the path to an existing directory focus changes back to VSCode, but showing the window for project instead of project Here is a movie of the experience: ! In previous versions of VSCode, when opening a new project with , the new window would show up above any existing windows. This is what I expected to happen. VS Code version: Code 1.67.1 (, 2022-05-06T12:37:14.619Z) OS version: Darwin arm64 20.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ vscode-tailwindcss0.8.3 vscode-eslint2.2.2 copilot1.19.5865 go0.33.0 terraform2.22.0 vscode-env0.1.0 jsonnet-language1.0.0 vscode-docker1.22.0 python2022.6.2 vscode-pylance2022.5.1 remote-containers0.234.0 remote-ssh0.80.0 remote-ssh-edit0.80.0 excalidraw-editor2.0.16 code-spell-checker2.1.11 svelte-vscode105.16.0 cython0.1.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Looks similar to and .
Same issue. On Mac OS, VsCode 1.67 How to reproduce: shortcut to open new window <kbdCMD</kbd+ <kbdSHIFT</kbd+ <kbdN</kbdshortcut to open new file/folder <kbdCMD</kbd+ <kbdO</kbdThe selected file/folder is now opened in the previously focused vscode window instead of the newly opened one. To solve the problem, you have to think to click in the newly opened window. When you do so, you see the focus takes effect, proving the window was not actually focused (EDIT: What is confusing is that you can see the cursor blinking inside of the editor of the new window, even though it is not focused) I can tell this is a relatively new issue (1 or 2 months max), because I'm doing the procedure above almost every day and it has been pissing me off since then (sorry, but truly annoying).
Sounds a bit like or
Do you have configured?
This is a regression from
Thanks for the fix!


https://user- Steps to Reproduce: the panel, see the comments tab the comments tab, reload the window :bug: comments panel keeps re-appearing Version: 1.68.0-insider (Universal) Commit: Date: 2022-05-13T17:25:40.854Z Electron: 17.4.3 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin arm64 21.4.0
does the file you have open have a comment in it? We show the comments view the first time you open a file that contains comments (once per reload).
no comments, regardless of what workspace I am in it always appears (even in an empty workspace) <img width="475" alt="CleanShot 2022-05-31 at 08 10 17 src="https://user-"
I'm not sure what's going on here, maybe you know. The Comments view is actually registered with , so I'm surprised it's even possible to hide the view. Is there anything else I need to do to prevent it from hiding or, even better, to respect the hide after reload?
The action takes is hiding the View Container so that's why it is hideable. There isn't anything that you can set on the View Container to prevent the hiding. I am also at a loss. can you "Export Settings as a Profile"? the profile should have the stored information about your views and view containers
hmm I don't see anything alarming in there, but I can now reproduce it ... but I don't get it in an empty workspace
is there any logging that can be in views to help narrow this down? I don't think there's anything else I can do from comments.
after lots of debugging, I think I have a fairly simple fix in the PR above.


This is a continuation of A unit test shouldn't take longer than 50ms. An easy way to "speed up" setTimeout and friends is -utility To reproduce these numbers run open the file and remove the first non-json lines run[x] 51ms, MarkdownRenderer Code block renderer asyncRenderCallback should not be invoked if result is immediately disposed [x] 104ms, MarkdownRenderer Code block renderer asyncRenderCallback should not be invoked if dispose is called before code block is rendered [x] 55ms, ExtHostAuthentication Can get multiple sessions (with different scopes) in one extension [x] 55ms, ExtHostAuthentication Can get multiple sessions (from different providers) in one extension [x] 60ms, ExtHostAuthentication clearSessionPreference - true [x] 72ms, ExtHostAuthentication silently getting session should return a session (if any) regardless of preference - [x] 93ms, Editor Controller issue : Greater than 1000+ multi cursor typing replacement text appears inverted, lines begin to drop off selection [x] 51ms, Notebook Find Update find matches basics 3 [x] 53ms, Notebook Find Update find matches basics [x] 51ms, Notebook Find Update find matches,
Thanks - for fixing tests in UserDataAutoSyncService
Made IndexedDB tests faster but not fast enough to finish within less than 50ms. Because the bottle neck is IndexedDB. Any write transaction in IndexedDB is taking ~20ms and couple of tests need at least 2-3 write transactions. Hence checking off IndexedDB tests Before ! After !
I think tests like that which still take a long time should be renamed to
Okay. Only couple of tests are taking around 80ms. But since the cut off is 50ms, I see I do not have option other than changing them to integration tests. So changed it.
Any reason I was assigned back?
Sorry, my bad
fyi - list starts now at and I have re-assigned some folks
It seems you overwrote the checkboxes
These are new checkboxes, everything slower than 125ms - I copied the list from the collapsed section
Sorry that I am confused. Following tests are fixed before and they were checked off. tests were fixed before and tests are moved to integration tests . You can see the updated results when I run locally: tests are not taking more than 125ms and tests do not exist. <img width="1134" alt="image" src="https://user-"I am not sure if I am missing anything here Anyway, I have made tests much faster
Its also weird that I do not see any collapsed sections in my browser <img width="976" alt="image" src="https://user-"
I read through and couldn't find any of my tests. I think this is a case of "wrong Alex".
A bunch of tests that were using fake timers, like the one, got faster after
Some observations after having looked into mine: in some of my slow tests I tend to do many assertions in a single test as opposed to doing 1 assertion per kind, as such I now split these tests up into smaller chunks but this will obviously not reduce overall execution times in some tests I was able to squeeze out a bit more by doing instead of awaiting promises one by one I attribute slowness in my tests mainly to the fact that: I access the disk (because I actually want to test APIs or native behaviour) I access a native library such as SQLite I was trying out the fake timers thing, but obviously that does not help a lot for disk access or native libraries. Bottom line: if we want unit tests to finish in range then I think we need to pull out all unit tests that test disk or native libraries into a new suite that is either integration tests or can be controlled by some flags. I am not a big fan of integration tests mainly for the reason that I cannot run them as nice as I can with our test runner support (I brought this up in our standup to Thoughts?
One thing we noticed is that quite some tests use the . Those will surely benefit from an InMem-provider <img width="944" alt="Screenshot 2022-06-09 at 15 21 59" src="https://user-"
This would also be less of a problem if we were able to run tests in parallel, as slow tests are usually not computationally-blocking slow tests. Mocha does have a flag that runs all tests in parallel, which may cause breakages. Vitest/jest allows explicitly marking tests as parallel-capable via . Maybe we could do something similar.
I second this. I agree we need to test the , but that's a single test suite in itself. Every other component should be unit tested with a which doesn't use any IO. If it's required that they do, I argue that is the very definition of integration test.
fyi - I reran the data extraction and updated the main comment here
Working on a couple of things with more adoption of figured out that we run a for every to ensure data is flushed to disk which makes writing slower and figured out a way to disable this for most tests except the ones that want to test writing specifically adopted scheme for some of my tests and even found a bug in our in-memory fs-provider Before: After:
Maybe after my PR landed, the list could be regenerated.
May be its better to switch to use fake timers by default for all tests?
Mine will be addressed by moving to integration via I found new ones in notebook land, adding I have asked to support our selfhost test extension showing test decorators in files because one papercut I have is that I can no longer use the selfhost test extension in those test files.
we should action these as part of this issue: <img width="837" alt="image" src="https://user-"
Excellent في الجمعة، ١٢ يناير ٢٠٢٤، ٣:٢٧ ص Matt Bierner


<!-- 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.67.2 OS Version: Windows 10 TL/DR: When saving untitled documents that have name with extension, the proposed file name is not the same and can be completely different: -(I do not have a file with that name ANYWHERE on my PC. I have somewhere though) -Steps to Reproduce: Issue 1: extension command that executes the extension and activate the command to get a new untitled file tab to save the file. The proposed filename is despite the original Untitled file name already ending with which is a valid extension for YAML files Issue 2: extension command that executes the extension and activate the command to get a new untitled file tab to save the file. The proposed filename is , which is unexpected and very surprising. I do not have a file with that name anywhere on my PC. I have somewhere though. Note that the VSCode- extension is here despite VSCode detecting the file format as YAML based on contents. I expect that when saving the file VSCode proposes my given filename and extension to the user. I expect that when saving the file VSCode does not propose completely unrelated file names like .
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.67.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Here is how to open an untitled file with associated file path: As for being able to suggest an extension, here is the related issue:
There are certain cases where the proposed solution might not work. The solution requires an absolute file path, but it's not always available. For example, with VSCode Web the workspace might not contain any directories.
I've tested your suggestion and it does not seem to work. The following code still proposes the file name with double extension: does not work either. This bug really breaks the CustomEditor extensions. The saved file is no longer associated with the custom editor due to the mangled name/extension. More so, the Custom editor immediately closes upon saving the file. So the flow becomes: /New File.../ Pipeline on building a pipeline in the custom editor. -VScode prompts for file name suggesting . The user clicks OK immediately closes the custom editor and reopens the file using the text editor (since the file name no longer matches the extension)
Moving to custom editors team for this case.
I think part of this issue is triggered by language detection. I have a hypothesis that the extra is /triggered by the YAML language detector. When the file contains binary data the issue does not seem to be triggered. (I've tested on the modified PawDraw extension modified to propose the file name)
I've just verified the hypothesis. I've modified the CatScratch editor to use the extension and "New Cat Scratch Document" command based on PawDraw. The issue started betting triggered (proposed file name). So the issue is triggered when the document contains valid YAML data (with includes empty file), but does not trigger when the document contains invalid YAML (e.g. binary data).
This also might be related to the "Duplicate editor tab" bug I've previously opened: I've recorded the video that shows both bugs: https://user- See how with first click on "Scratch" another tab opens (with text editor). When saving the custom editor tab, the tab closes (due to the bug we're currently discussing: ).
Repro branch:
me because Ark-kun mentioned language detection... and I own the ML language detection but this has nothing to do with that from what I can tell... it also is easily reproducible without custom editors as the original issue describes. I this to an barebones extension: With the behavior I get when I save the file is: ! Now if I change it to I get: ! I have no idea what is suppose to be. Trying a different file type (which is a language we ship a grammar for) I notice that this does in fact work as expected: ! So with this said, my suspicion is that something is up with YAML... I noticed I had the Python extension installed so I disabled it and well well well: ! So one that needs to go to the Python extension: "don't clobber the YAML file association". Looks like there are several instances of that in the extension: As for why becomes I'm not totally sure... but a discovery I made was with this list: in the built-in YAML extension (which just provides syntax highlighting). is at the top of the list. If I move to the top of this list, suddenly, this works: ! So two is "all possible extensions should be taken into consideration". I think you own this? What do you think?
nice analysis The issue here is that our logic for figuring out a file name for untitled files is pretty weak: We basically just append the first extension for the language, but we can be smarter: preserve extension when it matches (same for languages that only have file names) actually replace the extension when it does not match so that we do not have 2 extensions piling up I think this fix addresses both issues but would be good to verify then. PR:
so then after this change, what the Python extension is doing is correct to associate YAML with a new file extension?
Yes I do not think that is an 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!


<!-- 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. --The vscode shell integration currently needs to be turned off or disabled for anyone with complex prompt commands, or any trap DEBUG. Please consider supporting some kind of chaining model so we can work with the shell integration as needed. Even better - use the defacto package that has already been written. VSCode is the 3rd script that wants to mess with prompts and traps - but it's the first to completely ignore Please consider shipping this along side and sourcing/using it. If that is unacceptable, consider at least detecting this module has been loaded as documented in the repo - and using it: fwiw: iterm2 has very very similar functionality to the vscode shell integration, but I've been able to work with it. Although they embedded the script directly, they kept the compatible function names and mechanisms and interop fine.
I believe we have already fixed this: Adding to make sure
Well, line 100 breaks my prompt. Adding the line as the 1st line of vscpreexec shows why. I think perhaps there needs to be 1 more state 'not in prompt' that causes preexec to bail until all promptcommand processing is done. Alternatively, if this is all to send vsccommandoutputstart - it seems like using PS0 on bash = 4.4 would be a lot cleaner?
Hi This was on 1.67.2 with dropped in place.
We've made some big changes in the past few days around debug trap and PS1 handling in bash, I believe the issues here are fixed. We may at some point hook into similar to but for now that will just increase the number of cases we would need to test for (contributions very welcome).
Actually I'll keep this open with help wanted to track integrating with bash-preexec.
OK. Pulling the - Things look better, but not quite right. The problems I see (only when DEBUG trap is being used): Still seems to be not preserving $? for promptcommand Seems to execute the trap twice. repro with setup instructions below: Do 'cd' into some directory. The command '..' should then pop one directory up, but it will try to process twice and pop twice. Instead of 'success dots' in the gutter, all commands seem to think there are fail exit status. Here are my dotfiles: and a branch to help debug: The debug branch just build an array of what commands were that triggered the trap and print them at the start and end of building the prompt. It does show the trap being called twice when shell integration is enabled - and once otherwise. The repro environment/steps: Repros in OSX and WSL Ubuntu 22.04 for me. It uses dotbot. In a scratch user directory you can run ./install to link everything into ~/. Pass to ./install to avoid installing extra tooling it finds missing (pygments/tmux/coreutils)There is a script that get's sourced . This is the root of all evil. It's on the hacky side. The function is small and is (I believe) the only relevant part. I should stop using it, but it's sooooo_ ingrained into my muscle memory. To verify: Removing from makes everything work great with none of the above mentioned problems. One hack, that seems irrelevant is that uses debug trap directly, but also detects and uses the pre-exec infrastructure if it has been loaded (to not break iTerm2's shell integration). I appreciate the time and effort going into this feature. It's becoming a shockingly advanced embedded shell environment.
thanks again, planning on tackling this in June
I use just merged in a fix for this. It would be great if someone could help verify in tomorrow's insiders build as I'm not normally a user of bash-preexec.
Still some problems around . Very simple repro: clean environment. My bash and vscode versions are: use this .bashrc: For me (In WSL, repros in plain OSX): ! Without ! If extdebug works, then this would be the next simplest test (I think). Same clean environment. The following
Are there verif steps for this?
<!-- 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!
With the more complicated scenario, the decorations don't seem to show blue and red anymore. ! I realize that in the screenshot I forgot to add , but that didn't make a difference.
what is your exact debug trap when that happens?


I am the maintainer of VS Code basic latex language support. The language defines / as a bracket pair. This leads to wrongly highlight <img width="415" alt="Capture d’écran 2022-05-26 à 08 07 09" src="https://user-"I believe this is related to fixed it in by surrounding brackets using letters only with . However, in LaTeX every command starts with and the fix does not apply. This issue occurs on Version: 1.67.2 and also on Version: 1.68.0-insider (Universal) Commit: Date: 2022-05-25T05:16:10.689Z Electron: 17.4.4 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin x64 21.5.0 This problem was originally reported at
should be extended to check if the bracket starts/ends with a word. Only at those borders, should be . Should be easy to implement. I'm open for a PR here ;)
hey I am a beginner in open source contributions . Could you please guide me how too start contributing
I'd start here:
Hi I'm just starting out with open source contributions and just finished reading the how to guide you linked in this thread. I'm having some trouble understanding exactly what the issue is, could you please explain it a bit more? Is rangledot supposed to be highlighted as a whole?
This issue is actually already handled by PR , which will be merged for the July 2022 release.
Verification steps: Install the LaTeX extension Verify that and is matched, but not with in
I would personally highly go against this fix As it would disallow word based brackets inside word strings with no alternative (other than to reinvent the bracket highlighter again) I have no example of any language being affected But I would question the arbitration decesion to limit such function Instead, I think LaTeX should fix their bug (which was present before coloured brackets) by just disallowing/allowing certain word based bracket scopes via the and sections in !
Let's discuss this in a separate issue once this actually is a problem!


Testing Version: 1.68.0-insider (user setup) Commit: Date: 2022-05-31T05:17:04.479Z Run the command and select Would be nice to get a message in the log
Looks like the the message is not shown as it is of type and is less than than. Would be good to always show it, regardless of the current and the new level. Same problem with the initial message when the output is started.


Testing Things I would change: make it clear in the picker that selecting a language from the lower list will install it have a button in the picker that installs and syncs it. don't reveal the extension viewlet don't show that dialog <img width="444" alt="capture" src="https://user-"
is there a way to not show this dialog when installing an extension using the Extension management service? Here's the specific line:
How would you make this clearer? I figured since we had a section called that will always be there on Desktop it's implied that must not be installed. What will the default behavior be then when you accept a quick pick item? That it will install but not sync? That's not what the default is for the button in the extension pane so that seems a bit odd to me. This was to give a progress indication. We do the same thing for the Theme picker. I would like to hide this dialog. I didn't see it locally because Settings Sync isn't available in but I asked Sandeep above.
Yes, you can pass machine scoped flag to avoid this. Passing for this flag will not sync the extension and will sync it.
I thought the main reason for the dialog was to inform the user that something is installed. I can easily live with only the picker Since the dialog offered the option, I thought it is important. I can live with the default without a choice. I found it disturbing. I could live without progress or some window progress.


! I see this sometimes, but it often gets fixed if I try again, or close and reopen the editor, etc. Right now it keeps happening and it's just impossible to click the hover. I don't know how this API works but I assume this is on vscode's side. Happy to set breakpoints and debug
I couldn't reproduce this so I'm not sure what's the root problem. However, I'm saving here a patch which simulates a hover very similar to the one in the gif: <img width="1141" alt="image" src="https://user-"diffn- editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n+ await editor.focusNotebookCell(newCell, newFocusMode, { focusEditorLine: 1 });n
I tried for quite a while but couldn't repro. I think there might be some settings that cause the issue reproduce. Does this reproduce when you comment out all your user settings?
Yeah, it reproes with all settings commented out
Thanks to via we could find a repro. Reproduces consistently when hovering at the end of the line: It turns out it has to do with the range the hover provider returns. If the hover provider returns a range that spans one line above the hover request, the hover will render one line above. If the hover provider returns a range that spans two lines above the hover request, the hover will render two lines above, etc. Here's a simplified patch: https://user-
To verify, use gitlens and hover over the end of the line at
Works great but raises the question, why does gitlens return a hover with a multiline range? And I get a highlight in this region, but it blinks and disappears on line 919, and on other lines, no highlight. !
PR to improve the highlight range at
I'm still seeing the original issue at


While verifying I noticed that if I click on the warning I'm not taken to the size limit setting which I would've expected to be taken to. ! Version: 1.68.0-insider (Universal) Commit: Date: 2022-06-02T05:16:30.515Z Electron: 17.4.6 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin x64 21.5.0 Jupyter Extension version (available under the Extensions sidebar): v2022.5. Python Extension version (available under the Extensions sidebar): v2022.7.
This link is specified in core code.
The issue doesn't seem to be fixed in the latest insiders. Reopening
The issue is now fixed for me in the latest Insiders, at least on Windows 11.


Open the color theme picker and select the first option () Observe that it takes around 5 seconds for the results to show. This used to be much snappier


!
Think I saw this today
that was when I here, which causes other issues so i'm removing
working on it
repro is to create some decorations via commands and then delete the terminal


!
This happens because command executed happens but not command finished
And that's because of this:
nice, the fix works https://user-


If a password is not decrypted properly, then it should be removed from the secret storage because it's essentially dead. Originally posted by in
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Verification steps: grab and install in VS Code Insiders Run command Follow the notifications ping me if you have any questions or issues.


Issue Type: <bBug</bI do not see the error or success icons for the gutter icon on my shell integration enabled terminals; instead it is always the empty circle. The integration appears to otherwise be working (the Go to Recent Directory and Run Recent Command commands are working as expected). I presume that somehow, the integration is not picking up the result of the operation being run. For reference, I am using but otherwise don't believe I have anything special in my Bash configuration that would affect this. VS Code version: Code 1.68.0 (Universal) (, 2022-06-08T11:44:00.250Z) OS version: Darwin x64 21.5.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (76)</summaryExtensionVersion ------ Bookmarks13.3.0 project-manager12.6.0 vscode-sqlite0.14.1 atlascode2.10.12 github-markdown-preview0.3.0 jsdoc-markdown-highlighting0.0.1 markdown-checkbox0.3.2 markdown-emoji0.2.1 markdown-footnotes0.0.7 markdown-mermaid1.14.0 markdown-preview-github-styles1.0.1 markdown-yaml-preamble0.1.0 gitignore0.7.0 vscode-markdownlint0.47.0 vscode-eslint2.2.2 xml2.5.1 gitlens12.0.7 EditorConfig0.16.4 graphviz-preview1.5.0 flow-for-vscode2.1.0 vscode-mysql0.4.1 copilot1.28.6134 remotehub0.34.0 vscode-pull-request-github0.44.0 go0.33.1 todo-tree0.0.215 triggertaskonsave0.2.17 vscode-guid1.4.20 path-autocomplete1.19.1 tablegenerator1.0.4 plantuml2.17.2 svg1.4.18 docthis0.7.1 vscode-position1.1.2 yarn-lock-syntax0.1.3 Kotlin1.7.1 vscode-language-babel0.0.36 pull-request-quantifier0.1.2 extension-manifest-editor0.1.5 csharp1.25.0 dotnet-interactive-vscode1.0. network-edge-devtools1.0.0 data-workspace-vscode0.2.0 mssql1.14.2 sql-bindings-vscode0.1.0 sql-database-projects-vscode0.16.2 vscode-postgresql0.3.0 python2022.8.0 vscode-pylance2022.6.10 jupyter2022.5. jupyter-keymap1.0.0 jupyter-renderers1.0.8 hexeditor1.9.6 powershell2022.5.1 remote-repositories0.12.0 vscode-js-profile-flame1.0.2 vsliveshare1.0.5615 vsliveshare-pack0.4.0 resourcemonitor1.0.7 vscode-commons0.0.6 vscode-yaml1.8.0 sass-indented1.5.1 gitconfig2.0.1 mdx0.1.0 codevalet-vscode1.5.0 vcl0.1.2 msbuild-project-tools0.4.3 jest-snapshot-language-support1.1.1 intellicode-api-usage-examples0.1.1 vscodeintellicode1.2.21 vscode-icons11.12.0 quokka-vscode1.0.478 wallaby-vscode1.0.338 jinja0.0.8 ReactSnippets2.4.0 vscode-proto30.5.5 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details


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


Issue Type: <bPerformance Issue</bTerminals doesn't seem to free all GPU memory when closing them, making alt-tabbing from another application to vscode slower over time, there are other tickets around vscode freezing when alt-tabbing back to it and this seems to be one of the reasons as Windows needs to load/unload 1GB+ of GPU memory when alt-tabbing occurs. One way of reproducing this: 20 integrated terminals the terminals again (now only welcome screen open) Windows task manager -Performance tab something covers vscode completely (i.e. task manager is maximized) the GPU memory usage is 500MB+ lower than if vscode is visible (i.e. task manager is not maximized so it doesn't cover vscode completely, forcing Windows to keep vscode GPU memory active). scales linearly if you open more terminals, i.e. 40 terminals keeps 1GB+ of GPU memory even when they are closed I can reproduce it on the insiders build as well, so Electron 18 doesn't seem to solve this issue. vscode visible (2 GB GPU memory usage at the bottom of the screenshot): ! vscode still open but behind other windows (1 GB GPU memory usage at the bottom of the screenshot): ! VS Code version: Code 1.68.1 (, 2022-06-14T12:48:58.283Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<!-- generated by issue reporter --
I tried to repro with stable, but I wasn't able to. What are the steps for verification?
<!-- 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!
Hello, I'm waiting for these to cleanup the terminals properly: But as I am the author of those PRs I don't think additional verification is needed from me once they get merged.
fyi I think I noticed a few bugs about alt-tabbing being slow


Previously the terminal could be resized fairly quickly, to see what's going on and then hide it again (with 2 lines still visible). With the new update however, it can only be resized by one line per keystroke. So in order to use the terminal adequately, there are 10 - 20 keystrokes required, which is unacceptable (in my opinion). It would be great, if you could specify "args" for the command which control how many lines the terminal is resized by. Similar like the cursorMove command: Thanks for consideration, Floyd Haremsa <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. -→
I'm not sure what you mean. changing the height of the panel? https://user-
Yes, changing the height of the panel, but with keyboard shortcuts. Previously it worked pretty well (changing the height by lets say 10 lines, I don't quite remember). But now you can only resize by one line at a time (per hitting the keyboard shortcut), like this: https://user- and that is just way too slow and inefficient. This way I'm forced to resize it with the mouse (which is also too slow) or having it open all the time, which is bad on small screen sizes. Sorry for not having it clarified enough earlier.
we think this is related to the increase view size change - thoughts ?
This is indeed caused by The new behavior is actually the intended behavior, but the terminal is in full control if it wants to have a number-of-lines-based resize setting.
I am also affected by this and it is crazy to work mouseless, resizing terminal is not viable with keyboard like this. Any work around?
how many rows would you expect it to change?
3-4 would be nice
I'd say about 7 - 10 lines at a time. But if I can control it my self, that's even better.
Also being affected by this. The terminal now resizes by 1 line at a time. Previously it was 9 lines (3072×1920 on 16" with terminal.integrated.fontSize = 13) Something in the range of 4-8 lines might be a decent compromise considering the original request that led to the change ()
I think the best approach would be to just have a default of let's say 4 lines, but also a setting that controls this, and/or as I mentioned, arguments to the command for being able to map multiple resize settings to different shortcuts:
I'd rather not add a setting for this as it's pretty obscure and would see hardly any usage. An additional complication here is I'd like to eventually remove the terminal resize commands since we now have the increase/decrease view size commands which weren't around when the terminal resize pane commands got . Seems like 4 rows should work for most people.
Can confirm this is fixed in Insiders. Thanks for the quick response


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Executing "Surround with snippet" from the command palette while there's no surround-able snippet, results in an empty pick list: ! Shouldn't it be like showing an information message saying there's no snippet to pick, or just not prompting the user to pick anything?
Prompt might be too annoying but quick pick itself might have a way to show a lightweight in-place message
Do you mean something like this (using )? !
Just submitted the PR. Could you please check it?


Ah, sorry for the breakage... I believe asking for both is the best option for now but I can also add a "migration" path into the implementation, e.g use when seeing Originally posted by in


I really like how I can see the word-level change per line now in the merge editor, but shouldn't the colors be identical to the diff editor? !
I agree the new color needs to be tweaked. Would you also use the green background?
I think making this look as close as a diff editor if possible would be nice because I am so used at looking at diffs with their color coding. //cc


Testing !
That's actually a description of what clicking the button will do. This was as designed but maybe has a better idea?
Same feedback from in
The "..." in "Show Command Actions..." tells me it's clickable. Just removing the "..." would help, but it still looks like something I want to click on.


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


Testing Current: ! Proposal: !
Spoke with and I have submitted to add the file icon association to seti-ui repository.


Testing When I use cmd+up/down to navigate between POIs in task output, the blue box renders for a second on the item I have selected, but then disappears. I didn't understand what was happening to the focus border.
that is by design.
This has come up before, I think you had an idea to improve this?
I had the same experience in where I was on a slow machine. I think I had suggested just using a line on the side (like our activity bar) that remains until your focus changes: <img src="https://user-"
To the left of the command decorations? ! I like how visible the outline is when jumping between commands, so we could keep that as is and just also show the persistent line? !
yea I'd be open to trying that out, I think using both might be a bit overkill but just having the single line can also be hard to notice.


Testing Clone a git repository Open git repository in VS Code desktop Make a change to one or more files Invoke the command You are presented with an empty picker <img width="736" alt="image" src="https://user-"


Issue Type: <bBug</bI opened theme extension and click enable / disable fast. I see "Set Theme" button when extension is disabled and no "Set Theme" when it is enabled. VS Code version: Code 1.68.1 (, 2022-06-14T12:48:37.209Z) OS version: Darwin arm64 21.5.0 Restricted Mode: No Remote OS version: Linux arm64 4.9.253-tegra


! cmd+f, do a search clear the text in the find input it says "0 of -1"
was this insiders or code - oss? If the latter can you make sure is updated?
need to see if this reproduces in OSS
doesn't reproduce in the demo... I think I updated before the PR checks had finished maybe so that fix wasn't included?
I tested with my branch of symlinked so that's probably why I wasn't seeing it
yep happens in OSS so the fix is to update in vscode


Issue Type: <bBug</bTesting I have Code Spell Checker () extension provides diagnostics without error code, and rust-analyzer extension provides diagnostics with error code. When all diagnositcs don't have code, it displays correctly. When some diagnostics have code and some don't, scroll over the Problems value, some code changes randomly. https://user- VS Code version: Code - Insiders 1.69.0-insider (, 2022-06-29T05:20:28.364Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (12)</summaryExtensionVersion ------ Bookmarks13.3.0 remotehub0.35. remote-containers0.241.1 remote-ssh0.83. remote-ssh-edit0.80.0 remote-wsl0.66.3 remote-repositories0.12.0 material-icon-theme4.18.1 material-theme3.15.2 toml0.6.0 rust-analyzer0.4.1110 code-spell-checker2.2.5 </details<!-- generated by issue reporter --


a folder/workspace that contains a git repository a topic branch changes to main and the topic branch that would result in a merge conflict main into the topic branch to get a conflict Expected: commit action button is disabled Actual: commit action button is enabled
The button is now disabled while merging is in progress, but the button and the dropdown both take on a background color when clicked, which was confusing to me: !
Also, while the commit action button is disabled, the commit button above the input box is not: !
That is expected. At the moment the enablement is only toggled for the commit action button and not the commit action in the toolbar.
This is currently being tracked as


See the grey row that moves up when it scrolls !
I looked into this a bit, but is this something that is within the tree code? Nothing sticks out to be surrounding us registering the drag and drop handlers when it comes to a focus, or hover rendering
The grey row is the CSS state which stays enabled throughout a native DnD, but stuck in the same position the event fired. It's arguably a browser bug. But we can eat it as a list bug. I see no other way than to disable the hover decoration while the list is being dragged from. Having both and labels is a bit confusing. Those are mutually exclusive.
Oh I always used polish to indicate something that is a small change (at least to the user) and then it's a bug because it shouldn't happen . Idk, I guess I'll stick with just bug


Lately (since a few days) I see the explorer show an expand all icon even though some folders are expanded (in a multi root workspace): <img width="300" alt="image" src="https://user-"This must be a recent regression, not sure if in explorer or tree widget.
See
This breaks my muscle memory, I always collapse the explorer to start a new task and the new behaviour breaks this. I really see no value of this new behaviour? It is not even expanding all folders, only the ones that can be resolved? What is the use case?
As a suggestion: only show the expand button when really all nodes are collapsed, but keep the collapse button when any node is expanded.
I'm with this is quite different behavior in a multi-root workspace, I have one workspace with 5 root folders and another with 10+, prior to this change clicking the expand/collapse button in explorer would collapse all the folders in each root folder, clicking again would then collapse all the root folders. What I get now is the following: If all root folders are collapsed, clicking the expand/collapse button does nothing If one root folder is open the expand/collapse button expands and collapses folders within that root folder More than one root folder open the same as before for all of the open root folders Perhaps we could have an option to opt-in to this new behavior, I can't think of a single reason why I would want to expand every folder in a project.
Feature got removed.


to start the default build ! This happened right after something strange, which might be the underlying cause. I had the build running already, the one with two terminals open. But I still pressed and noticed another two terminals showed up with the same build tasks! I closed them all. Then I pressed and ended up where the screenshot above shows. cc
I reloaded, then pressed before the workbench was done loading and got this: ! I waited a bit more, pressed it again and it worked. This is very likely a separate issue, so feel free to treat it as such.
might be a bug with the new reconnect?
Yeah I think I saw this once
That's exactly right. Steps: selfhost setup Shift B, you now have 2 build commands running VS Code VS Code, you still have 2 build commands running Shift B, You now have 4 build commands running.
C the old ones The new ones appear loading, even though they have finished compilation: ! Worse: the window horizontally, and eventually you'll get lucky and the spinning icons dissappear: !
it's not a new bug that you can launch tasks that are already running
If you press you should get the default build tasks, which are long running. If you press it again, they shouldn't be launched again and they aren't. This is good and expected. The bug is: restart Code (tasks now get restored), press and you'll get the same build tasks running again. This shouldn't happen: !
same root cause as , which is not new
This is my selfhost setup. I am 100% sure this is new.
the two bugs that you've identified here though are: the error about a terminal group command not found was already aware that statuses do not work after reload
in your old setup, run ctrl shift b, ctrl shift b again. you'll get 4
in stable !
I think you are correct it's a different issue. I see what's going on now.
might still be the same root cause, but i'll try to investigate for a bit
Thanks
could you pls verify this is fixed for you in insider's keeping in mind these two that I have a PR out to fix as well?
Sorry for reopening but I could still repro in today's build () very likely due to the . !
This is happening because this conditional is entered on ctrl+shift+b after reload: Looks like isn't restored on reconnect: !
The task has the wrong id? !
is persisted as a guid, not the expected string? !
It's the custom task with the same label that gets the uuid:
ends up returning true, that's why _id ends up as a uuid: The task's type is undefined after reconnection. It's mean to be , this is what it's meant to be: !
Note that this only reproduce for compound tasks.
That was a journey and I'm ready to throw in the towel for now. I believe the issue is either compound task state is not restored properly after reconnect here: And/or the recently used tasks cached value does not contain all recently used tasks as I only see the compound and Core - Build, no Ext - Build.
any thoughts would be appreciated. I spent ~ 3 hours on this and Daniel did as well.
I will take some time tomorrow to dig into it.
Some notes from debugging: When comparing tasks that come out of the recently used task list, they must be compared by their recently used key as this is the only stable id value (map key and task id can change). Instead of having a separate code path for reconnect, which is what is causing some state to be lost (like the ), if possible, it would be better to try the reconnect in the same place that we currently create a terminal. This would hook up all the needed state again and re-attach problem matchers. I've made an example PR here that starts to address the above points. Note that this is relatively untested, I just checked whether it fixes the problem described in this issue. Other notes: Using the recent tasks from the task service for re-connecting is problematic since users can use to entirely disable recent tasks. Instead, you will probably need a separate LRU that functions exactly like but is only used for reconnection. Tangentially related: you also need to nudge/rerun problem matchers on terminal lines that have already been written so that they can find their start pattern and the task doesn't have a spinner forever.


Steps: some changes on the "continue working on..." command and open in desktop :bug: VS Code opens but nothing loads https://user- Desktop Version: 1.70.0-insider (Universal) Commit: Date: 2022-07-26T05:17:37.262Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin arm64 21.6.0 Web Version: 1.70.0-insider Commit: Date: 2022-07-26T05:17:04.193Z Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36
This action should be disabled in since we cannot access the local filesystem from the browser.
I'm still able to run the command from insiders vscode dev in Firefox. My Desktop Insiders then opens the repo using remote repositories but on the main branch instead of the branch I was working on. I'm not sure if this is the expected behaviour
I verified that this now works as expected 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.69.2 OS Version: MacOS BigSur and Monterey Steps to Reproduce: Open a terminal editor. a file from Finder into the terminal. This tries to open the file (unlike when the terminal is in the panel, which will paste the path).
I found that if I prevent the following code from executing, it works. So it seems like prevents the following code to handle pasting the file path. I did find that if you hold Shift before starting to drag the file, it will paste due to this code: I'm guessing there's some way to get that to realize it's a terminal editor and return as well.
I submitted PR for this.
File is still opened
did you hold shift? That's the method of passing the file through to the editor
works correctly with shift held


! The settings to select an codicon for a decoration are not playing well with our product icon theming approach. We want that a product icon theme can style all icons of our UI with a new icons. Each icon that we show should be defined with a component specific name E.g. , , ... That way the theme can come up with a custom icon for each icon location The base icon names (, , ...) should not be used directly, only as defaults, otherwise it gets complicated for a theme to change an icon as it affects many places, unknown to the theme. What might look good with our codicon based product icon theme, might look wrong with a theme that uses a different visual for I suggest to remove the settings as we don't do that at other places. Instead we should refer to product icon themes as the way to change icons.
Requested the aliases in
We do allow switching icons for terminals in this way which I think is fine as they're very temporal: ! I see what you're saying here though, let's remove the setting and leave it up to the icon theme . We have this setting now so it solves that part of what these icon settings allowed:
I was on vacation so I couldn't jump in here. It was not necessary to request new codicons or codicon aliases unless a new icon shape was needed, e.g. for a concept we didn't have yet. There still seems to be a confusion of Codicons vs product icon icons. The Codicon library is a set of default icons that are part of the Codicon font. We use these as default icons in VS Code. See the spec of Codicon: codicon aliases should be component agnostic (no 'terminal', 'debug'). The componnet specific ids go in the product icon registry. These are the ids that wil be used in a product icon theme when styling an icon. Product icon ids are component specific and are defined in the component itself, e.g. as done here: This defines a new product icon , and uses the codicon 'add' icon as the default icon. When using these icons in code, must be used (or in labels by the id ). We never want to reference in components, unless for the default in . Some years ago, all our components directly referenced codicons and their ids. When adding icon theming support we this indirection and I and migrated most components, including terminal. But given the huge number of icon references that work is still not complete and there are still plenty of references to Codicon. That's why a codicon and a product icon () still have the same API and we don't enforce this with the compiler. Also there are some codicon aliases that have component specific names. We can't clean up the aliases in order to not break existing code in extensions. Eventually no one should use there anymore. please do not reference Codicon directly anymore unless in registerIcon please follow the pattern as seen in terminalIcons please don't add component specific Codicon aliases FYI
FYI I was following what seemed to be the thing to do as demonstrated by the icons. Could we remove those and similar examples and/or add a comment with this guidance?
Good point, we should clean these up. The codicons have been around from old times before we did the product icons. There are product icon registration under the same name , so we can remove the codicons that are just aliases, and give the others a different name, to avoid confusion.


<!-- 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: V1.70.0 OS Version: Ubuntu 20.04 Steps to Reproduce: to latest V1.70.0 version of VSCode starship prompt for the bash shell. I have my starship prompt configured to update if the previous command execution failed for unknown reasons. After the latest update, every command execution seems to fail only in VSCode's terminal. Below is the expected behaviour, in a bash terminal: The screenshot of the same with colors: ! Now in the VSCode's terminal (running bash): (It shows the error condition even in a brand new instance of the terminal) A screenshot of the same with colors: ! This behaviour of always erroring out even for a successful command execution started today after VSCode auto updated to V1.70.0 Below is the information I got from menu: Version: 1.70.0 Commit: Date: 2022-08-04T04:38:48.541Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Linux x64 5.15.0-43-generic snap
Did you notice
, thanks for the prompt response! Yes, by disabling shell-integration, starship prompt started behaving as expected. Shall I close this issue or consider this a bug with shell-integration ?
I don't see why there was a need to enable Shell Integration by default, spent the last 2 hours trying to figure out what was wrong
This probably has nothing to do with starship (I have the same issue without starship). This is just a specific case of and should probably be closed as a duplicate


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


Type: <bBug</bnotebook an image from the workspace into a markdown cell Bug this inserts the full uri, such as It should insert the relative path instead VS Code version: Code - Insiders 1.71.0-insider (Universal) (, 2022-08-10T05:18:38.020Z) OS version: Darwin x64 21.6.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --


Testing As mentioned in the title it should be in this modal: <img width="405" alt="image" src="https://user-"
Thanks


Testing When my cursor isn't inside of a conflict, this command does nothing. Should it only be visible in the quickpick when it does something? Or should there be an error message when you try to run it but it doesn't do anything? Same with the "Toggle Current Conflict from Right". <img width="549" alt="image" src="https://user-"
I fear if we hide it when there is nothing to toggle, users won't discover that there is a (keybindable) command for this functionality. How did you find this command? Was your cursor in a conflicting region?
It wasn't in a conflicting region at the time
Let's show an error message if this command does not do anything.
If I run the toggle command in an invalid region, I get a notification, which is good. But, if I then toggle a valid region after, the notification still stays on the screen for a while. Can the notification be hidden when the user toggles a valid region?
Can notifications be removed? I thought that is not possible. Also, I think this use-case is quite rare. The notification is just to teach that you should be in a conflict.


<img width="603" alt="image" src="https://user-"
!


Refs: I do not understand this condition: How does that make sure a method exists? The only check for this that is valid currently is , the is just a detail of the file system and not a capability.
This looks like an actual typo to me or missing code review, not sure the consequences, as it could lead to errors when wrongly asserting, so maybe moving to August for investigation.
TLDR I misunderstood how the declared capabilities relate to the actual declared methods and the meaning of . For context, this change came in through and the intention of this change was to support the scenario where an has declared but not : since is optional in the interface and the capability requires both and to be implemented: I made this change because when implementing a with but not , this would result in throwing here: I see how it's possible that a which has check does not have a method implemented. Additionally I see that we have other examples of how to handle the requirement of a readonly filesystem which implements both and , e.g.: I am reverting Apologies for the incorrect code change and thank you for pointing this out.


Latest insider. <img width="433" alt="image" src="https://user-"We should make sure the delete action is clearly visible.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: Stable & Insiders OS Version: Any Steps to Reproduce: Jupyter extension the following cell against a Python kernel The expected output is fairly simple: ( can appear some where in the middle) However VS Codes output is incorrect We are missing the line breaks (looks like this PR seems to have broken that) (using blockinline-block` fixes this). We have duplicate entries (as you can see below, we have multiple times) i think this has to do with the fact that we're trying to re-use the previous output and append the new stuff into the previous output element Note: This can be repro'ed in stable as well, but if i were to remove the code that tries to append to the previous element, then it looks as expected. Not sure when this part of the code broken though. Didn't go through the change log to determine this, you might have a better idea.
note that this is from the test, so that could probably be modified to check for the fix
It looks like this was briefly solved (at least for me as I reported in ) but the problem is now reappearing.
I agree, I can replicate the same bug again, hence reopening this issue. Looks like subsequent change regressed the fix.
seems to be a worse regression now (only in insiders) and repros without needing to do anything with background threads (unless I just have some bad setting): !
I'm seeing something similar with the JavaScript/tslab notebook I use for teaching async and promises. Previously, the output was inconsistent across runs with sometimes missing or duplicated output. Now all the expected output is present but with line breaks appearing only after some async code (e.g. ) is executed. <img width="661" alt="image" src="https://user-"
I reproduced output shown by above with missing new lines in code-insiders at ~14:00 UTC +1 (CET). In a code-insiders session that has been running last 24 hours. Restarting code-insiders approximately an hour later (15.00 UTC+1), the output is now shown with correct line breaks, see screenshot below. Version: 1.75.0-insider (user setup) Commit: Date: 2023-01-09T05:29:27.679Z Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes Output after code-insiders restart: !
confirmed that this no longer seems to reproduce on the latest.
Adding label as confirmed above.


shell integration enabled a zshell terminal just exits instantly a zsh terminal now works. However, some shell integration markers are still present, and my .zshrc didn't load -- no theme and no aliases are available <img width="359" alt="image" src="https://user-"vs in iterm: <img width="246" alt="image" src="https://user-"
I have seen issues where this is happening, but haven't been able to reproduce yet myself
a recent change which could've caused this is
does your set your on the machine that you're seeing this on? what's your in the external terminal?
is unset when I'm using zshell in iterm
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!
This issue closed? This problem still seems to be occurring. Version: 1.72.0-insider (Universal) Commit: zsh 5.9 (x86_64-apple-darwin21.3.0) and I don't set ZDOTDIR variable
This issue still exists https://user-


This throws in the monaco editor. To see the exception: clone as a sibling to vscode run run run open http://127.0.0.1:8080/monaco-editor/test/manual/?editor=src observe the error: <img width="1323" alt="image" src="https://user-"
I get this so I think I need some verification steps:


Type: <bBug</b! VS Code version: Code - Insiders 1.72.0-insider (, 2022-09-23T05:17:37.024Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: Yes /assign <!-- generated by issue reporter --
/assign
Completely agree on this. Tree ident guide highlights are pretty awful throughout the hole app, except the editor itself because of the color lines.
Great find!


Type: <bBug</bLight+ on Insiders ! Light+ on Stable ! Dark+ on Insiders: ! Dark+ on Stable: ! VS Code version: Code - Insiders 1.72.0-insider (, 2022-09-23T15:06:00.185Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: Yes <!-- generated by issue reporter --
regression from


Testing on run continue on clone locally I see a browser-native dialog to open desktop I see a custom message that just reads "We tried opening Visual Studio Code - Insiders on your computer." which is confusing Unsure if we have to show the message or not but its wording needs to be improved. I mean tried and succeed in opening desktop so don't confusing me with this message. If we cannot prevent it I'd suggest to rephrase it and assume that it worked and give me a close option. Today, there this only covers the "didn't work cases" despite success https://user-
We cannot tell from the browser whether opening the protocol url succeeded, and the current wording for this dialog is based on a similar dialog from Office which also unconditionally appears in the browser: Maybe renaming 'Continue here' to 'Cancel' or 'Close' would help? Some other ideas for wording--when you launch a Zoom meeting from a browser in the desktop client, it says !
I can accept that but the wording should be positive/happy. Like: "This session now continues in VS Code Desktop. You can close this window, all your changes have been carried along. Try again if VS Code Desktop didn't start yet."


Testing It would seem to make sense to start at the first unhandled conflict (currently starts at the top of the file).
This would also help a first-time user understand what they are looking at. Without a conflict being highlighted, it is easy to get confused over all the filled and unfilled rectangles: <img width="2060" alt="image" src="https://user-"With the first conflict selected this is less the case because the 3 unfilled rectangles stand out: <img width="2061" alt="image" src="https://user-"
But the first conflict is revealed automatically, right?


Testing According to , we can have git checkout a specific branch as part of the cloning command. That way we can avoid slowness as well as a double progress indicator.
Verification From your browser, enter . This should clone the repo and checkout the branch , and there should only be one progress notification for the clone progress, there shouldn't be a second progress notification for the checkout
I just get messages like Version: 1.73.0-insider (user setup) Commit: Date: 2022-10-26T09:31:30.519Z Edit: It's missing url=. Will try again.
Thanks


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


Just debugging in Insiders, it looks like the opposite: the free port matcher doesn't match anything unless the output is more than its configured 20 lines <img width="499" alt="image" src="https://user-"If I add then it works. THat should be enough for me to verify the UI side of this... Originally posted by in
remove this completely
<!-- 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!


Type: <bBug</ba new profile from empty click on activity bar "Move Primary Side Bar Right" ! VS Code version: Code - Insiders 1.72.0-insider (, 2022-09-29T08:07:23.017Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes Remote OS version: Linux x64 5.15.62.1-microsoft-standard-WSL2 Remote OS version: Linux x64 5.15.62.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --


A remote code execution vulnerability exists in VS Code 1.71 and earlier versions for malicious notebooks. These notebooks could use command uris to execute arbitrary commands, including potentially dangerous commands The fix is available starting with VS Code 1.71.1. The mitigates this attack by performing input validation on the URL pointing to the repository to be cloned. Do not open notebooks from untrusted sources. The patch for this can be found at An advisory for this can be found at MSRC details for this can be found at
the docs and advisories say it's fixed in 1.71.1, but it's only fixed in 1.72.1


Since long we automatically profile the extension host when it becomes unresponsive. In that cases we send a signal via telemetry and in bad cases we ask users to file issues. During that we ask them to attach the corresponding profile but we have mixed results with that. So, in addition to the existing flow we want to log a richer telemetry event that uploads the heaviest sample trace from the profiling


When the /gifPlease command is used the issue owner sometimes replies to the GH notification email and attaches their files. The attachment gets lost. Please update the instructions to say that files must be submitted via the GH website.


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