Question:
<!-- 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

export const allApiProposals = Object.freeze({ authSession: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.authSession.d.ts', codiconDecoration: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.codiconDecoration.d.ts', <del> commentsResolvedState: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.commentsResolvedState.d.ts', </del> contribCommentEditorActionsMenu: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentEditorActionsMenu.d.ts', contribCommentPeekContext: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentPeekContext.d.ts', contribCommentThreadAdditionalMenu: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentThreadAdditionalMenu.d.ts',


Question:
<!-- 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

} /** <ins> * The state of a comment thread. */ export enum CommentThreadState { Unresolved = 0, Resolved = 1 } /** </ins> * A collection of {@link Comment comments} representing a conversation at a particular range in a document. */ export interface CommentThread {


Question:
<!-- 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

label?: string; /** <ins> * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; /** </ins> * Dispose this comment thread. * * Once disposed, this comment thread will be removed from visible editors and Comment Panel when appropriate.


Question:
<!-- 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

<del> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ declare module 'vscode' { // https://github.com/microsoft/vscode/issues/127473 /** * The state of a comment thread. */ export enum CommentThreadState { Unresolved = 0, Resolved = 1 } export interface CommentThread { /** * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; } } </del>


Question:
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? !
!

} else { this._onDidChangeViewWelcomeState.fire(); } <del> if (!this._terminalService.activeInstance?.shellLaunchConfig.extHostTerminalId) { // showPanel is already called with !preserveFocus // when extension host terminals are created this._terminalGroupService.showPanel(true); } </del> <ins> // we don't know here whether or not it should be focused, so // defer focusing the panel to the focus() call // to prevent overriding preserveFocus for extensions this._terminalGroupService.showPanel(false); </ins> if (hadTerminals) { this._terminalGroupService.activeGroup?.setVisible(visible); }


Question:
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? !
!

// Only focus the terminal if the activeElement has not changed since focus() was called // TODO hack if (document.activeElement === activeElement) { <del> this._focus(); </del> <ins> this._terminalGroupService.showPanel(true); </ins> } })); return; } <del> this._focus(); } private _focus() { this._terminalService.activeInstance?.focusWhenReady(); </del> <ins> this._terminalGroupService.showPanel(true); </ins> } override shouldShowWelcome(): boolean {


Question:
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 .

globalStorageHome: URI; workspaceStorageHome: URI; useHostProxy?: boolean; <ins> skipWorkspaceStorageLock?: boolean; </ins> } export interface IStaticWorkspaceData {


Question:
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 .

return workspaceStorageURI; } <ins> if (this._environment.skipWorkspaceStorageLock) { this._logService.info(`Skipping acquiring lock for ${workspaceStorageURI.fsPath}.`); return workspaceStorageURI; } </ins> const workspaceStorageBase = workspaceStorageURI.fsPath; let attempt = 0; do {


Question:
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 .

} // Run Extension Host as fork of current process <del> this._extensionHostProcess = fork(FileAccess.asFileUri('bootstrap-fork', require).fsPath, ['--type=extensionHost'], opts); </del> <ins> this._extensionHostProcess = fork(FileAccess.asFileUri('bootstrap-fork', require).fsPath, ['--type=extensionHost', '--skipWorkspaceStorageLock'], opts); </ins> // Catch all output coming from the extension host process type Output = { data: string, format: string[] };


Question:
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 .

import { realpath } from 'vs/base/node/extpath'; import { IHostUtils } from 'vs/workbench/api/common/extHostExtensionService'; import { RunOnceScheduler } from 'vs/base/common/async'; <ins> import { boolean } from 'vs/editor/common/config/editorOptions'; </ins> import 'vs/workbench/api/common/extHost.common.services'; import 'vs/workbench/api/node/extHost.node.services'; interface ParsedExtHostArgs { uriTransformerPath?: string; <ins> skipWorkspaceStorageLock?: boolean; </ins> useHostProxy?: string; }


Question:
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 .

string: [ 'uriTransformerPath', 'useHostProxy' <ins> ], boolean: [ 'skipWorkspaceStorageLock' </ins> ] }) as ParsedExtHostArgs;


Question:
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 .

// setup things patchProcess(!!initData.environment.extensionTestsLocationURI); // to support other test frameworks like Jasmin that use process.exit (https://github.com/microsoft/vscode/issues/37708) initData.environment.useHostProxy = args.useHostProxy !== undefined ? args.useHostProxy !== 'false' : undefined; <ins> initData.environment.skipWorkspaceStorageLock = boolean(args.skipWorkspaceStorageLock, false); </ins> // host abstraction const hostUtils = new class NodeHost implements IHostUtils {


Question: <!-- 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)

const editorInput = InteractiveEditorInput.create(accessor.get(IInstantiationService), notebookUri, inputUri); historyService.clearHistory(notebookUri); <del> await editorService.openEditor(editorInput, editorOptions, group); </del> <ins> await editorService.openEditor(editorInput, { ...editorOptions, pinned: true }, group); </ins> // Extensions must retain references to these URIs to manipulate the interactive editor return { notebookUri, inputUri }; }


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

if (args.verbose) { fancyLog(`${ansiColors.magenta('BuiltIn extensions')}: ${dedupedBuiltInExtensions.map(e => path.basename(e.extensionPath)).join(', ')}`); <del> fancyLog(`${ansiColors.magenta('Additional extensions')}: ${additionalBuiltinExtensions.map(e => path.basename(e.extensionLocation.path)).join(', ') || 'None'}`); </del> <ins> fancyLog(`${ansiColors.magenta('Additional extensions')}: ${additionalBuiltinExtensions.map(e => path.basename(e.path)).join(', ') || 'None'}`); </ins> } const secondaryHost = (


Question:
<!-- 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

import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { XtermLinkMatcherHandler } from 'vs/workbench/contrib/terminal/browser/links/terminalLinkManager'; import { TerminalBaseLinkProvider } from 'vs/workbench/contrib/terminal/browser/links/terminalBaseLinkProvider'; <del> import { normalize } from 'vs/base/common/path'; </del> <ins> import { normalize, isAbsolute } from 'vs/base/common/path'; </ins> import { convertLinkRangeToBuffer, getXtermLineContent } from 'vs/workbench/contrib/terminal/browser/links/terminalLinkHelpers'; import { isWindows } from 'vs/base/common/platform'; <ins> import { IFileService } from 'vs/platform/files/common/files'; import { URI } from 'vs/base/common/uri'; import { Schemas } from 'vs/base/common/network'; import { IWorkbenchEnvironmentService } from 'vs/workbench/services/environment/common/environmentService'; </ins> const MAX_LENGTH = 2000;


Question:
<!-- 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

@IQuickInputService private readonly _quickInputService: IQuickInputService, @IWorkspaceContextService private readonly _workspaceContextService: IWorkspaceContextService, @ISearchService private readonly _searchService: ISearchService, <del> @IEditorService private readonly _editorService: IEditorService </del> <ins> @IEditorService private readonly _editorService: IEditorService, @IFileService private readonly _fileService: IFileService, @IWorkbenchEnvironmentService private readonly _environmentService: IWorkbenchEnvironmentService </ins> ) { super(); }


Question:
<!-- 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

} private async _activate(link: string) { <del> // Normalize the link and remove any leading ./ or ../ since quick access doesn't understand // that format </del> <ins> // Remove file:/// and any leading ./ or ../ since quick access doesn't understand that format link = link.replace(/^file:///?/, ''); </ins> link = normalize(link).replace(/^(.+[/])+/, ''); // Remove `:in` from the end which is how Ruby outputs stack traces


Question:
<!-- 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

}); const sanitizedLink = link.replace(/:d+(:d+)?$/, ''); <del> const results = await this._searchService.fileSearch( this._fileQueryBuilder.file(this._workspaceContextService.getWorkspace().folders, { // Remove optional :row:col from the link as openEditor supports it filePattern: sanitizedLink, maxResults: 2 }) ); // If there was exactly one match, open it if (results.results.length === 1) { </del> <ins> let exactMatch = await this._getExactMatch(sanitizedLink, link); if (exactMatch) { // If there was exactly one match, open it </ins> const match = link.match(/:(d+)?(:(d+))?$/); const startLineNumber = match?.[1]; const startColumn = match?.[3]; await this._editorService.openEditor({ <del> resource: results.results[0].resource, </del> <ins> resource: exactMatch, </ins> options: { pinned: true, revealIfOpened: true,


Question:
<!-- 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

}); return; } // Fallback to searching quick access <del> this._quickInputService.quickAccess.show(link); </del> <ins> return this._quickInputService.quickAccess.show(link); } private async _getExactMatch(sanitizedLink: string, link: string): Promise<URI | undefined> { let exactResource: URI | undefined; if (isAbsolute(sanitizedLink)) { const scheme = this._environmentService.remoteAuthority ? Schemas.vscodeRemote : Schemas.file; const resource = URI.from({ scheme, path: sanitizedLink }); const fileStat = await this._fileService.resolve(resource); if (fileStat.isFile) { exactResource = resource; } } if (!exactResource) { const results = await this._searchService.fileSearch( this._fileQueryBuilder.file(this._workspaceContextService.getWorkspace().folders, { // Remove optional :row:col from the link as openEditor supports it filePattern: sanitizedLink, maxResults: 2 }) ); if (results.results.length === 1) { exactResource = results.results[0].resource; } } return exactResource; </ins> } }


Question:
<!-- 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

await configurationService.setUserConfiguration('terminal', { integrated: { wordSeparators: ' ' } }); await assertLink('', []); }); <ins> test('should support file scheme links', async () => { await configurationService.setUserConfiguration('terminal', { integrated: { wordSeparators: ' ' } }); await assertLink('file:///C:/users/test/file.txt ', [{ range: [[1, 1], [30, 1]], text: 'file:///C:/users/test/file.txt' }]); await assertLink('file:///C:/users/test/file.txt:1:10 ', [{ range: [[1, 1], [35, 1]], text: 'file:///C:/users/test/file.txt:1:10' }]); }); </ins> });


Question:
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.

} if (e.element instanceof InstructionBreakpoint) { const disassemblyView = await this.editorService.openEditor(DisassemblyViewInput.instance); <del> (disassemblyView as DisassemblyView).goToAddress(e.element.instructionReference); </del> <ins> // Focus on double click (disassemblyView as DisassemblyView).goToAddress(e.element.instructionReference, e.browserEvent instanceof MouseEvent && e.browserEvent.detail === 2); </ins> } if (e.browserEvent instanceof MouseEvent && e.browserEvent.detail === 2 && e.element instanceof FunctionBreakpoint && e.element !== this.inputBoxData?.breakpoint) { // double click


Question:
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.

multipleSelectionSupport: false, setRowLineHeight: false, openOnSingleClick: false, <del> accessibilityProvider: new AccessibilityProvider() </del> <ins> accessibilityProvider: new AccessibilityProvider(), mouseSupport: false </ins> } )) as WorkbenchTable<IDisassembledInstructionEntry>;


Question:
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.

/** * Go to the address provided. If no address is provided, reveal the address of the currently focused stack frame. */ <del> goToAddress(address?: string): void { </del> <ins> goToAddress(address?: string, focus?: boolean): void { </ins> if (!this._disassembledInstructions) { return; }


Question:
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.

const bottomElement = Math.floor((this._disassembledInstructions.scrollTop + this._disassembledInstructions.renderHeight) / this.fontInfo.lineHeight); if (index > topElement && index < bottomElement) { // Inside the viewport, don't do anything here <del> return; </del> } else if (index <= topElement && index > topElement - 5) { // Not too far from top, review it at the top <del> return this._disassembledInstructions.reveal(index, 0); </del> <ins> this._disassembledInstructions.reveal(index, 0); </ins> } else if (index >= bottomElement && index < bottomElement + 5) { // Not too far from bottom, review it at the bottom <del> return this._disassembledInstructions.reveal(index, 1); </del> <ins> this._disassembledInstructions.reveal(index, 1); </ins> } else { // Far from the current viewport, reveal it <del> return this._disassembledInstructions.reveal(index, 0.5); </del> <ins> this._disassembledInstructions.reveal(index, 0.5); } if (focus) { this._disassembledInstructions.domFocus(); this._disassembledInstructions.setFocus([index]); </ins> } } else if (this._debugService.state === State.Stopped) { // Address is not provided or not in the table currently, clear the table // and reload if we are in the state where we can load disassembly. <del> return this.reloadDisassembly(address); </del> <ins> this.reloadDisassembly(address); </ins> } }


Question:
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.

this.loadDisassembledInstructions(targetAddress, -DisassemblyView.NUM_INSTRUCTIONS_TO_LOAD, DisassemblyView.NUM_INSTRUCTIONS_TO_LOAD * 2).then(() => { // on load, set the target instruction in the middle of the page. if (this._disassembledInstructions!.length > 0) { <del> this._disassembledInstructions!.reveal(Math.floor(this._disassembledInstructions!.length / 2), 0.5); </del> <ins> const targetIndex = Math.floor(this._disassembledInstructions!.length / 2); this._disassembledInstructions!.reveal(targetIndex, 0.5); // Always focus the target address on reload, or arrow key navigation would look terrible this._disassembledInstructions!.domFocus(); this._disassembledInstructions!.setFocus([targetIndex]); </ins> } }); }


Question:
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.

// Without formatting we still need to support the separator // as provided in options (https://github.com/microsoft/vscode/issues/130019) if (!formatting && options.separator) { <del> switch (options.separator) { case paths.win32.sep: return paths.win32.normalize(label); case paths.posix.sep: return paths.posix.normalize(label); } </del> <ins> return label.replace(sepRegexp, options.separator); </ins> } return label;


Question:
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.

assert.strictEqual(generated, label); }); }); <ins> test('relative label with explicit path separator', () => { let generated = labelService.getUriLabel(URI.parse('myscheme://myauthority/some/folder/test.txt'), { relative: true, separator: '/' }); assert.strictEqual(generated, 'some/folder/test.txt'); generated = labelService.getUriLabel(URI.parse('myscheme://myauthority/some/folder/test.txt'), { relative: true, separator: '' }); assert.strictEqual(generated, 'somefoldertest.txt'); }); </ins> });


Question:
! //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-"

} .monaco-editor .find-widget .button { <del> width: 20px; height: 20px; </del> <ins> width: 16px; height: 16px; padding: 3px; border-radius: 5px; </ins> display: flex; flex: initial; margin-left: 3px;


Question:
! //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-"

justify-content: center; } <ins> /* find in selection button */ .monaco-editor .find-widget .codicon-find-selection { width: 22px; height: 22px; padding: 3px; border-radius: 5px; } </ins> .monaco-editor .find-widget .button.left { margin-left: 0; margin-right: 3px;


Question:
! //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-"

import { FindReplaceState, FindReplaceStateChangedEvent } from 'vs/editor/contrib/find/findState'; import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { IKeybindingService } from 'vs/platform/keybinding/common/keybinding'; <del> import { contrastBorder, editorFindMatch, editorFindMatchBorder, editorFindMatchHighlight, editorFindMatchHighlightBorder, editorFindRangeHighlight, editorFindRangeHighlightBorder, editorWidgetBackground, editorWidgetBorder, editorWidgetResizeBorder, errorForeground, inputActiveOptionBorder, inputActiveOptionBackground, inputActiveOptionForeground, inputBackground, inputBorder, inputForeground, inputValidationErrorBackground, inputValidationErrorBorder, inputValidationErrorForeground, inputValidationInfoBackground, inputValidationInfoBorder, inputValidationInfoForeground, inputValidationWarningBackground, inputValidationWarningBorder, inputValidationWarningForeground, widgetShadow, editorWidgetForeground, focusBorder } from 'vs/platform/theme/common/colorRegistry'; </del> <ins> import { contrastBorder, editorFindMatch, editorFindMatchBorder, editorFindMatchHighlight, editorFindMatchHighlightBorder, editorFindRangeHighlight, editorFindRangeHighlightBorder, editorWidgetBackground, editorWidgetBorder, editorWidgetResizeBorder, errorForeground, inputActiveOptionBorder, inputActiveOptionBackground, inputActiveOptionForeground, inputBackground, inputBorder, inputForeground, inputValidationErrorBackground, inputValidationErrorBorder, inputValidationErrorForeground, inputValidationInfoBackground, inputValidationInfoBorder, inputValidationInfoForeground, inputValidationWarningBackground, inputValidationWarningBorder, inputValidationWarningForeground, widgetShadow, editorWidgetForeground, focusBorder, toolbarHoverBackground } from 'vs/platform/theme/common/colorRegistry'; </ins> import { IColorTheme, IThemeService, registerThemingParticipant, ThemeIcon } from 'vs/platform/theme/common/themeService'; import { ContextScopedFindInput, ContextScopedReplaceInput } from 'vs/platform/browser/contextScopedHistoryWidget'; import { AccessibilitySupport } from 'vs/platform/accessibility/common/accessibility';


Question:
! //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-"

} } <ins> // Action bars const toolbarHoverBackgroundColor = theme.getColor(toolbarHoverBackground); if (toolbarHoverBackgroundColor) { collector.addRule(` .monaco-editor .find-widget .button:not(.disabled):hover, .monaco-editor .find-widget .codicon-find-selection:hover { background-color: ${toolbarHoverBackgroundColor} !important; } `); } </ins> // This rule is used to override the outline color for synthetic-focus find input. const focusOutline = theme.getColor(focusBorder); if (focusOutline) {


Question:
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?

const media = stepToExpand.media; const mediaElement = $<HTMLImageElement>('img'); <ins> clearNode(this.stepMediaComponent); </ins> this.stepMediaComponent.appendChild(mediaElement); mediaElement.setAttribute('alt', media.altText); this.updateMediaSourceForColorMode(mediaElement, media.path);


Question:
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?

this.container.classList.toggle('height-constrained', size.height <= 600); this.container.classList.toggle('width-constrained', size.width <= 400); this.container.classList.toggle('width-semi-constrained', size.width <= 800); <ins> this.categoriesPageScrollbar?.scanDomNode(); this.detailsPageScrollbar?.scanDomNode(); this.detailsScrollbar?.scanDomNode(); </ins> } private updateCategoryProgress() {