Issue Type: <bBug</bmicrosoft/vscode-extension-samples the helloworld-sample folder , build, verift that its contributed "Hello World" command activates the extension and shows a notification. the vscode version references in in two places to use 1.43 minimum. code to activate function in , for example: , run, use "Hello World" command to activate. breakpoint on return line above. a folder. Explorer button or context menu to create a new file. Confirm that the event fires and your breakpoint is hit. from breakpoint. Explorer context menu to copy/paste or use drag/drop with modifier to drip as a copy. :bug: The event callback does not run, despite the API doc stating: Issue also exists in 1.64.2 VS Code version: Code - Insiders 1.65.0-insider (, 2022-02-21T05:15:17.930Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
cc
the extension host's event is only emitting from 's event, but the explorer is using the 's , which doesn't seem to talk to the working copy service. What do you think the fix here should be? (cc
the bulk edit service is using the for its operations. If you look at , there is a bunch of usages for that service. The working copy file service is a wrapper around the file service that ensures the relevant events are emitted and can be participated on. I suspect that for the copy/paste operation or drag/drop we are possibly not using the bulk edit service but the file service directly? I suggest to make a pass over all explorer code and look for raw usages of to replace with bulk edit service. I think that would even enable undo/redo properly.
My bad, the real bug is that this block: doesn't handle events. cc
Pragmatic fix would probably to treat the same as .


It seems something odd is appearing in our builds, specifically for our "video" svgs that has a link. The SVG doesn't contain anything crazy: Which throws the following error in the console: The strangest thing is in OSS everything looks fine but in the builds, the image is small and not centered. <img width="1089" alt="CleanShot 2022-02-23 at 09 01 27 src="https://user-"<img width="1024" alt="CleanShot 2022-02-23 at 09 01 14 src="https://user-"cc
Is this new? cc any recent changes to CSP?
I see this in Stable as well, so we likely never caught it
This is happening because the is being stripped out of this svg at some point during build.


Just broke again:
Added a timeout to the initialize request which will tell me if that's the part that's timing out, but it's probably not. Any guess
Duplicates


This video shows text in another cell being undone even though focus is in a different cell. Doesn't seem to matter whether "Notebook: Undo Redo Per Cell" is enabled or not ! This video shows that after a cell as been and text has been to it, Ctrl-Z can be used to remove it, but it cannot be redone. You've lost anything typed in that cell permanently. !
Marking as important and a regression as I can't seem to figure out whether the "per-cell" setting is working the way it's intended or not.
Actually it appears that I may have disabled the "per-cell" setting a long time ago and didn't realize it. This may explain both behaviors above. I didn't realize that after changing that setting VS Code must be reloaded for the setting to take effect.
So removing "important" and "regression" for now. Let's just review what the behavior is that we want. It does seem problematic that if you have the setting off, that it doesn't seem possible to restore a cell you may have accidentally deleted. When the setting is on, Ctrl+z seems to work as expected.
After internal discussion, re-marking as important. It's a data loss scenario if you have cell-level undo off.
Possibly related to
With Cell Undo / Redo on (this is the default): Undoing and redoing text per cell works as expected Yes, with my testing Undoing and redoing add / remove of cell works as expected No, see bug 3 Undoing remove of cell via delete button No, see bug 4 With Cell Undo / Redo off: Undoing and redoing text per document works as expected No, see bug 1 Undoing and redoing add / remove of cell works as expected No, see bug 2 Undoing remove of cell via delete button No, see bug 4 Bugs: 1 Two cells in document. Changed from per cell to document mode. Typed in Cell A. Moved to the second cell, hit Undo. Instead of undoing the text, it blew away the second cell. Typing Redo did bring it back. I expected the typing in Cell A to be undone. Note, this bug I don't see after reloading the window. Might be that the setting change mid flow got the stack into a funny state? 2 Two cells in document. Shift-enter to run and add a new cell. Type in new cell. Ctrl-Z makes the typing go away and eventually the cell. When the cell is fully removed, redo will not restore it, so the typing is lost. Note, I can only replicate this will per cell turned off. With per cell turned on I first need to not be on the current cell to make it go away via Undo. But in that case I can make it go away with Undo and the text is restored with Redo. 3 However with per Cell on the cell + text does come back, but when it comes back it comes back without the per cell undo redo stack with per cell turned on: 4 When removing cell with the delete button, it cannot be restored with undo. This is true with either setting on. This is what I saw in my first pass. My personal ranking in importance would be like so 4 - Clear data loss. In both modes a cell is deleted and I can't get it back and the info in it. Easy to do and damaging. Effects both modes. 2 - Also clear data loss. I find this as a bit less important as I can only repro it with perCell off and I need to Ctrl-Z through the cell to get to the cell loss case so I've already removed what I typed in to the cell to get here. 3 () - Data loss here, but the data loss is not the actual code just the undo redo stack. So I'd vote for less important. 1 - I only reproed this when changing the perCell setting without a reload so an issue, but lesser importance.
Some related issues:
Note I'm going to use this issue specifically to resolve the issue where with perCell mode turned off you cannot restore a cell that was deleted with undo. The only specific scenarios in this fix are as follows: a notebook document a new cell (type something in it if you want) the cell using the delete button in the toolbar +Z (Run Undo) from a previous cell in the file the cell would not be restored, now it will be Scenario 2: the last cell in a notebook document shift-enter to run the cell and create a new cell some word in the new cell using Undo in that cell, it should walk back the words typed and eventually delete the cell start pressing Redo, it should restore the cell to the document then restore the words typed the cell would not be restored.
thanks for the detailed investigation, they are insightful! For bug 1, you are correct that flipping the setting messed up with the undo/redo state. We register based on the setting which is not updated when we flip the setting. We might want to dispose it and register a new one when the setting changes. For bug 2, with your fix in, I can't reproduce it with the per cell setting off. Not sure if it's similar to bug 1. For bug 3, your comment is accurate. It's like a document and we don't persist them usually when a resource is gone. I wonder if we should fetch and "save" the undo/redo stack for the cell on the cell deletion element in the undo stack.
Reopening to cover the issues with flipping the setting. I'll close after that fix and will cover the bigger issue on persisting undo / redo per cell after delete.
/verified? Still not sure this is working. Is per cell undo supposed to allow undo to affect other cells? Repro: to per cell undo in first cell in second cell +Z Expected it to only affect the current cell with focus. Actually it removes the typing in the first cell.
Otherwise seems to behave more like I'd expect.


Repro: in a terminal and select something ! We should hit ctrl+c beforehand () which should work properly on all shells
We should also do this when is clicked in the decoration's context menu
I attempted this in but it was more complicated than I originally anticipated. Moving to backlog.


Open following url Install dialog is shown asking user to install and open extension <img width="275" alt="image" src="https://user-"- After clicking on install, following prompt is shown <img width="454" alt="image" src="https://user-"Second prompt seems to be unnecessary. It is expected to open the URL after installing


System info: macOs, Zsh, shell integration on. to vscode folder and hit tab it autocompletes to Hit tab again to autocomplete the names, it instead creates a big space and adds again. !
Not sure if we're tracking this one yet but I've seen it too in pwsh/Windows.
Works fine in pwsh.
It only occurs for me when shell integration is on. I've had to disable it in the meantime
Maybe I didn't see it on Windows actually. Happens on zsh/mac when pasting followed by enter/left: <img width="418" alt="Screen Shot 2022-03-17 at 10 57 44 am" src="https://user-"
Oh I bet I know what's causing this, we need to wrap "invisible" parts of the prompt in and
Simpler repro: tab <img width="242" alt="Screen Shot 2022-03-17 at 11 08 21 am" src="https://user-"l


The original issue comes from Comment from Looks like there is some problem with the editor focus when the test message view is peeked out?
I found a way to view test results and work with tests. When the tests are executed, I need to press CTRL+m for tab key to move between elements, then tab until the close button and after that panel with buttons to go to previous and next failure results there will be a tree with test results. That's accessible with NVDA, I am sure it's also accessible with Orca. Thank you for help all!
Thanks for the issue! at the moment we reveal the failed position and then focus the editor. Instead is it preferable to focus within the peek view like the references peeks do?
yeah, it would be better if you focus inside the peek automatically for accessibility reasons. If you want, you can also differentiate if the command is triggered via keybinding, if yes then move focus, otherwise do not. This is what the editor hover does. Though I think it might be a bit confusing in this case, so I suggest to just pass focus inside the peek.
Thank you for such an active feedback! I also think that it would be more convenient if the focus moves directly to the peek instead of moving it to the editor with the selected line that can be easily deleted by accedent. Thank you!
<!-- 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!
how about some verification steps unless resurfaces?
Steps in the original post should still be accurate. Opening test peek output (for a failed test) via should focus and screen-read the peek view, rather than staying in the editor.


The fix for at only replaces the first instance of in the string, not all of them. I suspect the regex needs on the end. <img width="1028" alt="Screenshot 2022-03-17 at 14 46 58" src="https://user-" FYI :)
heh, I found that and was going to change it, but GitHub fell over. I can easily add the , but it's not clear to me where/how to write a test against this class (which is actually the part that I get stuck on any time I want to contribute something). I can't find any similar tests in this area to use as a template.
/verified


Steps to Reproduce: command a language Settings file is opened. Settings Editor with language filter shall be opened given that the editor supports it.


Forgot to respond and got closed due to inactivity. - We don't necessarily need them to read each item, but at the minimum screen reader users need to know that these buttons exist. Even a small announcement along the lines of "tree items actions available on tab" would suffice. Repost of:
Does this issue occur when all extensions are disabled?: Yes/No VS Code Version: 1.63.2 OS Version: Win11 Steps to Reproduce: a debug session in VSCode on Narrator keyboard and navigate focus to the debug target ! Expected Result: Narrator should announce all context, including action items associated with the treeitem Actual Result: Narrator announces just the tree item text and associated action buttons
I am not convinced this should be announced. As Rob already mentioned on that issue the user can just press tab and focus onto the toolbar. We do not do this in other places that the parent element mentions all the children element inside it. Or the element that is about to get navigated to next. Let's leave this open for now to see if there is some feedback from users regarding this. For now I suggest no action.
Not announcing anything does violate accessibility standard guidelines as visually impaired users who rely on screen readers wouldn't know that there are buttons associated with each tree item. I am filing this issue on behalf of the project where our products are required to meet accessibility standards and this component has been flagged as an accessibility violation. I understand that the prioritization might differ, but I wanted to give some context behind the issue.
Agreed that "they could just hit tab and find them" is neither valid to fulfil our accessibility needs nor is it something we can expect from users who rely on navigating without seeing. As a quick fix, is there a chance to add an aria label to elements like these that announces "more functionality available" to explain to people that hitting tab will get them there?
- Instead of adding extra announcements, we could also change the type of the component to be a tree grid/tree grid item. Screen reader users should expect more content on tab if they are on a tree grid item. Any thoughts on this solution?
thanks for your creative suggestion, but a is something that is like a table and might not fit here. Check out the example here does it make sense that VS Code trees start using a role because each element might have extra content inside. How do Screen Readers treat vs ?
The suggestion came from the Edge Accessibility team. The core idea is that the existence of interactive buttons/content should be inherent based on the role of the element which is true for a tree grid item but not a tree item. As for screen reader behavior, treegrids are announced like tables, but they also state item position and level similar to a tree item. For instance, when you enter the grid, it will say: "Entering table, 5x2... etc {contents of the row} expanded 1 of 3 level 1" From this, the user will understand that there are additional cells with content to the right (maybe just one extra cell containing the toolbar with buttons) and also that they are in a tree structure.
Thanks for clarifying. Also are you suggesting that all trees in vscode have the role? Since every tree could have additional actions inside. What's the downside of using the role? Let's see what thinks when she finds time to reply. She is the author of Orca screen reader.
tl;dr I think Tree Grid might be appropriate here. Long form: I definitely wouldn't expect interactive elements inside a normal tree view item. The two interaction models I've seen on those are: a) Put these items in the context menu. b) Have the user press Enter on the item to enter into a secondary layer where one would then tab through interactive elements. I first saw this in the old FireBug developer tools extension for Firefox, and later, while I was working at Mozilla, we also took this approach in the built-in developer tools in the HTML tree inspector. A tool bar with buttons etc. inside a tree item is certainly not Windows-Standard, and Windows standard is what most ARIA specs and authoring guidelines primarily derive from. Tree grids come more from the Linux side, where this is at least I saw them first in GNOME Nautilus. So yeah, I would lean towards a tree grid model where one would right arrow into the buttons for an item, if available, or tab to the toolbar, etc. We'd have to play with the aria-readonly property on this tree table, since some screen readers sometimes think they're editable when they're actually not, or vice versa.
thanks for chiming in, I really appreciate your expertise. In VS Code it is pressing to get into the toolbar that is inside the tree element. Some follow up questions for everybody on this thread so we decide how to proceed further: about the Breakpoints view? This has the role and also has interactive elements inside each ? there some unintended consequences of going with the instead of the in all our trees? Or should we use the only if there are interactive elements inside? Example: Explorer does not have interactive elements, but Search does. We need to have a consistent experience across VS Code, thus these questions. fyi
is a good question. I'll consult with our Accessibility team, but my initial thoughts are that we would need to change the role from a listitem. I'm not entirely sure if the best fit is a tree grid element or another role. wouldn't change all trees to treegrids as each role has its own set of implications and ignoring that would confuse screen reader users. If all these trees are derived from the same base class, I would add a constructor argument to differentiate treegrids and trees.
Looping back for the first question - I believe a grid/grid cell role would be best for that kind of component.
Let's assign to May as I would like to experiment with these changes at the start of a milestone
I have changed the role for the whole CALLSTACK to be a for this use case and for each item to be a . So now as you say users should expect more content when they press tab. If users get delighted by this change I would be open to do this in more views.
Hey - I appreciate the fix! Unfortunately, the component that we're using in our extension is the . Would it be possible to port the same fix over to this component considering this is the actual component our accessibility team is flagging up?
every tree item has an field which your extension can use to manipulate the role or the label of each tree property. I suggest you try using that. For example you could try different roles, or to make the label more verbose as Christian Heilmann suggested here Allowing extensions to change the role of the whole custom tree is currently not possible, and if that is what you would need then I would have to discuss with Alex Ross who is currently on vacation and this would require API changes.


Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !


System: Red Hat Enterprise Linux Workstation release 7.9 (Maipo) OS: Linux myhost 3.10.0-1160.36.2.el7.x8664 SMP Thu Jul 8 02:53:40 UTC 2021 x8664 x8664 x8664 GNU/Linux This began as an occasional annoyance and has escalated into a 100% reproducible annoyance. Using the latest snap install, during normal editing/debugging/etc. on local system. With increasing frequency, Ctrl-O/File-Open would completely freeze the UI with just a blinking cursor. Sometimes switching away and back would repaint part of the screen, increasingly not. Tried switching the output window to various things before attempting the file open (extension manager, main window, etc), but no output was observed before the freeze. Once the UI is frozen, only kill/killall seems to be able to get rid of it. Not sure if it means anything, but de-maximize and maximize still resize the window frame, although the contents aren't redrawn. Can't remember if that requires app cooperation or it that is a pure WM thing. Using snap installed code-insiders made no difference. Uninstalling snap versions and downloading 1.65.0 from the MS repo so far seems to have restored functionality (1.66.0 requires a glibc version unavailable for RHEL7). Haven't tried with (all) extensions disabled, but did disable everything I don't need constantly. One change in workflow recently seems suspiciously coordinated with the start of the issues - began using VS Code on another machine (nfs-mounted home folder, so shared settings/etc.) to attach to running containers (as container-specific user, to specific folder inside container), debug processes inside container, etc. Perhaps something got saved in the settings that is redirecting local File-Open to the remote-containers extension? Probably not, but the timing is mighty suspicious.
Interesting. With 1.65.0 still running, snap installed the latest (1.66.0) again and ran it with: Ctrl-O still hung the 1.66.0 app. Apparently it isn't an extension.
me is the same vscode is really disgusting
yes, I ran into the same problem, vscode hangs when execute any open command, open folder or open a file
Same for me on my Ubuntu 18.04 :-( Installed via tail of :
Also happening here, is there any known workaround at the moment to still open a folder? (Also seems to be related)
points to mismatched gtk library version loaded in the app process or others facing the issue, can you please follow the steps below and attach the generated profile
Thanks! Attached as requested above.
Is the log cut off ? I don't see most the library loads that are required for startup.
hmm, sorry, would be sufficient ? Because that is an only single output which I've got after execution. p.s. I am using managed PC and don't have permissions for :-(
In the past when I tried strace directly with snap packages and it would fail, hence I rely on the flag. Not sure if it works better now. No worries, I hope others hitting this issue might be able to provide the required trace. In the meantime, can you check if the issue exists with our debian package ?
Debian package works well (with some strange behavior). Thanks for a temporary solution. Strange behavior -maybe because I've disconnected all my monitors, but Open Folder dialog opens in background, thus I have to bring it manually to the foreground (but it is better than hanging program anyway ;-))
Here is the log I have with the instruction
I am also having this problem with the latest update (though I never had the application hanging problem) on Ubuntu 18.04
Thanks for the log, it confirms the root issue. Snap bundle ships with a version of libgtk3 that gets loaded by the app for all gtk operations, can be seen with With Electron 14 there was a refactor in the file dialog implementation to support XDG portal specification and the gtk library that was trying to be loaded as part of this is not bundled within the snap and in which case will search the system library paths, if the library cannot be found then the old code path will be utilized that will use the alreaedy loaded gtk library in the process but incases where it is found from the system and gets loaded, if the version mismatches with the already loaded library in the process, it causes the above app freeze. This should be fixed in Electron to use the same calls as chromium ;l=79-82? to load the gtk library.
so how should we solver it ?
I've got the exact same problem. So, if this has been fixed in Electron 18 when can we expect an update to VSCode? Because I'm on 1.67.1 and the error still persists.
This issue is very annoying: ! Hope upgrade to electron18 as soon as possible
This issue started for me after installing . Not sure if that is helpful? After removing this package (and also running afterwards), the issue was gone.
Got the newest version; but same error... Commit: Date: 2022-05-17T18:23:40.286Z Electron: 17.4.1 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Linux x64 4.15.0-177-generic snap
Update to Electron 18 is gonna take a bit longer, I will try to get the fix into Electron 17 as well. The issue is not yet addressed in our insiders and stable.
Latest version (from 2 days ago) still has the same bug (Ubuntu 18.04). Does anyone have a workaround? Any way to install an older version? EDIT: Downloading the Linux 64 .deb from solved the issue for me.
if you're just looking for a workaround, try the terminal command: or . It work's for me at least. But for a more solution maybe 's helps (I haven't tried it myself).
Same issue. Ubuntu 18.04. Channel: latest/stable: 2022-05-18 (97). thank you for the workaround. Removed new snap version and installed 1.65.0. Solved for me.
I was having a similar issue with vscode 1.67.2, non-snap on Ubuntu 20.04. After I noticed the issue I tried an apt upgrade, which didn't fix it. Downgrading to 1.65.2 fixed it for me. I am using i3 for window management.
<!-- 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!
Verification Steps: Install Ubuntu 18.04, images available from Install gtk3 <= 3.22, Install stable vscode from snap, Launch code and open the file explorer Verify application freezes Install insiders from snap, Launch code-insiders and open the file explorer Verify file explorer launches and application does not hang
can you help in verifying this since you have Ubuntu 18.04?
Hey , I can confirm that I get a dialog with the same setup and . Thanks! p.s. nevertheless, the strange behavior of dialog appearing in background remains the same as for previous solution using - but that is fine for now.


<!-- 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.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR. I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at . I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up! I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified


Issue Type: <bBug</bSteps to Reproduce:  in a Markdown cell in Jupyter notebook. The monospace font used in Jupyter notebook () Markdown code blocks is not consistent with in the settings. ! This does not occur in a seperate Markdown () file. ! VS Code version: Code 1.66.0 (, 2022-03-30T05:50:14.623Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --


<!-- 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.66.0 OS: MacOS Monterey 12.3, Darwin x64 21.4.0 Steps to Reproduce: new new markdown cell, name it for instance or will only show and have deleted the 1) or 1. written manually
cc -- It looks like this is being sanitized out of md strings. A markdown cell containing will be sanitized to render as . If the cell contains it will render as expected, only removing the html tags. It seems to be happening at the following:


<img width="776" alt="image" src="https://user-"I don't have stable reproduce, but this happens pretty often, especially I'm moving lines around.
I don't think this is a bug of injected text: When there are not decorations, there cannot be any injected text. This looks like there are some orphaned decorations.
Do you use the setting? Do you still see this with latest & greatest insiders?
I'm using the setting but haven't seen it for a while since I reported the issue.
Leaving this open, lets find steps
Is it possible that this is caused by the recursive issue?
Could be the case! The fix is to use it like this:
Oh, so inside the runner?
Yes, because change events are only send out after returns. Thus, is not reentrant anymore and will be assigned correctly.


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --In response to , I think this error should only be raised when a request actually fails. I have a network setup where my host operating system reports it doesn't have network connectivity, but it can actually reach the internet just fine through a configured proxy. I believe moving the online check to the would result in a more accurate error flow: Obligatory xkcd for my unique situation:
As mentioned by I expect shall provide right info whether VS Code can connect to internet or not. Is it possible to get this info from the error instead of ?


<!-- 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 VS Code Version: 1.67.0-insiders OS Version: macOS 12.3.1 Steps to Reproduce: the terminal scrollback to 30'000 for With version 1.65.0 this was not a problem, but there was no highlighting. It would be enough if I can disable the highlighting or disable the highlighting automatically if the history is longer than x lines. https://user-
That doesn't look or feel slow to me - can you elaborate on what the issue you're dealing with is?
Is it Upstream or VSCode Core.
Happens for me too, when you search then type abs quickly and it takes ~5-10 seconds for the letters to appear, same goes with erasing letters.
Search is fast now but matches info is not being shown -


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.66.2 (Universal) Commit: Date: 2022-04-11T07:49:20.994Z Electron: 17.2.0 Chromium: 98.0.4758.109 16.13.0 V8: 9.8.177.11-electron.0 OS: Darwin x64 20.5.0 Steps to Reproduce: push a commit to a repo that user don't have permission message modal will show to ask user if they want to create a fork repo button create a fork for you user don't want to creat a fork, that's why they close it. <img width="504" alt="Screen Shot 2022-04-29 at 11 18 18 PM" src="https://user-"I check the code, looks like github extention only check  to return. What I suggest If you think this were resonable, I will make a PR for it


Issue Type: <bBug</bI had a file with unusual line endings in it, and this happened: the dialog kept reappearing after pressing 'ignore' until i finally relented. When I tried to create a new file with weird line endings it seemed to work, maybe since I had the file opened while the file was being generated, every time the file changed the dialog was re-enqueued even though it was already open? VS Code version: Code 1.66.2 (Universal) (, 2022-04-11T07:49:20.994Z) OS version: Darwin arm64 21.1.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (4)</summaryExtensionVersion ------ astro-vscode0.16.0 vscode-graphql0.4.4 vscode-docker1.22.0 svelte-vscode105.16.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
could you post some steps to verify?
I could not reproduce this myself, I did the change by realizing that the code showing the dialog is re-entrant. Could you please verify the fix using our
<!-- 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 tried adding to the end of files and got the dialog, but I couldn't get the dialog to keep showing up on Stable.
Verified by code review
unfortunately it was a one-off conversion script from an old system that caused the issue which I don't have any longer, so I'm not sure about the exact steps to reproduce it! edit: oops wrong account, i'm threecreepio. :D


Issue Type: <bBug</bWhen closing the Python interactive window the Terminal panel shows itself. ! VS Code version: Code 1.67.0 (, 2022-05-04T12:06:02.889Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <details<summaryExtensions (8)</summaryExtensionVersion ------ remotehub0.32.0 python2022.6.0 vscode-pylance2022.4.3 jupyter2022.4. jupyter-keymap1.0.0 jupyter-renderers1.0.6 remote-repositories0.6.0 markdown-all-in-one3.4.3 </details<!-- generated by issue reporter --
what's the recommended approach to debug this? I'm not sure who is opening the terminal (but I know it's not notebook or iw as it's the editor tab close button)
I debugged this, and determined that when the interactive window is closed, it updates a context key which hide a view container in the panel. this incorrectly triggers the panel to show.


Open in two different tabs Make sure settings sync is OFF Change the theme in one tab Theme is not updated in other tab


The layout controls icons can be a bit of an eye sore when in the default state. One way to remedy this and to give a stronger indication of the state, we could swap icons based on their state. Would look something like this: https://user-
these icon are now in: - -


Many of these onDispose listeners get created:
we fixed this at one pt. !
They were in and
here's when we lost it
want to fix it since you're working on that PR?
Let's hold off until it's done, this PR is complicated enough without merge problems
it's a simple fix - literally adding to the conditional on line 218
Did another review and haven't seen this issue since


Our presubmit tests started to fail consistently since our test setup picked up code 1.67.0 yesterday. Our test is basically doing first, run written with from after the extension tests succeed, run a check on the consistency between our file and documentation/settings info. After running the extension tests with 1.67.0, it looks like the second step that involves reading sees a differently formatted Actually, it's not only a differently formatted , but it includes a new property (, , ...) at the end. The test passes if I make the extension tests to use 1.66.2. We can work around by arranging our presubmit test order or rewriting our test logic to handle this. But, we want to understand what is going on behind the scene and why this modification is necessary. Thanks!
this looks suspicious...
This is designed and expected. It is the metadata VS Code stores per extension while installing that can be used later for other features like updating etc., So I would recommend your extension to handle this.
this has started breaking our extension's tests without warning, and moreover, the way it writes to it's modifying the whole file (looks like whitespace changes).
how have you gone about working around this breaking change? I'm trying to get a release out myself and am suddenly blocked
Whelp, something else went on that broke my tests, but definitely noticed this too and will need to be careful about not committing the reformatted .
Sorry about the caused breakage. I am not sure what is your test doing, but I think it's not a good idea to depend on the content of , because VS Code uses it to write metadata about the extension. We do not remove any existing data but add more data.
What's the recommended way of dealing with the property when testing an extension with set to a version-controlled source directory? Should the changes be committed or do extension authors have to take care of reverting it (which probably means parsing and clearing the property).
I'm currently reverting it. Would love to know if we should do otherwise.
Reopening this to investigate if there is something changed on VS Code while running extension tests
I wanted to re-report this issue, because it was previously misunderstood and closed. Of course I won’t now this is open, but I already typed out reproduction steps. Perhaps they help. Steps to Reproduce: a git repository (this makes the issue more clear) a minimal VSCode extension with a test. The issue becomes more apparent if an existing extension name / publisher is used. .gitignore and commit we actually reproduce the bug. Run the extension tests Note that running tests has modified . Formatting is changed to use tabs, the final newline is stripped, and publisher metadata is to the file.
To verify: Create some hello world extension and open it's and change the and properties to an extension that already exists in Marketplace. Eg:Quit Code Insiders and Start from CLI with following arguments Make sure hello world extension's is not updated with property
This looks related to which didn't have anything to do with testing the extension, but only debugging it, and getting the same metadata written to an "unsuspecting" Will this fix handle this SO situation as well? The problem occurred very rarely so I couldn't give steps to reproduce, but I was only debugging and not running tests on the extension.
Yes
I have learned more about my situation of getting this extra data when debugging an extension. It happens when the extension writes to the . I have a couple of extensions which allow the user to make settings that will be read and converted to commands. I files a separate issue:


Request refactorings, and extract to a function at the top-level. Expected: no crash Actual: I'm not sure on the specific version, but in the last 9 days or so we started seeing the following crash:
Actually I found this while trying to repro a different bug. The one I was looking to repro had the following stack trace: <details<summaryOriginal Stack Trace </summary</details I think this actually only repros when working in an anonymous buffer in VS Code. When you ask for a refactoring on an anonymous buffer, we come back with the same buffer name However, VS Code pops up a notification that "You cannot rename this element" and creates a new buffer with the contents. This confuses TSServer a lot, and makes it fail over and over again.
I initially read the last part of the issue title as “thanks, language service” and thought the sarcasm was appropriate.
I may steal that in the future :D
can you transfer this issue to VSCode if appropriate?
Did this just start happening with the latest insiders?
Possible introduced with
Yeah, I believe it didn't repro on a 2 week old nightly, but I can't 100% confirm.
<!-- 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!


<img width="628" alt="image" src="https://user-"I often by accident click on the wrong button when adding a comment, imho this action is way too prominent there because it seems like the primary button to add the comment. //cc also because both buttons have the same color <img width="306" alt="image" src="https://user-"
The "Go to Review" button was to address confusion on how to complete a review: We could add some convention where the left-most button gets more prominent styling. what do you think?
Catching up after a week off.. I believe we should follow the same patterns used for dialogs and notifications where a single primary button is used alongside one or more secondary buttons. From what I understand, our the order the buttons in a dialog depends on the OS. Windows gets left-aligned primary buttons, vice versa for macOS. In this case, since the buttons are always right-aligned to the comment input on any platform, I think the primary button should be on the far right to align with the edge of the container. This looks to already be the case elsewhere in the extension: <img width="423" alt="CleanShot 2022-04-18 at 09 09 03 src="https://user-"
Thanks I want to update the style of this button to be a primary button, but there may be extensions that flip the order of importance for their buttons. I'll poll some other folks and see if it seems ok.
Verified. I assume that Go to Review button is renamed to Start Review !
The Start Review button is a Go to Review button once you have already started a review. But since you verified the button colors this is still verified.


Issue Type: <bBug</bJust updated VSC and I can no longer execute jupyter notebook cells This happens when working both in local and connected to a SSH host, both with python and markdown cells I get the following error: Checked the output every extension and log, there's no errors or no clue as to what is happening. VS Code version: Code - Insiders 1.68.0-insider (, 2022-05-11T05:17:12.474Z) OS version: WindowsNT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.4.0-1072-aws <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ jupyter-keymap1.0.0 remote-containers0.235.0 remote-ssh0.80.0 remote-ssh-edit0.80.0 remote-wsl0.66.2 vscode-remote-extensionpack0.21.0 python2022.6.1 vscode-pylance2022.4.3 jupyter2022.5. jupyter-keymap1.0.0 jupyter-renderers1.0.6 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Snapshot of message: ! I would post snapshots of the outputs of extensions and logs, but there is no output whatsoever generating when attempting to run a cell
I experienced the same after todays update to the same version. Using WSL2 Debian remote from Windows 10.
Same here!
Same.
I was able to workaround this issue by using the command "Notebook: Execute Cell".
same
Via the command palette? (Cmd/Ctrl+shift+p)?
Yep, that's how I first found it. You can also invoke the command directly from a cell with ctrl+alt+enter.
Same problem here too, thanks in advance for addressing!
I fixed it by determining the keyboard shortcut again. (ctrl + enter) However, the run icon still does not work. But the shortcut works.
run icon or regular shortcuts (shift+enter, ctrl+enter) did not work form me, only ctrl+alt+enter (which I wasn't even aware of until mentioned it) did anyways, seems to be fixed with PR, thanks for the quick response
How can I activate the PR in Insiders?
fix was already released for the VSC insiders build, update your installation
when I run jupyter notebooki type three words in it,the window can't response occur,then the vscode crushed,what should i dot to slove this problem


Started seeing this yesterday: !
This seems to be related to my theme, probably same root cause as
Repro for this is to set the following settings and try find in terminal:


insiders, new user data dir choose Light+ theme extensions viewlet, click on an extension Notice color contrast is off. The text can not be readable when an extension has selection and focus fyi !
It seems description color was introduced by Hence assigning to him.
Yeah looks like the new color isn't getting overridden in a focused/selected state. Thought I fixed this but I'll take a look


<!-- 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. --Love the new title control: ! My only problem is that I would often drag the window around by clicking and dragging the title bar. Since this takes up a large chunk of the title bar, I have less real estate to drag... but there's no reason the drag experience can't also apply to the area covered by the title control. Can the drag of the title control bubble up to the title bar so that dragging the window works?
There is a technical reason... Marking things as drag-region () swallows all events and you won't be able to click onto things anymore... I can try adding the style while dragging but it might not be possible <img width="113" alt="Screenshot 2022-05-24 at 09 15 34" src="https://user-" that's more concerning here...
Yeah, I have tried to set the style during mouse down (with a delay) but that doesn't seem to have an effect Plan was to mark the element as app region drag when holding for 200ms
related issue (which caused this)
and more context - seems like a hard problem
Can the top 1-2 pixels not be part of the drag element/target?
yeah, it already should be like that, there is another PR in the works that increases the title bar height. with that merged, dragging be simpler again
The title bar height is now aligned with the height of editor tabs. This allows to drag the window when clicking on the space above/below the CC. https://user- That's the best I can do (and aligns with Slack etc). Set/unsetting the property while dragging isn't supported...
To verify: enable CC via make sure you can drag the app window with the regions above/below the CC (see )


I'm building a custom Insiders to test one of the changes. The Linux localization smoke test seems to be failing consistently Edit: This result is likely a false positive. I think I forgot to update the branch.


<!-- 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.67.2 OS Version: Windows 11 10.0. Build Steps to Reproduce: the new folder button in the explorer panel; the new folder "**", without the quotation marks; text from red dialog box under the folder name is now bold, except for "The name ".
Probably because of markdown
The text box doesn't turn red or bold, so considering that a success
The text box should still be red saying it's an invalid file name on windows. Just the text should not become bold
I think the box is supposed to be red
the box did not turn red for me with a folder name of
Was this on windows?
no it's working for me on windows. it wasn't working on mac
** just happens to be a valid file name on macOS , thanks for verifying!


Testing This file has several headers which contain square brackets, and the contents that are delimited by square brackets get the link validation treatment ! One escape hatch for users is probably to set , but then you end up losing all reference link validation. Wondering if there is a less aggressive in-between option here, e.g. not validating link syntax in headers?
I'm taking this.
I've just submitted the PR.
Links in headers are valid. You can escape them if you don't want them to be considered link: I'm updating this issue to focus on links incorrectly be detected inside of other links, which your screenshots also shows
I've just submitted another PR. Could you please check it?
With Insiders on , it still seems like nested links are getting detected: !
Looks like the current fix doesn't handle cases where there are no spaces in the brackets. Will push a PR with a fix
I'm still seeing on the latest Insiders on macOS.


<!-- 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: OS Version: Steps to Reproduce:
Our C/C++ team has verified that our extension is correctly published to the marketplace with the correct binary -- our guess is that there is some VS Code or marketplace bug that is causing the wrong vsix to sometimes be installed.
Users are able to download/install our vsix manually from or so the bug appears to be with VS Code and/or the Remote WSL extension.
can you reproduce this problem? If yes can you file a new issue with reproducable steps? The issue is not 100% clear to us from this description. Thank you
Our C/C++ team has not been able to reproduce the problem yet. I'm guessing there's some random or unusual requirement, maybe involving a previously cached installation when an upgrade from version 1.9.8 to 1.10.5 of our extension occurs. I'm not familiar with what sort of install logging would be important for users who repro it to get, which is why I was thinking the issue should be tracked by VS Code (or the Remote extension or marketplace) and not our team. I'm aware of 4 user reports -- there could be more reported against VS Code that I'm not aware of. We don't believe our extension's warning about the incorrect binary is the root issue, and just a symptom of some other system downloading the incorrect vsix for the user's OS (we ship 10 different vsix's).
If you can let us know what the remote OS is and what the TargetPlatform property is set to in the file that could help us identify the problem.
yes getting more details here would be helpful. If you get a chance to repro the problem do let us know. Appreciate it!
A user reports that our .vsixmanifest file shows TargetPlatform="win32-x64" on a Linux-x64 remote machine (with Win-x64 host), which indicates that VS Code or the Remote extension or marketplace is somehow causing a download/install of the host platform's vsix instead of the remote one. I'm not familiar with what the next steps are in terms of diagnostics, but it seems like at least there should be an open VS Code (or Remote extension) bug to track this, since currently there are just 4 or so closed issues. See
I'm the reporter of This is not the case for me as I have installed the C/C++ extension for the first time. I don't usually use VS Code but just tried it to reproduce another problem reported by a user. Also, as far as I remember, this is the first time for me to connect to a remote workspace using VS Code. Something that might be related is the version of VS Code. I think I have originally installed VS Code back in October 2021. After that, I hadn't updated the VS Code for a long time because I'm not using it. This time, I think I first tried to install the C/C++ extension with the old version of VS Code and failed. After that, I updated VS Code to the latest version from the main menu of the VS Code, which didn't solve the problem. I'm not sure if this is really related, but is it unsupported to update VS Code from an old version (8-month old) in a single update (i.e., without any intermediate versions)? For example, some migration steps to update the cache or database format would be skipped? We might be able to ask other reporters about their situations? (), (), (this issue): How's the situation? Did you experience the problem in the remote workspace such as in WSL? Have you recently updated VS Code? When have you updated VS Code previously?
I am using the VS code(version 1.67) in Ubuntu 16.04 LTS (64 bit OS) which is hosted VM in Oracle VM virtual box. While trying to install C/C++ extension in the VS code, it was not proceeding and VS code suggested to download it from the website and install it via vsix. So, I have done the same. The installation of extension was successful but later during debugging, it has mentioned that wrong/incompatible binaries. please let me know if anymore information is required.
I was not using remote workspace WSL. I am just trying to use VS code for client side code at my local VM.
cc
Your issue might be different? You installed the Linux x64 vsix, right? What is the TargetPlatform property set to in the .vscode[-insiders]/extensions/ms-vscode.cpptools-[version][os-description]/.vsixmanifest file? It should say "linux-x64". What version of the C/C++ extension are you installing? Our team is able to debug with the Linux x64 vsix so we don't know what could be going wrong yet.
Sorry that I am late to the party. It would be great if I can get summary of the issue? Does it happen to be reproducible?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
I have been thinking that you have checked the linked issues, but let me comment in case you haven't noticed them. I have already described the details about my situation in my initial report If needed, I can just copy and paste the comment to here. Nevertheless, I can answer additional questions about my situation if any. We may also find some information by the OP of this issue in
May I know if you have downloaded the VSIX that is compatible to the platform you are using? !
It's not me. The above comment is from In my case, I initially tried to install the extension from a VS Code client in Win 10 opened for the remote workspace (Ubuntu 20.04 / WSL2), which fails with the message of incompatible binaries. After the suggestion in , I have downloaded the VSIX from and installed it in the remote, which was successful unlike the case of I'm not sure which version has downloaded. !
The problem is, as I have reported in , VS Code seems to wrongly download the VSIX of in Ubuntu 20.04/WSL2 instead of the VSIX of . I have tried several times VS Code's install button with different configurations for both VS Code and VS Code Insiders, but all failed in the same way.
Got it. Thanks for update. Can you please share us with a gif/video of what you are doing so that we can understand more about the issue? Can you please share us with the following logs after reproducing the issue? F1 Open View... Log (Window) F1 Open View... Log (Remote)
I tried to upload it to here but couldn't do it due to the size limit. I have instead uploaded it to YouTube: Log (Window) I cannot find such a view. Instead, I see and : Log (Remote Server) Log (Remote Extension Host)
Which version of VS Code are you using? Instead of downloading from the installed section, can you please try searching for the extension, say by typing c++ in the search input and install? Does it work if you uninstall the extension and install again?
As I have reported in , I have confirmed the behavior in and . Further details are found in As it does not seem to reproduce in every environment, I guess some other factors in my environment causes the problem.
I now noticed these additional comments. I'll try them when I get back home.
This installs the correct version of the extension. What is the correct way to uninstall the extension from the remote? (a) As explained in , I have already tried many times removing the remote extension---by deleting the directory as suggested in ---and installing it again. But they didn't change anything.(b) When I select the C/C++ extension from the installed section and press the [Unintall] button (see below), the remote extension is still located under , but the local extension instead seems to be uninstalled. ! (c) Also, when I type in the search input, select the C/C++ extension, and press the [Uninstall] button (see below), the remote extension is still there, and the local extension is instead uninstalled. !
So it means you are getting incompatible C++ extension when you use the button ? In both above screenshots, pressing Uninstall will uninstall locally as the extension seems to be installed locally. So, please try pressing uninstall button and install the extension again?
Yes. I had already tried that many times. The result doesn't change; It again installs an incompatible version as far as I use the button .
Can you please provide following logs while trying this? Enable log level to trace - F1 Set Log Level Share F1 Open View... Log (Remote) Share F1 Open View... Log (Window)
Here, I attach the logs: This time, (1) I first attempted to install the extension by pressing . (2) Then reopen the extension page, press and reloaded the VS Code. (3) Then, I again attempted to install the extension from the button. In the zip archive, the following files are included: --- This includes the log of in step (1) described above. --- This includes the log of in step (1). --- This includes the log of in step (3). --- This includes the log of in step (3). --- This includes the log of in step (3).
Thanks for the logs and I think I know the root cause of this issue. It seems in your case the extension is being copied from local client (Windows) to remote (WSL) and hence the bits are being incompatible. This happens if VS Code cannot find a matching installed extension in the Marketplace. In this case, VS Code falls back to copy the extension. Fixed it as follows: Before using the fallback to copy Try again to get the matching extension from the Marketplace In the fallback check if the local extension is compatible with the remote platform. This fix does not covers if you have manually installed an extension that does not exist in the Marketplace and is platform specific.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- 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.68.0 OS Version: Win10 21H1 .1706 Steps to Reproduce: ! This is caused by When L122 , the element may have been created in the tree before. Thus, may be more than once and causes icon style conflict. ! A PR will be linked. Idea from After fix: !


!
works in OSS !
also works for me in insider's
works for that exact task for me !
It's because of this: Here's the I was using:
This works but it adds an extra line because of initialText so it doesn't look quite right: Before: ! After: !


Issue Type: <bBug</bWhen I drill down into the git menu and choose the option to , I really don't need the same confirmation dialog as when I just hit the top-level check mark in the source control pane. The dialog tells me ; this is an incorrect warning at this stage, since I clearly invoked it by choosing . I certainly don't want to choose the option in response to this warning, since it's a good warning to have when I accidentally hit the checkmark without staging any changes. VS Code version: Code 1.67.0 (, 2022-05-04T12:14:47.100Z) OS version: Darwin x64 19.6.0 Restricted Mode: No <!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- 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.68.1 OS Version: Windows 10 Steps to Reproduce: When I open a terminal in VSCode the following warning is logged within a few seconds: . I take note of that this issue is not a duplicate of.
A warning as in on the window output channel or devtools console? Do you use powerlevel10k or another complex prompt by chance?
It's in the devtools console. Not using any complex prompt. Just plain CMD.
Oh OK, that's unexpected if it's cmd, thanks for the info
we should probably do something like here


Issue Type: <bBug</bAfter upgrading to 1.68, text selection in the integrated terminal does not show selected text. This is purely a visual glitch, as I can still copy what I had selected on the terminal. My colleague has the same version but does not have this issue, so I'm wondering if it's an issue introduced through my update. VS Code version: Code 1.68.1 (, 2022-06-14T12:48:58.283Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ project-manager12.6.0 github-markdown-preview0.3.0 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 keymapceditor-vsc0.7.7 gitignore0.7.0 doxdocgen1.4.0 transformer1.12.1 git-extension-pack0.1.3 githistory0.6.19 gitlens12.1.1 EditorConfig0.16.4 align-mode0.0.21 better-cpp-syntax1.15.18 cmake-language-support-vscode0.0.4 theme-karyfoundation-themes26.2.1 vscode-docker1.22.0 vscode-dotnet-runtime1.5.0 python2022.8.0 vscode-pylance2022.6.20 jupyter2022.5. jupyter-keymap1.0.0 jupyter-renderers1.0.8 remote-containers0.238.2 remote-ssh0.82.1 remote-ssh-edit0.80.0 remote-wsl0.66.3 vscode-remote-extensionpack0.21.0 cmake-tools1.11.26 cpptools1.10.7 cpptools-extension-pack1.2.0 makefile-tools0.5.0 indent-rainbow8.3.1 vscode-pbtxt0.0.4 cmake0.0.17 vim1.22.2 clang-format1.9.0 vscode-open-in-github1.3.6 (5 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Same issue, I'm using theme. When I switch to a different theme the selection is visible. Looks like a theme issue.
Can you reproduce the issue in Insider's? I see selection in Insider's when using solarized light, but it does seem pretty light !
I believe we're implementing solarized light correctly here and that's how it's meant to work. If you're not a fan of the low contrast selection you can change it with this setting: Otherwise change to a theme that you prefer. Let me know if I misunderstood and the selection is actually not visible (not just subtle).
I was using the theme for a while and I was used to the low contrast on selection. It was quite ok on my screen TBH. Now there's no visible selection. Here I've selected "Counting objects". I've actually pasted it from the terminal instead of typing to be sure. ! I don't think this issue is ready for closing.
Do you have any settings set and does changing help?
I strive to work on defaults. No settings in Setting to true causes selected letters to become slightly lighter, but no background. "si" selected ! Not sure if it has anything to do with it, but the issue seems to have started after the recent update (via PPA on an ubuntu flavor). After updating I didn't restart immediately, but attempted to open an image and everything crashed. Restarted after that and noticed selection not working a bit later.
Some more things to try: Does closing all windows and running fix it? If not, can you share your full file? Running the Generate color theme from current settings command will let us see if there's something weird going on with the theme
Confirming this is only happening in Solarized Light
Disabling GPU doesn't help <details</summary{ "window.menuBarVisibility": "toggle", "editor.minimap.enabled": false, "[javascript]": { "editor.defaultFormatter": "vscode.typescript-language-features" }, "javascript.updateImportsOnFileMove.enabled": "always", "[json]": { "editor.defaultFormatter": "" }, "[typescript]": { "editor.defaultFormatter": "vscode.typescript-language-features" }, "": "stuff=", "explorer.confirmDelete": false, "explorer.confirmDragAndDrop": false, "[html]": { "editor.defaultFormatter": "" }, "[jsonc]": { "editor.defaultFormatter": "" }, "workbench.colorTheme": "Solarized Light", "editor.inlineSuggest.enabled": true, "editor.renderWhitespace": "none", "[css]": { "editor.defaultFormatter": "esbenp.prettier-vscode" } } </details<details<summarycolor theme from current settings</summary</details
I can't reproduce based on those settings so I'm a bit stumped on what to do with this one
So I checked the terminal background on the screenshot and it's which is exactly the same color as the default selection color. the dump I pasted above had in it, which seems odd. But since you didn't raise it, I'm assuming it's supposed to mean the actual background is the one of the panel inside which the terminal is working. What I also noticed about the terminal panel is it's no longer giving me the option to move it to the bottom of the window, which is odd, but most of all when I right-click, it no longer says "move terminal right" as an option, but "move sidebar". I checked, and means I will no longer see my selection. Conclusion is what ends up being the color behind terminal text. The theme should probably set terminal background or change the selection color as a fix. I wonder what else breaks because terminal is now a sidebar not something else.
Ah ok, thanks for looking into it. Because of this, setting the terminal background explicitly is a good solution for now. I doubt it happens in many other themes since contrast is usually pretty high but I'll check Solarized Dark as well when fixing.


Version: 1.69.0-insider (user setup) Commit: Date: 2022-06-22T05:17:09.661Z 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. This is a follow up of Steps to Reproduce: the dnd sample: to the of some logs in : the extension multiple files to the dnd sample view, the uris in the data transfer are not split by line separators. // cc
Are you dragging from the VS Code file explorer view, or your operating system's file explorer?
Sorry forgot to mention, it's from VS Code file explorer
Can you check the actual value, not just the value printed by I debugged this and oddly while just prints: The actual value of is: In this case each file name is separated by a pair
Tested in: Version: 1.69.0-insider (user setup) Commit: Date: 2022-06-23T05:16:43.681Z 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. It's still stored in one line: https://user- Is there anything I missed?
Thanks. Only happens on windows for me. Taking a look now
I don't see us setting anywhere and suspect chrome is generating it automatically. See in for how this may happen Also we are possibly hitting
Nice find. I couldn't find us setting anywhere either.
Verified on Windows and Linux in 1.69.0-insider (user setup) Commit: , 022-07-01T05:17:04.343Z


I think we should understand why execution time seems to get slower and slower the more cells there are. Check out this video, it looks as if things get slower and slower: ! Originally posted by in
This test is running the "Run All" command, not the "run one cell" command...


! Version: 1.69.0-insider (user setup) Commit: Date: 2022-06-23T05:16:43.681Z 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.
It's actually allowed to have no scope (for the default fore/background), but the schema is too strict


<!-- 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 (the issue is produced using CMake Tools extension) <!-- 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: Version: 1.68.1 (user setup) Commit: Date: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: WindowsNT x64 6.3.9600 OS Version: Windows 8.1 When using the CMake Tools extension, the build output is shown in the "Output" tab. And when the build is going fast (when there are many build log lines per second), the Output doesn't update until the end of the build. See this video from https://user- The build output is not realtime. CMake Tools extension a project that builds fast (less than 200ms per build log line) main.c: Note: Build this CMake project using MSVC is faster and is more likely to reproduce the issue than building with clang/mingw. After severals tests, I've found that: The VSCode log file (inside is constantly updated as expected, this can be checked with bash using The code that prevent the actual log to be printed in the Output pane is here: This code uses from here (with a default delay of 300ms): Which uses from here: And if I read this correctly, this means that: Due to IPC between CMake Tools extension and the main Code thread, for every log line, is called, and every call to that function will reset the Delayer timer of 200ms. This means that as long as there are log lines every at most 200ms, the output pane won't be updated. Which cause the "hang" as seen in the above video. I guess that replacing the from to a would solve that issue ?
Here are videos to compare the modification of using instead of for the variable in . Before modification (VSCode 1.68.1 unmodified): https://user- After modification (replaced the declaration of to , replaced call from to and removed call to ): https://user- The CPU usage is a bit higher, but the log is shown in realtime (the CPU is a intel i5 3230m from 2013). Closing the Output pane while building takes less CPU (around 48% instead of 53% (when not recording), when not building I'm at 6%).
Thanks for debugging it and coming up with the root cause. Your analysis is correct. But changing this to Throttler is not the right. We would still want to delay/debounce the updates if they do not need to be real time like log outputs. But for the output channels created by outputs we shall update the content immediately. Created a PR to fix it when immediate updates are needed like in this case.


Testing If there are no changes, we should not be able to create a new edit session. In this particular case, I would expect that an information message is being shown, and that the existing edit session is not being overwritten.


Testing Have one profile with GitLens installed and other without. Notice how walkthrough shows up in Welcome page on profile without GitLens <img width="1653" alt="image" src="https://user-"
It seems welcome page is not updating when extensions are removed. This has to be fixed in walk throughs / welcome page component. Not sure who owns this now. Can you please assign it to the corresponding owner?
It appears we are handling it correctly here
I see is being invoked for gitlens extension when switching profiles, but I do not know why the walk through page is still showing it. I do not know the implementation of it. Can you please investigate from walk through component perspective first to see why it is still being shown?
I disabled gitlens and used the button to reload the window. The walkthrough is no longer there. is that expected?
!
I changed profiles to the one with Gitlens still enabled and there's still no walkthrough
Hmmm I cannot repro this. Can you provide a gif? If I have the walkthrough open and reload my window the walkthrough page doesn't dissapear
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.66.0 OS Version: iOS 14.3 Steps to Reproduce: Safari on iOS 14.3 to any vscode server (e.g. , or ) The Safari developer tools console shows the following error:
. I see references to in the following commits: (soft reference) Thoughts?
As this has been supported since iOS 15, do we want to change this?
The changes introduced in completely break vs code for all devices below iOS/iPadOS 15, the other occurrences of don't seem to have any negative impact according to my testing (anything below 1.66.0 works). The fix I proposed in is a more elegant solution that supports all browsers and does not break anything.
We are generally only aiming for latest and greatest browser version. The use of seems small enough to justify a special case but we shouldn't target a lower version nor is there any guarantee that other things won't break, e.g "fixing" this might just reveal another bunch of blocker etc pp.
Sounds good, forwarding to to evaluate the PR.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: N/A <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.69.0-insider OS Version: Windows 10 Steps to Reproduce: and install from VSIX the test-provider-sample from - this just sets instead of adding test cases. Testing panel and open outcome: shows "expanded arrow" but error message doesn't appear. Error appears in Developer Tools ! ! bootstrap- [uncaught exception]: TypeError: Cannot read properties of undefined (reading 'expand') onUnexpectedError @ bootstrap- (anonymous) @ bootstrap- emit @ node:events:390 window.onerror @ node:electron/js2c/rendererinit:73 platform1.globals.onerror @ bootstrap- TypeError: Cannot read properties of undefined (reading 'expand') at Object.getId (vscode-file://vscode-) at vscode-file://vscode- at (<anonymous) at IndexTreeModel.spliceSimple (vscode-file://vscode-) at IndexTreeModel.spliceSmart (vscode-file://vscode-) at (vscode-file://vscode-) at ObjectTreeModel.setChildren (vscode-file://vscode-) at ObjectTreeModel.setChildren (vscode-file://vscode-) at WorkbenchObjectTree.setChildren (vscode-file://vscode-) at NodeChangeList.applyTo (vscode-file://vscode-) at HierarchicalByLocationProjection.applyTo (vscode-file://vscode-) at TestingExplorerViewModel.applyProjectionChanges (vscode-file://vscode-) at (vscode-file://vscode-) at RunOnceScheduler.doRun (vscode-file://vscode-) at RunOnceScheduler.onTimeout (vscode-file://vscode-) onUnexpectedError @ bootstrap- (anonymous) @ bootstrap- emit @ node:events:390 window.onerror @ node:electron/js2c/rendererinit:73 platform1.globals.onerror @ Uncaught TypeError: Cannot read properties of undefined (reading 'expand') at Object.getId () at at (<anonymous) at IndexTreeModel.spliceSimple () at IndexTreeModel.spliceSmart () at () at ObjectTreeModel.setChildren () at ObjectTreeModel.setChildren () at WorkbenchObjectTree.setChildren () at NodeChangeList.applyTo () at HierarchicalByLocationProjection.applyTo () at TestingExplorerViewModel.applyProjectionChanges () at () at RunOnceScheduler.doRun () at RunOnceScheduler.onTimeout ()
I submitted a PR
/assign


<img width="368" alt="CleanShot 2022-07-18 at 08 28 16 src="https://user-""Configure" and "Manage" are really similar to each other and I had a hard time knowing which one opened what, which caused me to open the wrong one. "Configure" opens the settings UI with a query, and "Manage" opens a custom editor. My proposal would be to change "Configure Workspace Trust" to "Workspace Trust Settings" to make it explicit.
I'd actually like to tweak your proposal to "Manage Trusted Workspaces" and "Configure Workspace Trust Settings"


Repro: Using Open a Remote - WSL folder !
This would probably not be limited to the title, what about the hover over the tab?
The separators seem to be flipped: !
I wonder if could have regressed this, is this a recent regression?
I cannot reproduce, so this is some setting you have or some configuration most likely.
It might be remnants of the formatted caching bug?
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Steps to Reproduce: The documentation has a spelling mistake LINK: -Value of an environment variable on the host machine (in this case, called VARIABLENAME). Unset variables are left blank. To for example, this would set a variable to your local home folder on Linux / macOS or the user folder on Windows:
/ , can you please point me to the GitHub page that corresponds to this page.
Thanks for pointing this out. It looks like we fixed the typo () but have not yet deployed the latest changes.
You are welcome, ! I was trying to fix the issue for Hacktoberfest 2022, but I was unable to figure out in which repo this file was located. Just out of curiosity I would like to know as to where the source file for the page with the typo reside in GitHub?
Thanks for looping me in! Opened a PR in is the repo for


The focus on a search result shouldn't change when removing an element that isn't affected by the removal. ]() Should be like this: ! Likely due to changes in


Remove Manual Folding Range doesn't work Originally posted by in select a range in the editor invoke . Selection turns into a folding range put the cursor at the beginning of the collapsed line invoke . Should remove the manual folding range
It works when the cursor is at the second column or to the right of that, but not when it's right at the beginning of the line, which is exactly where it is placed after running the create manual folding range command.


Testing open the emoji picker (ctrl+cmd+space) drag an emoji into the code editor observe that nothing happens from adding a breakpoint, I can observe that  is never invoked I'm not sure what's wrong, the same steps work fine when loading the editor by itself in a browser using . https://user-
Seems to require holding down shift at the moment even though there is no overlay saying this
I cannot drop an emoji into the monaco playground and also not into the TS playground. It also does not work in However it works on stable and stable VS Code when holding Shift as Matt suggested. I also do not see the drop feedback in insiders, so this looks like a regression to me.
Sorry, I think I got confused because in my insiders I have configured , so I do not see the drop indicator. I see no difference in behaviour between VSCode stable and insiders, so it is not a regression as far as I can tell. I can confirm that pressing makes this work
On our playground it does not work either but I am not even seeing the drop indicator: !
The editor at is around 6 months old, so there it doesn't work at all, I acknowledge that. In my original screen recording I was running the editor from sources. I am quite certain this used to work at some time (when Matt first did the PR at ). I'll try bisecting to see if that points to anything. The initial bisect points to
points to
If I comment out the following lines, then dropping text from TextEdit works, otherwise it doesn't: https://user- https://user-
The safest fix seems to be reverting the fix for by commenting out the block of code. Will push that for July and then investigate a proper solution that also in August
Can't seem to get this to work with the Windows emoji picker and the drag/drop extension sample. Does this only work on mac?
I only tested on Mac and don't know if this is supported on windows. Can you drag emoji into other apps, such as notepad?
Doesn't look like it. Will close and leave for someone on mac to verify then.


Testing In Remote-WSL + bash + subshell, if I run and then use the command decoration to rerun the command, it instead runs . !
This is also the reason may be replaced by ; we're sending the alias resolved command line instead of the raw command line as input.
We should also verify this doesn't happen with aliases in zsh
fyi verifier, reproduces in normal in a non-subshell
to reproduce: in a terminal to see the ones you've defined the part to the left of the command decoration menu, the command's alias (part to the right of ) is the input
it does not
the alias value is also displayed in the quickpick atm
I thought of an even better idea to what we talked about, we could use the old history method to supplement our current better method; if there are no problematic histcontrol settings and the latest history command changed between precious and now, assume it was an alias and use that?
could you verify this one when you get a chance?
still seems to repro in Remote-WSL ! Version: 1.71.0-insider (user setup) Commit: Date: 2022-08-23T10:56:12.685Z Electron: 19.0.12 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
Does show anything? My Ubuntu wsl shows in which case we cannot use that history method which is a known edge case that I don't think we can handle currently and is not worth tracking imo.
Yeah the output is . Is there a value I can change that to which would allow me to verify the fix?
it can be set to the empty string or - set this in your which should run before shell integration
<img width="278" alt="image" src="https://user-"


Type: <bBug</bTesting down in a TypeScript function ! Note that, In the screenshot, is actually at line 1344, the gutter doesn't have enough space for 4 numbers. Also, the visual separation between sticky lines and normal lines looks too subtle for me. VS Code version: Code - Insiders 1.70.0-insider (, 2022-07-29T10:47:14.408Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (18)</summaryExtensionVersion ------ Bookmarks13.3.1 remotehub0.39. remote-containers0.243.0 remote-ssh0.85. remote-ssh-edit0.80.0 remote-wsl0.66.3 remote-repositories0.16.0 material-icon-theme4.19.0 material-theme3.15.2 vscode-eslint2.2.6 gitlens12.1.2 prettier-vscode9.5.0 copilot-nightly1.36.6347 js-debug-nightly2022.7.2717 abracadabra6.14.4 vscode-jest4.6.0 prisma4.1.0 code-spell-checker2.3.4 </details<!-- generated by issue reporter --


Does this issue occur when all extensions are disabled?: No VS Code Version: 1.70.0 OS Version: Debian 10.8 Steps to Reproduce: a zsh shell with a framework like zim installed shell integration zsh Observe: This breaks all my integrations and I lose history, etc... Usually because default settings do things like
In WSL: Ubuntu-22.04, z4h (zsh for humans) is telling me my ZDOTDIR has been set to /tmp/vscode-zsh . I updated to VSCode 1.70.0 and noticed this. It's a shame because the shell integration worked so well in 1.69.x.
I'll check this out tomorrow but it seems like a candidate for the recovery release. In the meantime you can disable shell integration in your settings and install it manually with these instructions:
This appears to be the only change around ZDOTDIR since 1.69:
I will echo this has also broken my shell configuration to load an SDK for a certain VSCode workspace because it hijacks the early on and doesn't provide any hooks to work around that.
I can reproduce this when using a non-login shell. That's because we reset the in the login rc file which only runs for login shells. Unrelated to the history change
Thanks.
we're planning on releasing the fix in the next couple of days
it's already available in the
to verify, set your to something in your . remove the login args from the profile. and verify that it's whatever you set.
As of 1.70.1, macOS 12.5, this is still broken for me:
looks like we should try to detect if this is used and disable shell integration
FYI, I've tested on macOS, WSL/Win 11, and ChromeOS. On WSL and ChromeOS, ZDOTDIR is set to /tmp/vscode-zsh, but otherwise it's the same as on macOS. When I turn off Shell Integration in the settings and open a new Terminal instance, shell integration appears to work. So maybe has the right idea. And as I said earlier in the thread, this worked without issue on 1.69.x.
setting to worked for now
I think zsh4humans uses powerlevel10k which disables shell integration (or will disable it in the next version?). I think to fix this we actually need to add or something similar similar inside this if statement: Alternatively, should this line be moved above the check? To test this without plugins, unsetting inside your rc should repro.
I don't think that line can be moved above or will override the temporary we have set for vscode but think as you said, we need to also add it before returning when it's been disabled
Or can we remove this: Either there or at the end of whatever injected zsh script that runs last.
we could remove it there for non-login shells. for login shells, it gets reset here and probably can remove line 6
<!-- 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'm trying to set in my .zshrc, but it always ends up reset to my home directory, same behavior in stable/insiders. But I'm not sure whether there is something in my zsh config that does that.
the gets set in not your
Tried that, and it seems like ZDOTDIR ends up set to a tmp folder <img width="636" alt="image" src="https://user-"
not sure then - it works for me - it's the only thing in my file though
I encountered the same problem as I used the following version of Insider, which seems to be fixed in commit , but the problem is not fixed. `
hey all, I've also run into this, not 100% sure though if it's exactly the same or "just" related. I use remote container extension with a Debian based container and ZDOTDIR env isn't respected as long as shellIntegration is enabled. Actually I was using regular code but tried insiders after reading the comments here, without any success. let me know if I should provide more details - I tried so many combinations I can't really exactly remember right now, but of course I'm happy to try something specific if it helps.
Is this fix supposed to be live to the stable release now? If so, I am still having this issue when using zsh4humans.
It's not yet in stable. it should be fixed in insider's now though by
Is this fix scheduled for the next stable version? and when would that be?
yes, it will be next week


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