Version: 1.58.0-insider Commit: Date: 2021-06-16T05:18:57.982Z Electron: 12.0.11 Chrome: 89.0.4389.128 14.16.0 V8: 8.9.255.25-electron.0 OS: Linux x64 5.11.0-18-generic After starting up VS Code I got a modal dialog telling me about an unusual line delimiter. It didn't tell me about the file this is about. ! After accepting to fix, I saw where the problem was ! I find the dialog too heavy, especially on startup. I would need to see the code to find out what's the issue here. E.g. in our case, this is in a test, so might be intended Maybe have a warning triage next to 'LF' in the status bar? When I click ignore for this file, how can I unignore the file?
I agree this is pretty weird. The prompt comes from a code editor contribution which executes only when a code editor widget is instantiated and shows the problematic file. I think that this normally works fine, but in this case I believe the problematic file was opened, the dialog was shown, and then the "Release Notes" editor opened under the prompt and changed the active editor from under the prompt. I agree with the feedback here, but I'm not sure what to do. Maybe we could make the "Release Notes" editor wait until all confirm dialogs have been closed before showing itself or that the workbench starts directly with that editor after a release? Regarding converting this to a passive indicator in the status bar: I don't think that would be wise. Having this unusual line terminator will lead to semantic tokens, jump to definition and all kind of language features to become off. Here is the background:
Maybe instead of a modal dialog this could be shown somewhere in the editor area? Almost like the trust banner but instead of showing to the top of the window, showing right above the editor but still inside the editor? ! As for release notes, I think we are investigating to move away from using an editor and using something else but I cannot find the issue now. Arguably this can happen in other cases too I guess, e.g. when I open a file which loads slow and I manage to open another editor over it?
Well, easiest fix is to add the file name into the dialog, I would argue then it doesn't really matter which editor is active.
PR is up to change the dialog just a bit (): !


<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The comments API doesn't have the concept of resolved/unresolved threads, although most code review tools distinguish them. The current API allows us to surface this to the users, see However, this seems pretty limited. I find it difficult to identify all my unresolved comments. It's very easy to miss some of them. If the API had a boolean for unresolved comments, we could surface them in multiple ways: In the Comments panel, surface the number of unresolved comments, similar to what is done with Problems: ! In the Comments panel, highlight the unresolved comments (or put them in bold), so that it's obvious to the user what comments they still have to go through. In the Comments panel, have a way to hide/filter the resolved comments. In the Editor, consider consider using a different background color for unresolved comments. I currently use a different label for unresolved comments, but this is very subtle. In the gutter, use a different symbol for unresolved comments (e.g. or a diamond of another color). In the Editor, provide a way to go to the next unresolved comment (an alternative to ).
Let's discuss the API change. IMO, the information should be part of a . On many levels, Comments seem similar to s. A diagnostic is a comment provided by a tool such as a compiler. A comment is typically provided by a human. Diagnostics have a severity field, which indicates how important is the problem. We need an equivalent for Comments, something that tells the user if an action is expected (e.g. they need to resolve it) or not. Once the user addresses the comment, the importance is reduced. simplistic solution is to add a boolean, e.g. . to , we can go for a two-state enum instead: to be more general: . We might consider having more fields here. In a code review, multiple users interact with the comments. The current VSCode user is not necessarily the person who needs to do something. For example, the user has just updated the comment and they wait for a response. So the third value could be used to mean "it's not my turn" or "acknowledged, I'll come back later". The benefit is that the user can use the list of "unresolved" issues as a TODO-list and publish the comments once it's empty.
Thank you very much for your proposal. and me have quickly discussed this and we believe this proposal makes good sense. We plan to start looking into it next milestone. Though no promises yet when this will land, we will know more in December when we start our investigation.
All of the proposals in have merit. In a perfect world I would choose one of options 2 or 4; however, we have users of the comments API who's comments don't have a resolved/unresolved state. Option 3 circumvents that, but then we have the issue of what to show in the UI: a GitHub PR comment isn't high or low priority. Another proposal, similar to how comment reactions work:
I see than left comments on the commit (). I like the approach of having an object for the state (instead of the proposed boolean/enum), it gives more flexibility and lets user create their own states. In my proposal, the information was attached to a thread, not to a single comment. Do we have use-cases where we want this information per comment? We might also want to control the gutter icon:
GitHub comments are resolved per-thread, so no, no cases were we want it per comment. I'll move it to the thread.
After much discussion, we have decided to proceed with the following: The main reasoning behind this is that resolved vs. unresolved comments should look the same to the user across a GitHub PR extension, an Azure Dev Ops PR extensions, and any other PR extension. There original concern around using "resolved" and "unresolved" is that maybe not all comment provider have those states (maybe they have "viewed" and "unviewed" states for example). To alleviate this, we'll see if we can avoid using "resolved"/"unresolved" language in the UI. If additional states are needed later, we can always add more to the API.
I have a basic implementation of this working, with and themable colors. Before I finish up the pull request to send it out, I was wondering what the best practice is for providing defaults for these colors? In the mocks from we use a yellow for unresolved comments that is inspired by visuals of our internal tool. I am not sure if they match an established VS Code palette.
awesome, looking forward to reviewing it! Generally, we try to avoid introducing a new color entirely for something like this. The best practice would be to look through the existing color values where we use yellow then use the same yellow, just like is done here where uses the same color as : We'll also do a UX review of this, so the color may end up changing anyway.
I went for new colors as the comments are conceptually something different than e.g. editor warnings. Currently the comments in the editor use (default blue), so a theme, an extension, or the users themselves would not be able to style comments independently of peek views. I think it makes sense to base the default on another color like as in your example, so that themes which omit the new colors receive a reasonable default, but it seems like we would give up a lot of flexibility and also clarity if comment widget colors directly used something like internally?
Yes, basing the color on another is what I meant! I agree that we don't want to directly use another theme color.
If anyone is eager for this API to be finalized then please comment and let me know how it's working for you. Otherwise, I will plan to finalize later in 2022.
This would be very nice to have. We are using Github and especially larger PRs are hard to manage, if there are many comments (in Github as well as in VSCode)
So is there currently a way to filter resolved/unresolved comments in the sidebar? If not what can I modify currently to provide a visual distinction between resolved/unresolved?
there's a color difference on the icon, but that's currently it. This is the feature request you're looking for


According to the documentation, if calling show(true), the terminal will be made visible but it won't capture the keyboard focus. I also remember in the past this worked. For some months already I noticed that regardless of how I call show, the focus is always taken. Anything changed? Is there already an issue that you tracking for this? Am I doing anything wrong? Related to this, if we won't manage to fix this behavior, how can we make key bindings for commands to be recognized even when the terminal has the focus? For example, when having focus in the terminal, if I press F5 debugging will start. The terminal will not try to write something for "F5". But if I run another key combination that I defined for some extension command, the terminal will react to the key combination (will try to write something) and the command will not be triggered (unless focus is somewhere else). We have this issue in the CMake Tools repository and the user would be happy if we fix this problem either way.
Hey, I would like to work on this issue. Could you give me any pointers? Where should I start?
this one's a little involved as it needs an extension to trigger the issue, you'd be better off finding an issue with the help wanted label.
Okay, thanks!
Tried this in an extension after making sure I had a terminal open: And the focus moved into the terminal.
did you have focus in the terminal before running that? preserve focus returns the focus to whatever was focused before. I'm unable to reproduce the problem using the exact code you mention above. Could you please include a gif? !
!


In some cases, when the extension host is unresponsive, a window reload can lead to the new extension host process not being able to acquire the lock for workspace storage, since it is still held on by the old (unresponsive) extension host process (). There are even greater concerns that the current way to resolve lock contention (i.e. generating a fresh workspace storage folder e.g. ) is problematic if extensions store very important data in these folders. e.g. suppose a lock cannot be acquired, the workspace storage folder is changed to , the extension writes very important data to , VS Code is closed and reopened the next day, when the extension will end up using as the workspace storage folder, missing out on the data written in (). As a low-risk band-aid, we can limit the acquiring of locks to only the remote extension host, where we have initially observed problems with multiple extension hosts sharing a single workspace storage folder, bringing the local extension host behavior back to what it was in 1.57.x and in the past.
To verify: open a remote window. look at the local extension host log and check that it says look at the remote extension host log and check that it says
The remote extension host log does not say , but instead . I guess that counts too. The local extension host reads .


<!-- 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: Code-OSS OS Version: Windows 10 Steps to Reproduce: IW from codelens IW is initially not pinned, and becomes pinned after the NotebookDocument is modified (e.g. sys info markdown cell is inserted)


<!-- 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.58+ OS Version: Windows Steps to Reproduce: with and . the browser launches, the server throws. This is due to: It should just be . I have a PR to fix this, but needed an issue to reference.


<!-- 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.58.2 OS Version: Linux x64 5.4.0-80-generic Steps to Reproduce: open a vscode window open the embedded vscode terminal any file path to a path that exists, but prepended with the uri 'file:///' prefix (example: file:////home/somedir) ctrl+click on that path error message appears: "Unable to open 'somedir': File is a directory The expected behavior (opening the directory in vscode) works for regular paths (/home/somedir)
+1
duplicate of
Can we get a little explanation of how this is a duplicate? Seems completely unrelated. This is incorrect handling of RFC 8089, RFC 3986 links while the other is failure to handle softlinks while using remote ssh. The issue here is file:// schema is treated as if it can only be a file while on the posix path it detects file vs directory.
Can reproduce the problem, it should say folder not file: ! !
Repros on Windows too. Same thing happens in the editor: ! Above should use 3 slashes:
So the link does work (tried it with multiple folders)... but I guess I expected the underline to include the bit. It's a nit and I don't feel too strongly about it, but thought I'd mention. !
let's wait until is back for that. I'm considering this verified for now
Problem is back, looks a little different though: !
I think the new problem is Windows only


Testing fyi Single click on the instruction breakpoint properly reveals that instruction breakpoint - great. Double click should pass focus to the disassembly view. Just like we do for regular breakpoints
Will fix this.


We only respect the setting when a is found: We should always support the separator.
//cc
Went ahead with a fix myself because I figured it is more involved: without formatting we cannot just add the separator so I ended up using the method that matches the config in that case on the relative path.
Thanks for the proper fix! I had couple of attempts but first failed when list of files in with stopped to work (apparently needed ) Second was but it produced different results for and . Haven't thought about using same normalization as in
what are some verification steps for this issue?
thanks for bringing this up. Steps from : different values for "Copy relative path" for some nested filed - separators should match selection (or system separator for ) I've checked latest version in and looks like fix doesn't work at this moment: apparently won't replace with ! Maybe it make sense to use ?
is a valid character in filenames on POSIX so this is a bit tricky... I don't think we should ever convert it to on a POSIX system as that would represent a totally different resource.
Yep, in name is tricky but is it common case? Anyway: Alternative option will be to "force" path formatting which will work with and I'm assume it will always have as separator that later converted to if needed without causing problem with -that might replace from filenames This will be "similar" to missing formatting as would work with it as with path anyway. But then there will be inconsistency with : - relative as expected, expected separator- relative as expected, expected separator- - not expected but return full path (same as current behavior in ) as it's processed with , separator not supported at all. I'm not sure why returns full path but I guess it's incorrect setup for in web playground, as works OK for files in VS Code desktop.
Reopening with verification steps web on windows .copyRelativePathSeparator: a path from the memfs system that it still uses I can take this as I own label service from Going to push out as products are not affected.
It looks like the code that is typically doing this conversion when a formatting is there is this one: Maybe we can do something similar instead of and replace any of or with the separator.


! //cc
Works great in most cases! Maybe this button needs manual tweaking though to align with the one we have in search view: ! !
Removed the border radius for the expanding chevron: <img width="139" alt="CleanShot 2021-09-13 at 15 40 09 src="https://user-"


Issue Type: <bBug</bthe getting started page split editor split editor cursor on left hand side Bug A scroll bar is shown even though there is plenty of space. Scrolling doesn't seem to do anything <img width="679" alt="Screen Shot 2021-08-23 at 11 19 37 PM" src="https://user-"VS Code version: Code - Insiders 1.60.0-insider (, 2021-08-23T10:42:53.526Z) OS version: Darwin x64 20.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I would like to contribute to this. Can I help you with the issue?


<!-- 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. --VSCode have add a new keybinding for , so, remenber to add ctrl+i for toggleSuggestionDetails which is usiing the same let add this !


Issue Type: <bFeature Request</bWhen foldind HTML tags inside JSX code, the closing tag is hidden and sometimes this make the understanding of the code a little bit confusing. Also, copying the folded code becomes a bit difficult. I was wondering if its possilble to make it work like in HTML, where when you fold a tag it is possible to see both opening and closing tags. Imagine that we have this JSX code: When we fold the tag, it is displayed like this: In HTML the code will be like this, showing the closing tag: so its easier to copy the code and understand the structure VS Code version: Code 1.59.1 (, 2021-08-19T11:54:37.513Z) OS version: Linux x64 5.11.0-31-generic Restricted Mode: No <!-- generated by issue reporter --
Relevant code:
Hi, would love to take this on as my first contribution!


<!-- 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.60.0 (user setup) OS Version: Windows 10 Steps to Reproduce: through VS Code Search tab and tab through all the buttons . ( refresh , clear search results , etc. ) ( Search tab is just an example I can see the same behavior in all buttons) Expected : On the tab navigation to each of the button, the tooltip should be displayed. On escape the tooltip should be dismissed. Keyboard users will not know what is the use of the button through the icon for the button. Actual : User cannot see the tooltip when they tab into a button. They can only see the tooltip when they hover over. !
, Hey, I search to see if there is something already open but couldn't find it. I hope it is not a duplicate.
Dup of Reasons why we are not changing this still hold which I mentioned Leaving this open for tracking purposes.
GitHubTags:#A11yMAS;#A11yTCS;#Win32;#DesktopApp;#A11y_VSCode;#WCAG1.3.3;#A11ySev3;#VisualStudioCode-Win32-Apr2021;#Benchmark;#Visual Studio Code Client;#Keyboard;#CEACCReviewed;
Removing label because we got confirmation from the testing team that this can be moved to Severity 3. Reasoning why this is Severity 3 can be found
Hi , we met the same issue. In our Teams Toolkit extension, we have several buttons on tree items. When user tab to the buttons with keyboard, tooltip will not show: ! Accessibility team has raised a Sev2 bug to us for this issue. Is it possible to fix this?
same issue seen in bug
It can be done in one line due to a contribution by the Edge team to Chromium However, loads of tooltips don't show up, eg this toolbar (top right)- ! Maybe because is on an element which inherits the attribute from a parent element. This can be reproduced on as well.
thanks for investigating. When I make that change, I don't see it working for any of the buttons. Which work for you?
Hi, iirc it worked on New Search Editor, Search (text box), Replace (text input) and the icons in the activity bar. By the way, I noticed then that is missing in the activity bar.
when I test with the above change, it doesn't work for me for any of the buttons. I looked at the docs and it should be supported. Any clue why that would be?
you need to close and reopen after making the change. Reload Window wouldn't be enough. You can also visit in Edge and it should have the same behaviour.
Thanks, yeah, I run OSS to test, which should work, but doesn't.
It looks like we'd need to move all native hovers over to using custom ones to do this.
I sent a draft PR and explained there in more detail what works and doesn't work. (Tested on Windows 10)
I am reverting this for now because we don't want multiple tooltips showing up on hover. I'll try to investigate in December.
Removing these lines, IE the custom hover, fixes the issue, but I worry about making this change so close to the release: it looks to me like we are using custom hovers all over the place because we didn't have this flag enabled before. Do you think we can consider removing those in favor of the native ones?
the custom hovers are better for accessibility as they're exposed to the screen reader. The eventual plan is to move to custom hovers throughout the workbench. Generally if the custom hover is being used a should not be present.
Partially blocked by
isn't this separate to adopting it in different places? I would have expected us to need a focus handler to show the hover for that specific case
This can be closed when happens
Ben has adopted the custom hover in our base widgets, so this may now be easier than before?
Kai mentioned I should consider adding a delay like we have for mouse hovers here. I need to see if this is acceptable by accessibility standards.
AFAICT, the WAI-ARIA guidelines do not specify that there cannot be a delay.
it seems like this already works thanks to your changes
When I tested on native Windows explorer, I saw a delay even when using keyboard, so it seems the same delay should apply for keyboard and mouse.
Currently the mouse and keyboard delays are exactly the same which is what we want. We do not have delays where we support instant hover such as navigating between action items on a toolbar/actionbar. FYI: pressing closes the hover
awesome work!


<!-- 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 (Needs InlineSuggestions from some 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: 1.60.0 OS Version: MacOS Catalina 10.15.7 Steps to Reproduce: GitHub Copilot. The exact version shouldn't be important, but this was verified using 1.4.2586. a blank Python document and enter the following text: There are a single space after each sign. Put the cursor on the end of the first line and trigger Copilot inline-suggestion by pressing Backspace then Space. Don't accept it, but press Down-arrow, Backspace, Space. After pressing Down-arrow the suggestion on the first line disappears (as it should), but after the Backspace+space, you may see the suggestion briefly appear again, before the new inline-suggestion appearing on the second line. This is a bit flaky, and it may not appear every time the cursor is moved. It may also depend on latency to the Copilot server, and so be less pronounced in e.g. North America than in Europe or Asia. Edit by This is the buggy behavior: !
Please let me know soon if we should release this with our Recovery Release tomorrow!
Thanks for your lightning fast fix, Releasing this quickly would be awesome - it's a quite distracting glitch!
can you verify that the issue is fixed in todays insider build?
As he's out today, I've had a play with today's insiders build and can't reproduce it, whereas I can with the insiders build from 6th September. So looks good to me!


<!-- Please search existing issues to avoid creating duplicates. --- VS Code version: 1.59.1 Extension version (available under the Extensions sidebar): v2021.8. OS and version: Linux x64 5.13.11-1-MANJARO Python version (& distribution if applicable, e.g. Anaconda): 3.9 Type of virtual environment used (N/A ...): virtualenvwrapper Relevant/affected Python-related VS Code extensions and their versions: pylance v2021.8.3, jupyter v2021.8., Visual Studio IntelliCode v1.2.14 Value of the setting: Pylance from the VS Code marketplace to see if that fixes your issue] Extension loads successfuly Extension does not load, console reports "Unexpected token ' in JSON at position " [NOTE: Self-contained, minimal reproducing code samples are extremely helpful and will expedite addressing your issue] the extension by clicking a .py file <!-- Note: If you think a GIF of what is happening would be helpful, consider tools like , or . --<details<summaryOutput for <codePython</codein the <codeOutput</codepanel (<codeView</code→<codeOutput</code, change the drop-down the upper-right of the <codeOutput</codepanel to <codePython</code) </summary<p</p</details
Looks like you might have a bad update. Do the following to remove stale versions of the extension: Python extension (if you have pylance uninstall it first). all instances of VS Code. to, (on windows) or on Linux/Mac. any folder with the name starting with VS Code, and install Python extension (also pylance if you uninstalled it in step 1).
I followed all steps, but nothing changed. should I try to install older version of python ext?
Hi Can you try installing an older version of the Python extension, and if it doesn't work can you try a different version of VS Code (either an old one or the Insiders build)?
I've installed python extension , jupyter and no pylance. here's the log: As you said I'm going to install older version of vscode
Hi Did you try installing an older version of VS Code?
FYI - This looks like some JSON stored via the became corrupt. The JSON is written a few lines lower, so it is unexpected that the value is corrupted. This might indicate some kind of bug in the storage layer. I don't remember writing that code, did you perhaps write that? Do you think it is so important such to fail extension activation when the JSON is corrupt, or should we catch that exception and return ?
I would suggest to be more resilient in extension activation as you suggest and fallback to an empty object here if any error rises from but log it as error: This is the first time I hear about a problem with persisting data into SQLite. However, seeing makes me think that this is not an officially supported Linux distribution.
curious if you could share the following 2 files with me (via e-mail is fine: find it on ). Steps: open the VSCode window where this issue happens View Command Palette =Log Storage Database Contents Help Toggle Dev Tools Find the 2 paths for the DBs send both files to me
I can still see the original issue in vscode-insiders v1.61.0-insider
whats the exact version you are on? And is it the issue that the extension fails to activate?
Version: 1.61.0-insider (user setup) Commit: Date: 2021-09-16T08:31:28.161Z Electron: 13.4.0 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: WindowsNT x64 10.0. python extension: v2021.9. Error 2021-09-16 17:51:12: Error discovering pytest tests: [SyntaxError: Unexpected token S in JSON at position at (<anonymous) at a.runTestDiscovery (PATH.vscode-insidersextensionsms-outclient) at runMicrotasks (<anonymous) at processTicksAndRejections () at async (index 0) at async _.refreshTestData (PATH.vscode-insidersextensionsms-outclient) at async v.refreshTestDataInternal (PATH.vscode-insidersextensionsms-outclient)] { stdout: '[{"rootid": ".", "root": "...
I fixed the issue as reported in that extensions fail to activate when the contents in storage fail to get parsed. What you report here seems different to me. Looks like the python extension is calling on something that is not valid JSON? Have you asked the Python extension what this could be?
I see, I'll create a new issue. thanks


Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this


Issue Type: <bBug</ba JS file: Fold and place cursor after the opening of the class Bug Nothing happens VS Code version: Code - Insiders 1.61.0-insider (Universal) (, 2021-09-14T05:14:54.400Z) OS version: Darwin x64 20.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (55)</summaryExtensionVersion ------ salesforce-soql-editor1.8.0 comment-tagged-templates0.3.1 docs-view0.0.9 emojisense0.9.0 folder-source-actions0.2.1 jsdoc-markdown-highlighting0.0.1 markdown-checkbox0.3.2 markdown-emoji0.2.1 markdown-yaml-preamble0.1.0 test-ext0.0.1 vscode-eslint2.1.25 typescript-notebook2.0.3 gitlens11.6.0 tsl-problem-matcher0.4.0 EditorConfig0.16.4 codespaces1.0.5 vscode-pull-request-github-insiders2021.9. vscode-drawio1.6.2 vscode-postfix-ts1.9.4 latex-workshop8.20.2 vscode-platform-specific-sample1.15.0 vscode-platform-specific-sample1.5.0 vscode-memfs0.0.3 template-string-converter0.5.3 vscode-azurefunctions1.5.1 vscode-azureresourcegroups0.4.0 vscode-docker1.16.1 vscode-language-pack-de1.60.3 vscode-edge-devtools1.3.0 python2021.10.-dev vscode-pylance2021.9.2-pre.1 jupyter2021.9. jupyter-keymap1.0.0 remote-containers0.194.0 remote-ssh0.65.7 remote-ssh-edit0.65.7 azure-account0.9.8 hexeditor1.8.2 js-debug-nightly2021.9.417 live-server0.2.8 vscode-github-issue-notebooks0.0.106 vscode-typescript-next4.5. vsliveshare1.0.4836 debugger-for-chrome4.13.0 vetur0.34.1 java0.81.0 code-spell-checker2.0.4 rest-book4.2.0 ayu1.0.5 luna-paint0.9.0 sort-lines1.9.0 vscodeintellicode1.2.14 vscode-java-debug0.35.0 vscode-java-dependency0.18.7 vscode-java-test0.31.3 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I'm trying to document this command but find its behavior difficult to understand and rather unpredictable This could be wrong, but I think it tries looking for the next fold above the current level. In the case above, that means that works if you are inside another method: But it doesn't work if you are in the class body I'd expect this command to work more like where it just jumps to the next folded location in the file
FYI Got to next fold looks for the next fold of the same level. In the example above there's no such fold
Thanks for tagging me, The way I have fold jumping working is that it takes the cursor position and figures out what fold you are currently in. From there, it checks if you want the next previous or parent fold. Parent is pretty easy. It just gets the fold that's at level X - 1. For next and previous fold, they are implemented as the next or previous fold at the same level. The reason for that is because it makes it easy to find associated parts of the file. For example, if you are at an , , or fold, you can easily navigate to the other conditions. Similarly, in the above example, if you are on function , you can easily jump to the other functions that are defined. I don't think it's valuable to jump to the next or previous fold by file order. For example, in the below code it would not make sense to me to have jump to next fold go to b1, then c1, then c2, then a2. Please let me know if you want me to make any changes though.
We need a better label then: ?
That seems reasonable. Want me to do that? I probably shouldn't change the actually command ID though, right? That would break key bindings.
Thanks for the explanation. I agree that this should be renamed. Even with a better name though, I still find the behavior from my example confusing. When the cursor is inside the class body, I'd expect that the folding points for and would be siblings to the cursor's location (because they all have the same folding parent). Instead though we jump out of the class entirely
One other note on the name: maybe the command should call these something like instead of ? Conceptually I think of a as being code you've actually folded, but my understanding is that these commands actually jump between foldable lines in the file
sounds good to me. I see how that's confusing, so I put together this JS sample to illustrate where the "next fold" is for different cursor positions: Cursor 2's next is straightforward since you're on a folding point. Cursor 3's next I think is reasonable. You are in a fold, so you find the folding point and go to the next of that. Cursor 1 and 5's next start getting a little weird, but following the same logic as cursor 3, it seems logical that is the folding point, so the next sibling is at . Cursor 4 is basically your original question. I agree that it gets a little confusing. The logic is the same as 1, 3, and 5, but visually, if you're between 2 folding points, I could understand the desire for it to go to those points. I think the confusion stems from using the command when you're not on a folding point line. If you are, I think it's easy to understand, but when you aren't, not so much. What do you think of the following? If you are on a folding point line, do what it does now. not, go to the next folding point sequentially. With those updates, the above example looks like this:
We don't use 'folding points' as a term. I suggest 'folding range'
Ok. What do you think of changing the implementation as I mentioned in my previous comment?
Yes I like the suggestion (I thumbed up it :-) )
I wish I could turn on reaction notifications in GitHub. I implemented this in . I update the command from "Fold" to "Folding Region", but I did not add "Sibling". I hit a bit of a dilemma there. With the change, it's no longer necessarily a sibling. However, I can still see people getting confused by previous or next folding region command "not working" when you are on the first or last sibling folding region's start line. For example, in the above example, the previous command won't move you when you are at . I think that's really valuable. It lets you move up and down the different cases of branches without going past them. I wouldn't want to run previous at and end up at , then next brings me to . Any suggestions for that? I'm pretty sure nobody would want the command label to be "Go to Previous Folding Range, but Stop at First Sibling", but that's essentially what this does.
/verified Looks to follow the logic set out by I used this example: When on line 8 it jumps nowhere is a little confusing, but that's because the next folding range is the current?
That's because it's the last sibling. The benefit is that you can move to previous and next sibling folding ranges without stepping out of them (at which point going to the next or previous sibling won't be the original set of siblings you were on). I agree, it's confusing, but I think it's valuable to do it this way.


This new capability allows the terminal to control when the tab description shows, so we can align the description in the terminal editor with how it shows up in a terminal panel tab.
To verify: Run a task, move the terminal to the editor area, check that the description shows up like it did in the panel In a terminal, change the directory, verify you see it in the tab description in the panel Move that to the terminal editor, make sure you see it there as well
Is this tooltip the task description? <img width="486" alt="image" src=""I think I'm a bit confused on how a task would be affected by a different terminal changing directories.
drag the terminal into the editor area and you should still see in the label of the tab.


I just reloaded a window with my repo open, and it attached to a terminal which is already open in my repo, so now this terminal is open in two windows: ! The right window is the window that originally owned this terminal One thing about this terminal is that its cwd is some other folder outside of both workspaces, if that matters.
I reloaded the left window again, and it reattached to the correct terminal. !
Just so you know, this happens pretty often. I just reloaded a window and got some random terminal from another window. Let me know if I can collect any other info
Also hit this, I believe it was after restarting insiders for an update. !
I was able to repro once out of many attempts. I wonder if there's a command to reload all windows to simulate what happens on update? Maybe then I'd see it?
exiting the application (cmd+q) and reopening it is essentially what happens on update
Something similar just happened with the most recent insiders update, but now the terminals aren't synced, it's just that the working directory of one window's terminal is set to the other window's root instead of it's own. <img width="1440" alt="image" src="https://user-"
Happened again, accidentally ran a destructive command in the wrong directory :( cc is there any logging or something I can enable to help you get to the bottom of this?
I spent awhile investigating. I don't understand what could be going on here because we store and reconnect to terminals according to the workspaceId. said that he thinks it's a race condition. Setting log level to trace and toggling the shared process would help when it reproes
Today I had something new happen: had 3 VS Code windows open. reloaded window 1. 1 now shares a terminal with window 3! Totally different workspaces. No other windows were reloaded. No windows were closed. Is there a way I can disable terminal reconnect for local windows? I've also run destructive commands when this happens and I don't want to risk it.
Yep, it's not working atm for remote terminals, so:
Hello everyone, there is any plan to try to fix it in the nearest milestone?
This code that we for transferring terminals via dnd between windows looks suspicious
Has anyone seen this in awhile? I cannot reproduce
I don't remember seeing it recently
Okay pls reopen if you see it again and I'll be happy to debug with anyone that can reproduce it
Sorry, I cursed myself because this happened again today but I probably won't have consistent repro steps. I reloaded the window with my vscode workspace and got a terminal from this extension sample which is also open in another window, although the terminal panel had not been made visible in that other window's session yet. I reloaded the window several more times and always got the right terminal after that. <img width="1049" alt="image" src="https://user-"
we don't create a terminal until you open the panel, so what do you mean by the terminal had not been made visible yet?
In case it is important to the issue, I'm just saying that the drop-on-document terminal that was wrongly attached to the vscode window hadn't yet been attached to the drop-on-document window, because it was from some earlier session.
I also used to see this periodically but I've had terminal reattach disabled to avoid it. Let me know if it will be helpful and I'll re-enable reattach!
Same as
Yes it would be very helpful I spent 90 mins yesterday trying to reproduce to no avail. If you could enable trace logging too in case you repro, that might give the insight we need
We should review the code around terminal adoption of orphan processes, I suspect the issue is that it's not transactional.
it appears we're only doing an orphan check on terminals that are in the workspace as set in the map
I think somewhere all unadopted processes get taken by some window? Might not be remembering right though.
If you see this again after lands, please enable trace logging and get the output channel logs for Pty Host and Window.
I was seeing this previously on occasion but haven't seen it over the last week so marking as verified
+1 on no longer seeing it since re-enabling re-attach a few weeks ago.
Just saw this again. The incorrect re-attach occurred on 1 July and I only noticed it today. Pty logs: Window logs
This seemed for a while like it'd stopped happening, but just ran into it again: In my case I'd just reloaded a single window.
Just had this happen again, but once again I didn't have trace logging on. I'll try to leave it turned on for next time. Pty Host logs: Window logs:
Could the needed log statement to troubleshoot this on the terminal side be converted to an log. That might help track down this bug sooner.
they're actually warnings already so they should show up:
Just ran into this again. I have the same terminal restored in two distinct windows. I ran into this after restarting to update Insiders on macOS (I had 6 folders opened). The Pty Host log contains the following: https://user- Maybe might know if there's a way to easily simulate a restart caused by an update. Alternatively, maybe you can try changing a setting like which shows the restart prompt. I think this also leads to the terminals attaching incorrectly.
Might be related to (maybe not as that's remote only?)
this is a little confusing to me. No reconnect is meant to happen on restart, when updating node-pty gets replaced so it can't be running, all processes are torn down and the pty host shuts down with the main process. Did you see this? !
Changing this to always return isOrphan = true: I can get it to reconnect which is meant to be prevented by one of my other changes.
It's a little suspicious that the entry doesn't get deleted: That determines here which can bypass the orphan check:
I can confirm that within the last two days (both before and after the upgrade to 1.70.0) it has happened to me both on window reload and on full VSCode restart.
When I see this it also happen on restart.
do you see the history restored message when it happens on restart?
Yes, I see this every time when restarting to install a new version (Gear Restart to Update) or when changing the setting : <img width="473" alt="image" src="https://user-"
I'm 99.9% certain the answer is yes, but I will make sure to notice the next time it happens.
Ok, I figured this out. What a journey! Here is the fairly reliable repro: Clear state - Given 2 folders and Open folders and and close all terminals File Exit Setup for the process revive - Window : Open 3 terminals and type "a", "b", "c" into them respectively, this helps identify them to ensure they're in the correct order later Window : Open 3 terminals and type "d", "e", "f" into them respectively File Exit Process revive - Window and should revive the processes and have all terminals in the correct order they were created (this works) Process reconnect Reload window and window at the same time Window and should revive the processes and have all terminals in the correct order they were created :bug: Note that this is a timing issue and has a chance to not reproduce the problem. This is what is meant to happen when exiting and restarting the pty host process. Terminal processes are revived (aka. re-created) and their actual pty IDs for this pty host process are mapped to, starting at 1. Notice below how the new IDs start from 1, they just represent the order they are created in which shouldn't matter when reviving. After that, when reloading windows, terminal processes do not get revived but reconnected to. So an mapping is expected: What is happening and what is causing this bug as well as a related issue[^1] is that the revived pty ID is cached, so if reloading happens to use a that is mapped to a different pty ID in , it will reconnect to that one instead: The above results in: Then on reload the pty ID mapping occurs instead of being undefined, which causes a reconnect_ to the wrong pty. So in the above they get re-mapped, shuffling the order within a window and potentially connecting to a different window's ptys: ! [^1]: The folder's terminals may not get restored at with the warning "Couldn't get layout info, a terminal was probably disconnected" in the pty host output channel. This started happening due to one of the previous workarounds to prevent 2 windows attaching to the same pty.
Wow. Nice detective work! Thanks, looking forward to the fix.
Reported here
I actually saw it again once earlier this week too. It does seem to happen significantly less often than it used to.
I just ran into this again today. After a restart due to an update, I got a terminal from a folder showing up by itself in folder . Here's the only relevant content I found in my logs:
I hit this today. Moving this forward to January 2023, since it probably was just lost in the queries by being assigned to August 2022.
I've hit this once per day for the past several days. It seems to be occurring more frequently again.
This would probably be addressed if terminals moved into utility process and there was a message port per terminal:
Using the new pty host trace logging, this is what happens on a reload with a single terminal that will be reconnected, with the environment parts truncated:
I believe this is now fixed as a part of I'm still not able to reproduce but the current theory is that the async isOrphan check that was removed in the PR was not only delaying reconnection by 4 seconds, but also causing a race where the wrong window could adopt it. Instead we no longer check whether it's an orphan and trust the saved workplace state to be correct.
Thanks for following up
I haven't seen this in a long time. Not sure whether there is anything that can be done to verify it.
I just ran into this now: had ~4 windows open: Window 1 is vscode-pull-request-github2 : terminals cwd were all in the workspace Window 2 is vscode-pull-request-github: terminals cwd were all in the workspace Window 3 is repo1: 2 terminals, both of which had a cwd outside the workspace Window 4 is vscode: terminals cwd were all in the workspace VS Code reattach: Window 1's terminals are correct Window 2 has reattached to one of Window 3's terminals and has lost it's original terminal Window 3's terminals are correct Window 4's terminals are correct. Pty logs from Window 2:
thanks for the info! Looking into it
I spent a few hours looking into this, here are my findings: This warning in the logs is common across recent failures: , I tried and tried but could not reproduce this on Insiders or OSS I'm adding more verbose logs to the info log level that gives me the old/new pty id mapping as well as dumping a bunch of info when the above error happens I looked into whether should be correct and while I found it could cause issues when the pty host restarts (), it seems like it should work after a restart I could the cwd being outside the workspace would make a difference as we don't even take that into account when reviving the proc () The management of would be a lot simpler if we moved the id to being a guid instead of a number, but that would be a shame as we then need to send the guid along the wire for pretty much every request to the pty host I looked into possible race conditions where could get stale/invalid values. Both a thorough review of the code and injecting timeouts (random, differing by window) into important calls didn't cause problems Current plan is to wait for to merge and await a repro with these logs present, then analyze them. I'll also likely be continuing to fiddle with terminal reconnection in debt week to improve perf further and reduce redundancies.
I'll keep an eye out for this and try to maintain a setup similar that one that I just saw it with, but I have to say, this has gotten so much better. I almost never see it.
I tried to repeat my setup before updating, and it did happen again. Setup: Window 1 is vscode-pull-request-github2 : terminal cwd is outside the workspace and on a different drive (C vs D) Window 2 is vscode-pull-request-github: terminals cwd were in the workspace Window 3 is repo1: terminal cws was in the workspace Window 4 is vscode: terminals cwd were all in the workspace After update: Window 1 is vscode-pull-request-github2 : has a new terminal Window 2 is vscode-pull-request-github: correct Window 3 is repo1: has attached to Window 2's terminal and now they share the same terminal Window 4 is vscode: correct Logs:
Thanks it seems there's some inconsistency with the layout info and the revived procs, so I suspect this silently error swallowing now: Added logs for that here: , I'll merge for July so you might not be able to test for a week but when you do please also grab the Terminal output log as this is renderer side.
Cross post
With logs in , I was able to reproduce the problem! ! The repro is very complicated, it is essentially trying to get into a state where 2+ windows have "old pty ids" that conflict with one another, and then increasing the latency of the pty host in order to force the race condition to show itself. these settings: default log level to trace all windows window 1 (W1) with folder A 1: Open 2 terminals 1: Close window 1: Open window 1: Open pty host log, you should see this: window 2 (W2) with folder B 2: Open 2 terminals 1: Close window 2: Close window VS Code (W2 should open) 2: Open pty host log, you should something like this: 2: Close window an external terminal and type another external terminal and type the commands in both terminals in quick succession 1|W2: Open pty host log, you should see something like this: The terminal with end up attaching to the wrong pty. The fix for this is simple, just add workspace ID as part of the key of the old id, so becomes . This should make conflicts impossible to occur.


The <kbdToggle Size to Content Width</kbdcan only be toggled a few times, before freezing completely. Resizing terminal could reset it. https://user- Does this issue occur when all extensions are disabled?: Yes System info:
please see my explanation on
Thank you for your detailed explanation. I did test on the insider version, the blur seems to decreased with smaller canvas required but this freezing issue still happens all the time. Moreover, the issue is only on Linux so I'm not sure the explanation is quite sufficient to describe this. Let me know if there's anything I missed, thanks again.
when you do this how long as the lines you're working with? ideally, we probably need an upper cap based on the environment's max canvas size (which would need some searching).
It's hard to say when the doesn't work as expected this time. Do you have any idea to get this revealed? https://user-
when the width of the longest line is less than the width of the terminal, as is featured in your gif, toggling the width won't do anything (by design).
thanks for your information, I did some tests again and got some conclusions: in the menu doesn't work, so I recorded with shortcut . IIt also freezes after the second as expected (bottom scrollbar indicates that): https://user- lines hidden when press are affected (still freezes after the second toggle): https://user- number 2 above seems to happen almost every line length: ! Let me know if I can do any more tests to provide more information.
As compared with how this works for windows/mac, linux is broken given the same text content !
This actually is working by design - when you copy and paste, it includes newline line endings that will indicate to the terminal that line isn't wrapped.
based on , it seems like we should go with the min value since we don't want to calculate this per platform/browser, so going with 8000
I started on Windows to try to understand how works. It didn't appear to do anything on Windows. On linux, I can see the toggle happen, but there is no scroll bar.
it will only happen if there are wrapped lines. so increase the line width or resize the terminal to be more narrow.
the scrollbar is very low on linux and i'm not sure why. I'll open an issue for that - separate from this one
Windows !
thanks, i'll make a new issue for that
Now the same thing is happening on linux too. I will leave this for someone else to verify.
Thank you for getting back. I've tested with the insider build but it doesn't work, I've thought it was some sort of thing related to my particular machine, which confuses me these days. So it's good to track that again on a new issue. Most of behavior I have described in I don't spend much time on Windows so didn't test carefully. Let me know if there's anything else I can do.
Because of the way this feature works where it stretches the canvas to the size of the content we are limited by the canvas API. As a compromise I'm going to add a cap to the number of columns the terminal can take up.


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled? Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.61.0 Commit: Date: 2021-10-07T18:11:58.853Z Electron: 13.5.1 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 Steps to Reproduce: the Terminal Sample from the vscode-extension-sample repository the a task that reuses a terminal. For example, I used a user task like: On the first run of the task the 'link' text will create a hover link correctly. If you re-run the task so the terminal has 2 (or more) runs of the task in the same terminal then the link will fail to detect correctly. Adding a breakpoint to there appears to be 1 call per execution of the task in the terminal. I think when the terminal is re-used it re-registers the link provider and if two link providers have overlapping links they both seem to fail (which is a known issue but due to this bug all link providers start failing if tasks are run multiple times).
Putting a breakpoint in the registerLinkProvider call for xterm (here ) I see multiple copies of all of the link providers: <img width="574" alt="Screen Shot 2021-10-12 at 9 15 30 AM" src="https://user-"


Issue Type: <bBug</bI'm using MacOS. After opening VSCode and getting into full-screen mode: If I use the integrated terminal of VSCode to create a new file, e.g.: VSCcode switches my screen to my previous workspace that causes interruption of work. Everytime I use to create a new file, I'll have to use + to move back to VSCode. VS Code version: Code 1.61.1 (, 2021-10-14T01:23:30.274Z) OS version: Darwin x64 20.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ code-runner0.11.6 terminal0.0.10 go0.28.1 vscode-docker1.17.0 python2021.10. vscode-pylance2021.10.1 jupyter2021.9. jupyter-keymap1.0.0 jupyter-renderers1.0.3 remote-containers0.202.4 remote-ssh0.65.8 remote-ssh-edit0.65.8 remote-wsl0.58.2 vscode-remote-extensionpack0.21.0 vscode-yaml0.23.0 code-settings-sync3.4.3 open-in-browser2.0.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I am not sure if this could be a regression from the work we did to use the command.
I just built a version without the open cmd fix, but still saw the behaviour. I'm wondering if it could actually be caused by changes made during Edit: It seems reverting both commits fixes the issue.
It is unrelated to my changes. When I simply change this line to always go into the of : It does not reproduce anymore. Looks like when we are using , macOS does not really know whether a new window opens or an existing one reused. I feel this is a pretty bad regression actually.
I see that has fixed this bug and merged the PR. It seems like this is in (not sure what that means) but the issue still persists. I wonder when will this be fixed? In the next VSCode update? Thanks.
It should be fixed in our current latest stable release ().
Thanks, Just updated to today and I confirm that it's fixed.


<!-- 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: latest OS Version: macOS 11.2.3 Steps to Reproduce: repo npm version < 14 or ≥ 17 to see this message message or just read the commit diff to see the problem
from check is for ≥ 17 but error message says to use ≤ 17, thus exactly v17 is both valid and invalid


Copied from My workaround is export VSCODEGITASKPASSEXTRAARGS="--title=foobar" but the proper bugfix should happen in VSCode's GIT_ASKPASS implementation.
I experience the same problem, from the moment been released. Working through remote ssh the git processes stay open, without anything happening.
Still facing this issue on WSL.
Will be fixed in upcoming 1.62.2. Meanwhile a workaround is to and then manually
I can confirm that this is fixed after updating to 1.62.2 ().


! It could be that I caused this, but I doubt it (injected text has nothing to do with the gutter, maybe they shared a CSS rule).
I can reproduce but I'm not aware of any changes in that area from the debug side.
I would like to work on this issue!
Before fixing anything we should do a "git bisect" to find the commit that broke this.
commit . it should
thanks for pointing out the commit! If you like, you can provide a PR, that would be awesome!
PR


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- 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: git commit (1 Dec 2021), with openvscode-server patches until commit Browser: Firefox OS Version: Ubuntu 20.04 Steps to Reproduce: a freshly opened window, open or type some text in it. Try using Ctrl + Shift + Right, text should be selected at word boundaries. a terminal, then close it using command. using Ctrl + Shift + Right again. Expected: Text should be selected at word boundaries. Actual: No text is selected. Cursor doesn't move at all. This is the the same issue as filed at [1] and [2]. If it's reproducible in 3 server implementations (counting openvscode-server), then it's probably an upstream issue. Sadly I don't have an access to GitHub Codespaces, so I can't verify it with an "official" implementation [3]. You'll notice in keyboard troubleshooting log below the following 2 lines: It's been suggested in [1] that vscode might still think that is active despite the terminal is closed. Thus, a workaround I've been using is to have the following in (with default unbind): That is, wherever exists, augment it with . [3] I mean, doesn't have terminals. I've tried using Live Share; that doesn't change. See Keyboard shortcuts troubleshooting. The first keypress is before the terminal is opened. The other two are after it's closed. <details<pre[2021-12-03 01:36:00.490] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 17, key: Control [2021-12-03 01:36:00.503] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 5 ('Ctrl') [2021-12-03 01:36:00.509] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:00.513] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 16, key: Shift [2021-12-03 01:36:00.517] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 4 ('Shift') [2021-12-03 01:36:00.521] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:00.808] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 37, key: ArrowLeft [2021-12-03 01:36:00.813] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 15 ('LeftArrow') [2021-12-03 01:36:00.817] [window] [info] [KeybindingService]: | Resolving ctrl+shift+[ArrowLeft] [2021-12-03 01:36:00.821] [window] [info] [KeybindingService]:  From 2 keybinding entries, matched cursorWordLeftSelect, when: textInputFocus, source: built-in. [2021-12-03 01:36:01.146] [window] [info] [KeybindingService]: + Ignoring single modifier shift due to it being pressed together with other keys. [2021-12-03 01:36:03.304] [window] [info] [KeybindingService]: | Resolving [KeyE] [2021-12-03 01:36:03.310] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:03.401] [window] [info] [KeybindingService]: | Resolving [KeyE] [2021-12-03 01:36:03.406] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:03.737] [window] [info] [KeybindingService]: | Resolving [KeyX] [2021-12-03 01:36:03.744] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:03.832] [window] [info] [KeybindingService]: | Resolving [KeyX] [2021-12-03 01:36:03.838] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.210] [window] [info] [KeybindingService]: | Resolving [KeyI] [2021-12-03 01:36:04.218] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.344] [window] [info] [KeybindingService]: | Resolving [KeyI] [2021-12-03 01:36:04.348] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.396] [window] [info] [KeybindingService]: | Resolving [KeyT] [2021-12-03 01:36:04.404] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.518] [window] [info] [KeybindingService]: | Resolving [KeyT] [2021-12-03 01:36:04.523] [window] [info] [KeybindingService]:  No keybinding entries. [2021-12-03 01:36:04.762] [window] [info] [KeybindingService]: | Resolving [Enter] [2021-12-03 01:36:04.769] [window] [info] [KeybindingService]:  From 20 keybinding entries, no when clauses matched the context. [2021-12-03 01:36:04.824] [window] [info] [KeybindingService]: | Resolving [Enter] [2021-12-03 01:36:04.827] [window] [info] [KeybindingService]:  From 20 keybinding entries, no when clauses matched the context. [2021-12-03 01:36:06.677] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 17, key: Control [2021-12-03 01:36:06.685] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl], code: ControlLeft, keyCode: 5 ('Ctrl') [2021-12-03 01:36:06.689] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:06.692] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 16, key: Shift [2021-12-03 01:36:06.696] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ShiftLeft, keyCode: 4 ('Shift') [2021-12-03 01:36:06.700] [window] [info] [KeybindingService]:  Keyboard event cannot be dispatched in keydown phase. [2021-12-03 01:36:06.766] [window] [error] Cannot refresh property when process is undefined: [2021-12-03 01:36:07.142] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 37, key: ArrowLeft [2021-12-03 01:36:07.147] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 15 ('LeftArrow') [2021-12-03 01:36:07.151] [window] [info] [KeybindingService]: | Resolving ctrl+shift+[ArrowLeft] [2021-12-03 01:36:07.155] [window] [info] [KeybindingService]:  From 2 keybinding entries, matched , when: terminalFocus && terminalHasBeenCreated terminalFocus && terminalProcessSupported, source: built-in. [2021-12-03 01:36:07.913] [window] [info] [KeybindingService]: / Received keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 37, key: ArrowLeft [2021-12-03 01:36:07.920] [window] [info] [KeybindingService]: | Converted keydown event - modifiers: [ctrl,shift], code: ArrowLeft, keyCode: 15 ('LeftArrow') [2021-12-03 01:36:07.925] [window] [info] [KeybindingService]: | Resolving ctrl+shift+[ArrowLeft] [2021-12-03 01:36:07.930] [window] [info] [KeybindingService]:  From 2 keybinding entries, matched , when: terminalFocus && terminalHasBeenCreated terminalFocus && terminalProcessSupported, source: built-in. [2021-12-03 01:36:08.344] [window] [info] [KeybindingService]: + Ignoring single modifier ctrl due to it being pressed together with other keys. </pre</details
I can't reproduce this issue in Firefox or Safari.
you mentioned Safari, which implied that you have macOS. Could you please re-try using Linux or Windows? macOS uses Command key for those keybindings, and so duplicated keybindings doesn't exist. Folks at cdr/code-server can't reproduce it on macOS either, but subsequently can reproduce it on Linux. Please re-open this issue.
doesn't reproduce for me there either !
That looks like Microsoft Edge, based on Chromium engine. Could you please try again on Firefox?
I can reproduce this in Ubuntu/Firefox
Does not repro on Ubuntu/Edge
Created a PR with a workaround


<!-- 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 In make a new keybinding: Intellisense shows many arg keys that are inaccurate or not implemented. Here is what I get for intellisense: These appear to be the correct and implemented args to this command: Version: 1.63.0-insider (user setup) Commit: Date: 2021-12-02T05:15:40.605Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.
Related:
This issue persists as of vscode I was going to open an bug issue mentioning that some params were not working... when in fact I was using the ones suggested by the intellisense e.g. instead of . A while back I opened: about how the command does not resolve variables whereas does. Also related I guess needs some love to be more consistent feature-wise with .


Issue Type: <bBug</b(sorry, these are not good steps because I can't figure out exactly what triggers this) a language pack installed (I have the german pack) a new workspace or reload VS Code Bug Sometimes I get a prompt to switch display languages. I select no but the prompt will come back again later I see this maybe once or twice a day and haven't figured out exactly what is causing it VS Code version: Code - Insiders 1.64.0-insider (Universal) (, 2021-12-14T13:26:59.630Z) OS version: Darwin x64 21.1.0 Restricted Mode: No <details<summaryExtensions (53)</summaryExtensionVersion ------ salesforce-soql-editor1.8.0 tsl-problem-matcher0.5.0 comment-tagged-templates0.3.1 docs-view0.0.9 emojisense0.9.0 folder-source-actions0.2.1 jsdoc-markdown-highlighting0.0.1 markdown-checkbox0.3.2 markdown-emoji0.2.1 markdown-yaml-preamble0.1.0 test-ext0.0.1 vscode-eslint2.2.2 dendron0.73.0 dendron-paste-image1.1.0 typescript-notebook2.0.6 gitlens11.7.0 EditorConfig0.16.4 codespaces1.4.2 copilot1.7.4273 remotehub0.20.0 vscode-pull-request-github0.35. vscode-drawio1.6.3 vscode-postfix-ts1.9.4 latex-workshop8.22.0 vscode-platform-specific-sample1.15.0 vscode-platform-specific-sample1.5.0 vscode-memfs0.0.3 template-string-converter0.5.5 vscode-azurefunctions1.6.0 vscode-azureresourcegroups0.4.0 vscode-docker1.18.0 vscode-language-pack-de1.63.3 python2022.0.-dev vscode-pylance2021.12.2 jupyter2022.1. jupyter-keymap1.0.0 jupyter-renderers1.0.4 remote-containers0.209.6 remote-ssh0.70.0 remote-ssh-edit0.70.0 azure-account0.9.11 hexeditor1.8.2 js-debug-nightly2021.11.1217 live-server0.2.11 vscode-github-issue-notebooks0.0.113 vsliveshare1.0.5196 debugger-for-chrome4.13.0 vetur0.35.0 code-spell-checker2.0.13 rest-book5.0.1 ayu1.0.5 luna-paint0.11.0 sort-lines1.9.0 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
please ping if you need help with this.
Here's the code that seems to trigger this: Would extension updates also trigger this?
and I looked into this with and we were shocked to see that background updating of an extension had an InstallOperation of "Install" and not "Update" Is this correct Easy repro steps: Using OSS with the marketplace Place a breakpoint on the line linked above ^ (or just at the top of ) Install an old version of a language pack No longer "Ingore Updates" Reload the window Your breakpoint will hit when the language pack updates to the latest version again and you'll notice the is set to (aka 2) instead of .
Yeah, it's a bug on my side that I am not propagating the operation properly. Sorry about that. Fixed.
I did a lang pack install and used it for half a day and didn't seen any prompts to switch display language. Is there anything other way to verify this?
I have the German language pack installed but haven't been using it. I haven't seen any prompts to switch to German recently so :+1:


I do not see the notification toast when I select "New Terminal" from command palette. But I see this issue that the OP reported I think: ! ! Originally posted by in
I see this problem: Start a new terminal - full screen Drag to bottom or right = non-functional If you split the panel right, it is fine
Reproes only when you have more than one terminal in the editor area
Can do it with a single terminal, clean open of VSCode (mac), no other windows. !
Thanks, I specifically meant when dragging and dropping into the panel.
/verified second terminal is no longer blank


allows extensions to disable the "Open Preview" button in markdown files. This option should also disable the "Open Preview" button in the context menus. ! Originally posted by in
/verified In stable: ! In insiders: !


Parent issue Update: Activate the fish shell integration by following these instructions: We're keeping this open until automatic injection is looked into.
Deferring to focus on polishing how shell integration works in general
Final implementation details aside, fish's event handing will make at least some of this dead easy: Some will be more difficult, at least to deploy auto-magically, because fish's are the output of shell functions, not the contents of variables: So to transparently preserve the user's original prompt, like the bash script does, would require modifying a shell function on-the-fly, not just a variable. Yikes. That said, I put the above code, plus the following, in my own config— —and I had all of VS Code's working perfectly with VS Code v1.70.0 + fish 3.5.1. It's only a proof of concept, but hopefully this saves somebody a few web searches down the line, at least. :)
very handy info thanks! The bash script handles both PS1 and PRONPT_COMMAND, might be able to wrap the function automatically in a similar way?
Well, fish doesn't have either: if you want something to run right before the prompt displays, you put it in a function with . There is, alas, no event handler that runs after displaying the prompt but before accepting input (which is where you'd want ). There are also no events specific to the right-side prompt only. FWIW, there's also no equivalent in fish—"instead it leaves the lines indented to show that the commandline isn’t complete yet"—but the lack of and sequences in the above didn't seem to have any noticeable impact on VS Code's ability to parse the terminal in my testing.
ah I see, I think this stuff should still work though. We actually don't currently use some of these positions and the 633 E sequence kind of removes the need for them all together. So if there are limitations like this we can just take note for the future, like when finalizing the sequences this month. The limitations imposed on us by the Windows backend are much more frustrating to deal with than this sounds If you want to put a PR out with just the script as a starting point (just the script) we could then give it a try and see if we can get it in as an experimental thing. I guess just manually installing until it's considered stable, plus the automatic injection was a handful for the other shells. You could also move the 633 A to just after 633 D, I'd expect that to work fine.
I've been wanting to do this since last month, and comment finally motivated me to put up a fish plugin here: The trick I have seen in is that they wait for a event and then initialize the code, at which time the prompt function should be ready however they are defined.
FYI those sequences may change as they are yet to be finalized ().
Now that has reminded me fish can do e.g. (which I just... totally blanked on yesterday ), I think I could put together an experimental PR for this—one that could be easily tweaked if/when the escape sequences are finalized.
Also thanks to a PR from the fish history file is now loaded so pulls from it when fish is active !
that would be fantastic
Thanks everyone! The script should be available in tomorrow's Insiders, see for manual install instructions (replace with ) I'll keep this issue open until we no longer consider it experimental.
The new function does not work properly in my case. My fish configuration uses a right prompt and shows the exit code of the command (green check mark). The exit code is always shown as good, even if the executed program returns a non-0 code. The right prompt is also misaligned. It is one line below where it is supposed to be. ! The status code issue seems to be caused by executing first, because this will overwrite and . The misaligned right prompt seems to relate to some newline shenanigans fish does. It removes the last newline from the prompt, but since is after the prompt it doesn't work any longer. I found these related links: , I change the above snippet to this it seems to work better for me.
thanks for the report! Do you want to submit a PR or should I try out the fix?
I am not interested in progressing this further or submitting a PR.
no worries, thanks for reporting
Isn't this already done? Or is this about automatic integration?
I was keeping it open until the kinks were worked out, plus automatic injection would be great if it's possible. Not sure anyone has looked into it yet.
should we change the title of this issue or create a new one to capture automatic injection?
i think the right way to add automatic injection would be to append a directory to that contains the integration script in a subdirectory (see )
we wouldn't be able to stick it in XDGDATADIRS though in case a user has a file there already. Changing XDGDATADIRS also seems dangerous and I think this would only work on Linux
it sounds like you may be confused as to what XDGDATADIRS is so i whipped up a pr for this, with links to the relevant spec and fish docs. alternatively i'm confused as to what you might mean. XDGDATADIRS is a set of directories to search for data files, ordered by preference. we'd be adding a directory to the end of it so what a user may already have there is irrelevant, and our directory would be part of the vscode distribution so the user really shouldn't have any files in there. aside from that user things go in XDGDATAHOME, XDGDATADIRS is for system components. i'm not sure what danger you see there. we're adding another directory to find data files in; we're not preventing any other data files from being found. this is documented universal fish behavior on any system it supports. i linked the literal default fish configuration above that demonstrates this. also back when i last used a mac most tools did support the xdg base directories, including fish (and nix, which makes rather heavy use of XDGDATADIRS). the only ones that didn't still don't on linux (like electron ).
oh it's a list of dirs, I thought this was setting a single dir. And you're right we don't need to worry about Windows here. Thanks, will check out the PR soon
Since the issue is now closed, is the problem reported here something you would still want to fix? It doesn't seem to be fixed on main so far.
thanks for the reminder, I forked it off to
To verify: Make sure fish is installed on your system (macOS or Linux) Launch a fish shell and verify the shell integration decorations should up to the left of the terminal
yep, works for me!
Unfortunately this does not work in a newly-installed fish shell via homebrew on macOS. https://user- Pty host logs:
what's your ? Also what is the output of ?
works for me with this info: !
did you manually install shell integration? This issue is about automatic injection, the update in the original issue was to help users manually activate it before this was done.
Yes I did
and disabled automatic injection (set ) as you see in the screenshot. it also works for me in a subshell, so I know that i'm testing / verifying manual injection
it also works for me with automatic injection
is 3.6.0, and the shell integration path is
Looking at the code it doesn't look like we actually copy a file to :
hm, the path does appear to exist <img width="1045" alt="image" src="https://user-"Manually executing it with results in an exit code of 1 and no output, however
yeah I think what happened was I already had the injection config in my fish file when I tested automatic injection - likely from testing manual injection at one pt
Argh, I had removed the manual integration but still have other FinalTerm-compatible shell integration and probably thought this was working because of that On 26. Jan 2023, at 18:19, Megan Rogge yeah I think what happened was I already had the injection config in my fish file when I tested automatic injection - likely from testing manual injection at one pt —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID:
To verify make sure you don't manually activate shell integration in your , then check with and without and make sure shell integration works and doesn't work respectively.
When I open a terminal in the fish shell and run some commands, then run "Run recent command", the commands in the fish terminal don't show up, I assume that means it's not working for me
works for me: <img width="741" alt="Screenshot 2023-05-30 at 2 43 13 pm" src=""Do you see the grey/blue/red dot?
No, I guess shell integration is not enabled in the fish profile, I'm not sure how to troubleshoot that.
Is there supposed to be automatic integration in stable VSCode now? It doesn't seem to be working for me, but manual integration still does. Open and make sure it contains the manual integration code:
he's trying to test the newly fixed automatic injection in Insiders
can you run ? Also enabling trace logs and getting the pty host log when launching would be helpful (be mindful of any sensitive environment variables)
Here's my pty host log which includes
this isn't working for me after I removed my !
what do you mean by removed your XDGDATADIRS? weird, it's there so it should be run afaik. any idea what could be going wrong here wrt the XDGDATADIR auto activation?
I think I had manually enabled fish shell integration which is why it was working. In order to undo that, to test automatic injection, I removed that directory. Then it didn't work
IE my expectation was after undoing manual injection, it would work automatically. That wasn't the case.
I had misunderstood how this injection works because it is different from that of and . Deleting my in the comment above was the reason I saw it not working. I now see it working. !
since it's working for and I we'll close this and include it in the release notes. It would be good to get to the bottom of your issue, we can track that in another issue? We can have a call to investigate when you're free if that works.
Sure, call any time
Not really, sorry. Maybe the snap packaging interferes somehow? From your shell session, are and present?
We investigated, it ended up being the fish version being too old. After the update it worked great! Thanks for all the help
This isn't working for me in 1.79.0 (non-insider), as far as I can see the fish config is there but XDGDATADIRS isn't getting set. And looking at the code I found -- what happened?
we had to disable it because it was printing an error when starting up for someone on the team: For some reason was undefined at the time, it got set later, after our applied.
Looking at again I believe this would happen when something we need, like , is configured in either or in a file with a basename that's sorted before the one we expose. The file is intentionally read last so people can override vendor configuration, so since we need to run after user configuration maybe providing vendor configuration is just not the way to go here… sorry Maybe instead we could invoke fish with ? That would ensure the integration happens after any configuration but before* interactive input. If I have the spoons and noone beats me to it I'll try to whip up a PR for that next week.
One way to make sure something runs after the user's but before interactive input is to put the necessary code in a self-erasing function tied to the , e.g.: This can be placed in the appropriate vendor-config directory as simply (e.g.) with no need to worry about sorting order. The function will be defined during startup, executed just before printing the first prompt, then immediately undefined so it doesn't run twice.
I tried something like that thanks to your suggestion. It's not working atm and not sure why... lmk if you see what could be wrong here
I think you also need to add to this function:
Removing verification-needed as this was covered by a test plan item.


<!-- 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. --Hi! I want to solve this issue as a good-first-issue. Please help me if you can :) In Github there was a problem that README and issues don't work for RTL languages. () Then on November 16, 2021, Github announced that we fixed this problem: () But vscode does not support it yet. For example we see ) in github like this: ! But in vscode, we see the markdown preview like this: ! Feature or improvement request: Providing support for correctly previewing RTL languages texts.
Hi! Can you help me to solve this issue? (as a good-first-issue) I opened a pull request here:
/verified


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


Issue Type: <bBug</bthe Extensions tab enough text in the search box to cause scrolling back to the beginning of the search box Actual: The typed text overflows the right edge of the search box Expected: the typed text doesn't overflow the edge of the search box <img width="210" alt="Screenshot 2022-01-09 at 18 00 24" src="https://user-"VS Code version: Code 1.63.2 (, 2021-12-15T09:38:17.605Z) OS version: Darwin arm64 20.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<!-- generated by issue reporter --


The 'Last updated' and 'released on' dates on the extension page use the American format. This is confusing to many people. ! I tried to Spanish and German, but the problem remains: ! ! Consider using a unambiguous date format such as yyyy-mm-dd (ISO 8601)
I am not locating the datetime as a resource for localization, I'm assuming it is concatenated in runtime so not a loc issue. Please help if I'm mistaken.
I think using the unambiguous date format is a good way forward. However, we could do something where en-US is displayed one way everything else is displayed the other way... but I don't think that is 100% accurate.
is this issue closed? or still needs help?
Its still open and there is a PR which has to be reviewed.
Hello, is this issue still open? I am new to contributing to GitHub projects and this seems like a good first issue for me. Is there a way to claim this issue? If I am able to work on this, do you have any advice for me in contributing for the first time?
Thanks for your interest. This is already being worked on. Please look for another good first and help wanted issues. Thanks/


<img width="600" src="https://user-"<img width="600" src="https://user-"<img width="600" src="https://user-"<img width="600" src="https://user-"IMO the labels should be consistent and we should use the icon + label as much as possible: !
I like your idea of showing the icon + label. But would like to show it next to the version as they are coupled. Also showing an addition line for a pre-release extension in the hover seems redundant to me. So, I just icon to the existing label and this is how it looks: ! !


Testing On macOS Ensure the setting is not modified (default to ) Create two folders and , create file in Drag it to Undo There isn't any prompt of warning
Renaming a file and undo doesn't warn either.
These are not destructive operations, correct? The original expectation was that all destructive operations would prompt, do you think that any operations at all should prompt?
The way I interpreter is it will warn is it prompts and tells you what's going to happen when you undo/redo as the undo/redo is focus based and it's likely to mis-trigger. I don't necessarily want to disable this feature (as it's convinient) but I want to be aware of what's going to change. Undo the dnd is one of them as I might miss where the file will be moved into (especially when I'm traversing in the undo stack).
Changed the config around to better stratify this:


<img width="452" alt="Screen Shot 2022-01-27 at 11 21 24 am" src="https://user-"


<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/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.64.2 OS Version: Windows 10 Steps to Reproduce: a git repo in root of a drive (network share in my case) a change of a file to Source control a see file diff version is shown as empty command line shows diffs properly when git repo is located in some subfolder git diff works in VSCode properly
VS Code Version: 1.67.2 OS Version: Windows 10 () I am also receiving this error, and I have pinpointed it in the Git Output, hopefully, it helps the path is missing the first character in the path for a specific file on the 'git show --textconv' lines 'ub-folder' vs 'sub-folder' If the command is run manually, with the correct path there are no issues Working (Non-root folder) [2022-06-01T06:49:42.910Z] git ls-tree -l HEAD -- fserverc$gitsharesub-folderMapper [229ms] [2022-06-01T06:49:42.991Z] git show --textconv HEAD:sub- [318ms] Not Working (Root folder) [2022-06-01T06:51:54.868Z] git ls-tree -l HEAD -- fservergitsharesub-folderMapper [226ms] [2022-06-01T06:51:54.897Z] git show --textconv HEAD:ub- [262ms]
The issue is in the file The following Line needs to be changed to As the current process is removing a specific length, when sometimes the variable for 'to' can contain a single slash or double slash (which the + 1 would handle the double slash) I recommend using the regex to effectively trim any leading slashes rather than a calculated length. I have a working file here I can provide further details if required as well.
thank you very much for looking into this. I have looked at this today and while adopting a regex to remove the characters from the resulting path will work, I think that there is something else happening here that I would like to understand before making a fix. Debugging the issue I have noticed that when you open a folder from the root as described in this issue, the value of the parameter contains a trailing . This is why adding +1 to it, will actually remove an unwanted character. I will investigate this further and will get a fix in this week.
Quick update on this issue. While the method can be improved, the root cause of the problem here is that returns a path that has a trailing character. This then results in the repository root being incorrect which can result in unexpected behaviour, diff editor not working being one example. This method already has code to handle mapped drives but it does not seem to handle this particular scenario. As we are in the process of shutting down for the next Stable release, I will be looking at fixing this issue sometimes next week. I will update the issue when the fix will be released in Insiders. Thanks for your patience.
I believe I have tracked down the root cause of the issue to the call: Running the following tests clearly illustrate the problem. Notice that the second call contains a trailing . This particular behavior seems to be by design based on an old issue that I have found - One option that I have considered was to remove the trailing slash from the repository root but that does not seem to be a good option as there are Windows path that are only valid if they contain a trailing slash (ex: ). I am more inclined to tweak the implementation of to always use as that seems to be able to correctly handle directory paths with the trailing . what are your thoughts? Thanks!
Hi, I'm also having this issue, even on the insiders build. I disabled all installed extensions. Expected Git Output: Actual Git Output: The drive in question is a mapped network drive. Whenever I try to view the file diff, the previous file is blank. This problem applies to all files on the network drive, even ones in subdirectories. Let me know if there's any other information I should provide.
I have file to track the problem that you have reported.
<!-- 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!
Yes
I'll mark this issue as verified as part of . Please file a new issue if the bug continues to occur on the latest Stable and/or Insiders versions of VS Code.