Question:
! Only seems to appear if I resize the terminal such that a is on its own line.
Cannot repro: !
I can still reproduce this? For example cat this file to your terminal Then drag until a quote is the only thing on one of the lines. This causes the link detection to detect everything below that quote.
Couldn't repro on Windows but I do see some offset problem after the resizes: ! Probably an issue with reflow (mac/Linux)
In tried on my mac and I still can't reproduce: !
Still able to reproduce this, have passed repo steps regarding the private repo offline.
Still struggling to repro, I did notice sometimes it's off by 1 or 2 cells in either direction like this though: <img width="852" alt="Screenshot 2022-12-22 at 5 08 03 pm" src="https://user-"
This happens because of line caching, hovering a wrapped line and then resizing it a little such that the line is still there, the line range will be off: <img width="866" alt="Screenshot 2022-12-22 at 5 12 44 pm" src="https://user-"
That one repro's upstream: <img width="793" alt="Screenshot 2022-12-27 at 6 24 10 am" src="https://user-"Since I can't repro your actual issue I'll fix this and see if that's the underlying issue.
Can still repro this building OSS. Note you do not need to resize the terminal for this to occur if it's already the correct size when you run the task.
Update cannot repro when debugging. So odd
Update again, I can repro this again in insiders. Not sure why debugging is different.
Still can't reproduce so closing as unactionable until there's a solid repro. Insiders: <img width="632" alt="Screenshot 2023-05-08 at 6 43 07 am" src="https://user-"OSS: <img width="637" alt="Screenshot 2023-05-08 at 6 44 55 am" src="https://user-"OSS debugging: <img width="633" alt="Screenshot 2023-05-08 at 6 46 16 am" src="https://user-"cat this file:

resolved "https://registry.yarnpkg.com/wrappy/-/wrappy-1.0.2.tgz#b5243d8f3ec1aa35f1364605bc0d1036e30ab69f" integrity sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8= <del> xterm-addon-canvas@0.4.0-beta.1: version "0.4.0-beta.1" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.4.0-beta.1.tgz#f2742b88cd3eb1840b9e7f986c4bfe31e0f4684f" integrity sha512-EfjaN0ujHJ4D8CsVpBig3xPvfRhbzAyOh8piAbNpePZmTpBzc2OQQQvEeklPriKVNDv28WbmY0Zzl5tgYM7vwg== </del> <ins> xterm-addon-canvas@0.4.0-beta.6: version "0.4.0-beta.6" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.4.0-beta.6.tgz#f8cb09ef980f1fa9d73f067e00f7a879c374ad68" integrity sha512-x5OY0VOJxqvXdyXpW9aug3vaeQX/+r7TZk13MujReuJRLRAjCHaH6ep6g9ZOVlqa8VCBWPwmm/eXH05SGUbnQQ== </ins> <del> xterm-addon-search@0.11.0-beta.7: version "0.11.0-beta.7" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.11.0-beta.7.tgz#d90bcbe9e8f9238c18ba6145bd7ec2f8e3240052" integrity sha512-i/c774V0/Eon3BIFRsRR3OjKTnMGkccBo12yDkOa40tnAD4aa8FjspE3bxW/Hh1mUEhCSgBSLnMDlK/GwnUC+g== </del> <ins> xterm-addon-search@0.11.0: version "0.11.0" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.11.0.tgz#2a00ff7f9848f6140e7c4d1782486b0b18b06e0d" integrity sha512-6U4uHXcQ7G5igsdaGqrJ9ehm7vep24bXqWxuy3AnIosXF2Z5uy2MvmYRyTGNembIqPV/x1YhBQ7uShtuqBHhOQ== </ins> xterm-addon-serialize@0.9.0: version "0.9.0" resolved "https://registry.yarnpkg.com/xterm-addon-serialize/-/xterm-addon-serialize-0.9.0.tgz#3eee5f5c34b16e48891ec59b213716bab2354bf4" integrity sha512-qJju2YJFh8c8pbtCYtHaG7gDDHBpDJ4a4JQZvOzuiMxOjgeM1oCnFNjbhzMuK/fOUa59FmvIUGQyqn3WL9q7qw== <del> xterm-addon-unicode11@0.5.0-beta.5: version "0.5.0-beta.5" resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.5.0-beta.5.tgz#6992a6f56349e67b903201d52b1ad41ba3469d93" integrity sha512-MaqnU34WTHCUAo7moB4KhynGn03RckI0JJ8E/gXe96EzuCP6bVJIKSc5pc9iFeLF4BX1SuemOqIHYl2Q3u3NTA== xterm-addon-webgl@0.15.0-beta.1: version "0.15.0-beta.1" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.15.0-beta.1.tgz#bc3f784c3c467a70542b8a9a8998dbe996287796" integrity sha512-8f4cNXG0+dBMqp+Nvk/ZQ8Wo8s4/KbF24b2VTHTt8DuY5QXt4wSA6+NEdnABV98VYDoHl+KfXl9yyFqkcJYr8Q== xterm-headless@5.2.0-beta.2: version "5.2.0-beta.2" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-5.2.0-beta.2.tgz#db8d4cc45a2bba062622d7784a2264030aa7d56d" integrity sha512-aP3+K47bJu5AkdtekML5LZZUh/zAkDc5ONNFgQ+7eUBh7RkFy3JYRuaG5Nj3LbdkUMjWqQZXzc3BW5Vo9KQNgA== xterm@5.2.0-beta.2: version "5.2.0-beta.2" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.2.0-beta.2.tgz#67369235a54f41179922e662df40ff4c7c974787" integrity sha512-MRAdWRfV80ae0Q3Caq/mfmCwnZZZ89Z8i/sAleio5g5dpsst9IXc0zeFpPnOvUWmtVy5P1LbfU9YCy47449DWw== </del> <ins> xterm-addon-unicode11@0.5.0: version "0.5.0" resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.5.0.tgz#41c0d96acc1e3bb6c6596eee64e163b6bca74be7" integrity sha512-Jm4/g4QiTxiKiTbYICQgC791ubhIZyoIwxAIgOW8z8HWFNY+lwk+dwaKEaEeGBfM48Vk8fklsUW9u/PlenYEBg== xterm-addon-webgl@0.15.0-beta.4: version "0.15.0-beta.4" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.15.0-beta.4.tgz#d03a98e446372a5dbb7d92075d1f125eec23b030" integrity sha512-W9N0+5i3trQhgBOHDsnNiBbBiJpleFenY668wWaZ9GlvWseCTnjnWis1kfnM9WASDh/0+7aOjWrD089o+QeHGQ== xterm-headless@5.2.0-beta.10: version "5.2.0-beta.10" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-5.2.0-beta.10.tgz#fc7b11b0395f6bb934b0c9373b412bc4d3247148" integrity sha512-jjylqERzLWWrPLpehL1v0Y3JaZqQksoqE04g5H+tNceQemoBlIpbA5OgPrbcjz5xxFIR9mVWppFR7klWox5/Sg== xterm@5.2.0-beta.10: version "5.2.0-beta.10" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.2.0-beta.10.tgz#33e67a8397937dd8b731a2f315c67f4bd63f3c28" integrity sha512-3zVxU/0XrUWpvOIU/KkXREweq7hCxNGFt4asT4D/SsRlRKYOnO+vooz1CjLO6USY++iHXicgf8PdgRDeYj5fFQ== </ins> yallist@^4.0.0: version "4.0.0"


Question:
! Only seems to appear if I resize the terminal such that a is on its own line.
Cannot repro: !
I can still reproduce this? For example cat this file to your terminal Then drag until a quote is the only thing on one of the lines. This causes the link detection to detect everything below that quote.
Couldn't repro on Windows but I do see some offset problem after the resizes: ! Probably an issue with reflow (mac/Linux)
In tried on my mac and I still can't reproduce: !
Still able to reproduce this, have passed repo steps regarding the private repo offline.
Still struggling to repro, I did notice sometimes it's off by 1 or 2 cells in either direction like this though: <img width="852" alt="Screenshot 2022-12-22 at 5 08 03 pm" src="https://user-"
This happens because of line caching, hovering a wrapped line and then resizing it a little such that the line is still there, the line range will be off: <img width="866" alt="Screenshot 2022-12-22 at 5 12 44 pm" src="https://user-"
That one repro's upstream: <img width="793" alt="Screenshot 2022-12-27 at 6 24 10 am" src="https://user-"Since I can't repro your actual issue I'll fix this and see if that's the underlying issue.
Can still repro this building OSS. Note you do not need to resize the terminal for this to occur if it's already the correct size when you run the task.
Update cannot repro when debugging. So odd
Update again, I can repro this again in insiders. Not sure why debugging is different.
Still can't reproduce so closing as unactionable until there's a solid repro. Insiders: <img width="632" alt="Screenshot 2023-05-08 at 6 43 07 am" src="https://user-"OSS: <img width="637" alt="Screenshot 2023-05-08 at 6 44 55 am" src="https://user-"OSS debugging: <img width="633" alt="Screenshot 2023-05-08 at 6 46 16 am" src="https://user-"cat this file:

dependencies: object-keys "~0.4.0" <del> xterm-addon-canvas@0.4.0-beta.1: version "0.4.0-beta.1" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.4.0-beta.1.tgz#f2742b88cd3eb1840b9e7f986c4bfe31e0f4684f" integrity sha512-EfjaN0ujHJ4D8CsVpBig3xPvfRhbzAyOh8piAbNpePZmTpBzc2OQQQvEeklPriKVNDv28WbmY0Zzl5tgYM7vwg== </del> <ins> xterm-addon-canvas@0.4.0-beta.6: version "0.4.0-beta.6" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.4.0-beta.6.tgz#f8cb09ef980f1fa9d73f067e00f7a879c374ad68" integrity sha512-x5OY0VOJxqvXdyXpW9aug3vaeQX/+r7TZk13MujReuJRLRAjCHaH6ep6g9ZOVlqa8VCBWPwmm/eXH05SGUbnQQ== </ins> <del> xterm-addon-search@0.11.0-beta.7: version "0.11.0-beta.7" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.11.0-beta.7.tgz#d90bcbe9e8f9238c18ba6145bd7ec2f8e3240052" integrity sha512-i/c774V0/Eon3BIFRsRR3OjKTnMGkccBo12yDkOa40tnAD4aa8FjspE3bxW/Hh1mUEhCSgBSLnMDlK/GwnUC+g== </del> <ins> xterm-addon-search@0.11.0: version "0.11.0" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.11.0.tgz#2a00ff7f9848f6140e7c4d1782486b0b18b06e0d" integrity sha512-6U4uHXcQ7G5igsdaGqrJ9ehm7vep24bXqWxuy3AnIosXF2Z5uy2MvmYRyTGNembIqPV/x1YhBQ7uShtuqBHhOQ== </ins> xterm-addon-serialize@0.9.0: version "0.9.0" resolved "https://registry.yarnpkg.com/xterm-addon-serialize/-/xterm-addon-serialize-0.9.0.tgz#3eee5f5c34b16e48891ec59b213716bab2354bf4" integrity sha512-qJju2YJFh8c8pbtCYtHaG7gDDHBpDJ4a4JQZvOzuiMxOjgeM1oCnFNjbhzMuK/fOUa59FmvIUGQyqn3WL9q7qw== <del> xterm-addon-unicode11@0.5.0-beta.5: version "0.5.0-beta.5" resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.5.0-beta.5.tgz#6992a6f56349e67b903201d52b1ad41ba3469d93" integrity sha512-MaqnU34WTHCUAo7moB4KhynGn03RckI0JJ8E/gXe96EzuCP6bVJIKSc5pc9iFeLF4BX1SuemOqIHYl2Q3u3NTA== xterm-addon-webgl@0.15.0-beta.1: version "0.15.0-beta.1" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.15.0-beta.1.tgz#bc3f784c3c467a70542b8a9a8998dbe996287796" integrity sha512-8f4cNXG0+dBMqp+Nvk/ZQ8Wo8s4/KbF24b2VTHTt8DuY5QXt4wSA6+NEdnABV98VYDoHl+KfXl9yyFqkcJYr8Q== xterm-headless@5.2.0-beta.2: version "5.2.0-beta.2" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-5.2.0-beta.2.tgz#db8d4cc45a2bba062622d7784a2264030aa7d56d" integrity sha512-aP3+K47bJu5AkdtekML5LZZUh/zAkDc5ONNFgQ+7eUBh7RkFy3JYRuaG5Nj3LbdkUMjWqQZXzc3BW5Vo9KQNgA== xterm@5.2.0-beta.2: version "5.2.0-beta.2" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.2.0-beta.2.tgz#67369235a54f41179922e662df40ff4c7c974787" integrity sha512-MRAdWRfV80ae0Q3Caq/mfmCwnZZZ89Z8i/sAleio5g5dpsst9IXc0zeFpPnOvUWmtVy5P1LbfU9YCy47449DWw== </del> <ins> xterm-addon-unicode11@0.5.0: version "0.5.0" resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.5.0.tgz#41c0d96acc1e3bb6c6596eee64e163b6bca74be7" integrity sha512-Jm4/g4QiTxiKiTbYICQgC791ubhIZyoIwxAIgOW8z8HWFNY+lwk+dwaKEaEeGBfM48Vk8fklsUW9u/PlenYEBg== xterm-addon-webgl@0.15.0-beta.4: version "0.15.0-beta.4" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.15.0-beta.4.tgz#d03a98e446372a5dbb7d92075d1f125eec23b030" integrity sha512-W9N0+5i3trQhgBOHDsnNiBbBiJpleFenY668wWaZ9GlvWseCTnjnWis1kfnM9WASDh/0+7aOjWrD089o+QeHGQ== xterm-headless@5.2.0-beta.10: version "5.2.0-beta.10" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-5.2.0-beta.10.tgz#fc7b11b0395f6bb934b0c9373b412bc4d3247148" integrity sha512-jjylqERzLWWrPLpehL1v0Y3JaZqQksoqE04g5H+tNceQemoBlIpbA5OgPrbcjz5xxFIR9mVWppFR7klWox5/Sg== xterm@5.2.0-beta.10: version "5.2.0-beta.10" resolved "https://registry.yarnpkg.com/xterm/-/xterm-5.2.0-beta.10.tgz#33e67a8397937dd8b731a2f315c67f4bd63f3c28" integrity sha512-3zVxU/0XrUWpvOIU/KkXREweq7hCxNGFt4asT4D/SsRlRKYOnO+vooz1CjLO6USY++iHXicgf8PdgRDeYj5fFQ== </ins> y18n@^3.2.1: version "3.2.2"


Question:
In the following dialog that appears: <img width="696" alt="image" src="https://user-"in and opening a protocol url, the 'Install VS Code Insiders' button should route to a new link for installing insiders specifically rather than just Install VS Code Insiders should not dismiss the dialog, so that the user can return and try again cc
likely a separate issue: Was not sure how this modal was arrived at, so I clicked the remote indicator and I only saw an option to download VS Code - not Insider's as I'd expect. !
I then did the flow and saw the dialogue. Clicking on the button took me to the Insider's download correctly. !

invokeProtocolHandler(); <del> // We cannot know whether the protocol handler succeeded. // Display guidance in case it did not, e.g. the app is not installed locally. if (matchesScheme(href, this.productService.urlProtocol)) { </del> <ins> const showProtocolUrlOpenedDialog = async () => { </ins> const showResult = await this.dialogService.show( Severity.Info, localize('openExternalDialogTitle', "All done. You can close this tab now."),


Question:
In the following dialog that appears: <img width="696" alt="image" src="https://user-"in and opening a protocol url, the 'Install VS Code Insiders' button should route to a new link for installing insiders specifically rather than just Install VS Code Insiders should not dismiss the dialog, so that the user can return and try again cc
likely a separate issue: Was not sure how this modal was arrived at, so I clicked the remote indicator and I only saw an option to download VS Code - not Insider's as I'd expect. !
I then did the flow and saw the dialogue. Clicking on the button took me to the Insider's download correctly. !

if (showResult.choice === 0) { invokeProtocolHandler(); } else if (showResult.choice === 1) { <del> await this.openerService.open(URI.parse(`http://aka.ms/vscode-install`)); </del> <ins> // Route the user to the appropriate install link await this.openerService.open(URI.parse( this.productService.quality === 'stable' ? `http://aka.ms/vscode-install` : `http://aka.ms/vscode-install-insiders` )); // Re-show the dialog so that the user can come back after installing and try again showProtocolUrlOpenedDialog(); </ins> } <ins> }; // We cannot know whether the protocol handler succeeded. // Display guidance in case it did not, e.g. the app is not installed locally. if (matchesScheme(href, this.productService.urlProtocol)) { await showProtocolUrlOpenedDialog(); </ins> } }


Question:
Type: <bBug</bVSCode, create a folder named, for instance, "XXXX". that folder create another called .vscode .vscode create a file named with this content: VSCode sure the setting "task.allowAutomaticTasks" is not set or is set to its defautl value "auto". "XXXX" with VSCode. VSCode will run "echo Hello" without asking you whether you want to run tasks configured with "runOn": "folderOpen" or not. VS Code version: Code 1.70.2 (, 2022-08-16T05:35:13.448Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This happens because you have presumably opened a trusted workspace - which is now when we allow these to be run if the setting is "auto" for allow automatic task
The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our . Happy Coding!
! If I understood it correctly, the popup that supposedly asks you whether you want to run these tasks is not actually meant to appear ever because if the workspace is trusted it will be executed without asking you and if it is not trusted then it will just not exeute them instead of asking you. Doesn't it look kinda pointless to have in the description of the option of the configuration "Prompt for permission for each folder"? You are never prompted anyways.
I this configuration and I am still not prompted anyways:
No I did not. Please next time ask the user if he did X before assuming it and closing the issue. I tried reproducing the problem with and without a trusted workspace and the problem persists anyways.
i'll investigate this that shouldn't happen
Tasks will only run in trusted workspaces, so I will update the setting description to indicate that. Also need to fix the prompt not happening per folder.

} if (runSource === TaskRunSource.User) { const workspaceTasks = await this.getWorkspaceTasks(); <del> RunAutomaticTasks.promptForPermission(this, this._storageService, this._notificationService, this._workspaceTrustManagementService, this._openerService, this._configurationService, workspaceTasks); </del> <ins> RunAutomaticTasks.runWithPermission(this, this._storageService, this._notificationService, this._workspaceTrustManagementService, this._openerService, this._configurationService, workspaceTasks); </ins> } return executeTaskResult; } catch (error) {


Question:
Type: <bBug</bVSCode, create a folder named, for instance, "XXXX". that folder create another called .vscode .vscode create a file named with this content: VSCode sure the setting "task.allowAutomaticTasks" is not set or is set to its defautl value "auto". "XXXX" with VSCode. VSCode will run "echo Hello" without asking you whether you want to run tasks configured with "runOn": "folderOpen" or not. VS Code version: Code 1.70.2 (, 2022-08-16T05:35:13.448Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This happens because you have presumably opened a trusted workspace - which is now when we allow these to be run if the setting is "auto" for allow automatic task
The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our . Happy Coding!
! If I understood it correctly, the popup that supposedly asks you whether you want to run these tasks is not actually meant to appear ever because if the workspace is trusted it will be executed without asking you and if it is not trusted then it will just not exeute them instead of asking you. Doesn't it look kinda pointless to have in the description of the option of the configuration "Prompt for permission for each folder"? You are never prompted anyways.
I this configuration and I am still not prompted anyways:
No I did not. Please next time ask the user if he did X before assuming it and closing the issue. I tried reproducing the problem with and without a trusted workspace and the problem persists anyways.
i'll investigate this that shouldn't happen
Tasks will only run in trusted workspaces, so I will update the setting description to indicate that. Also need to fix the prompt not happening per folder.

@ITaskService private readonly _taskService: ITaskService, @IConfigurationService private readonly _configurationService: IConfigurationService, @IWorkspaceTrustManagementService private readonly _workspaceTrustManagementService: IWorkspaceTrustManagementService, <del> @ILogService private readonly _logService: ILogService) { </del> <ins> @ILogService private readonly _logService: ILogService, @IStorageService private readonly _storageService: IStorageService, @IOpenerService private readonly _openerService: IOpenerService, @INotificationService private readonly _notificationService: INotificationService) { </ins> super(); this._tryRunTasks(); }


Question:
Type: <bBug</bVSCode, create a folder named, for instance, "XXXX". that folder create another called .vscode .vscode create a file named with this content: VSCode sure the setting "task.allowAutomaticTasks" is not set or is set to its defautl value "auto". "XXXX" with VSCode. VSCode will run "echo Hello" without asking you whether you want to run tasks configured with "runOn": "folderOpen" or not. VS Code version: Code 1.70.2 (, 2022-08-16T05:35:13.448Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This happens because you have presumably opened a trusted workspace - which is now when we allow these to be run if the setting is "auto" for allow automatic task
The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our . Happy Coding!
! If I understood it correctly, the popup that supposedly asks you whether you want to run these tasks is not actually meant to appear ever because if the workspace is trusted it will be executed without asking you and if it is not trusted then it will just not exeute them instead of asking you. Doesn't it look kinda pointless to have in the description of the option of the configuration "Prompt for permission for each folder"? You are never prompted anyways.
I this configuration and I am still not prompted anyways:
No I did not. Please next time ask the user if he did X before assuming it and closing the issue. I tried reproducing the problem with and without a trusted workspace and the problem persists anyways.
i'll investigate this that shouldn't happen
Tasks will only run in trusted workspaces, so I will update the setting description to indicate that. Also need to fix the prompt not happening per folder.

await Event.toPromise(Event.once(this._taskService.onDidChangeTaskSystemInfo)); } <del> this._logService.trace('RunAutomaticTasks: Checking if automatic tasks should run.'); const isFolderAutomaticAllowed = this._configurationService.getValue(ALLOW_AUTOMATIC_TASKS) !== 'off'; await this._workspaceTrustManagementService.workspaceTrustInitialized; const isWorkspaceTrusted = this._workspaceTrustManagementService.isWorkspaceTrusted(); // Only run if allowed. Prompting for permission occurs when a user first tries to run a task. if (isFolderAutomaticAllowed && isWorkspaceTrusted) { this._taskService.getWorkspaceTasks(TaskRunSource.FolderOpen).then(workspaceTaskResult => { const { tasks } = RunAutomaticTasks._findAutoTasks(this._taskService, workspaceTaskResult); this._logService.trace(`RunAutomaticTasks: Found ${tasks.length} automatic tasks tasks`); if (tasks.length > 0) { RunAutomaticTasks._runTasks(this._taskService, tasks); } }); } </del> <ins> const workspaceTasks = await this._taskService.getWorkspaceTasks(TaskRunSource.FolderOpen); this._logService.trace(`RunAutomaticTasks: Found ${workspaceTasks.size} automatic tasks`); await RunAutomaticTasks.runWithPermission(this._taskService, this._storageService, this._notificationService, this._workspaceTrustManagementService, this._openerService, this._configurationService, workspaceTasks); </ins> } private static _runTasks(taskService: ITaskService, tasks: Array<Task | Promise<Task | undefined>>) {


Question:
Type: <bBug</bVSCode, create a folder named, for instance, "XXXX". that folder create another called .vscode .vscode create a file named with this content: VSCode sure the setting "task.allowAutomaticTasks" is not set or is set to its defautl value "auto". "XXXX" with VSCode. VSCode will run "echo Hello" without asking you whether you want to run tasks configured with "runOn": "folderOpen" or not. VS Code version: Code 1.70.2 (, 2022-08-16T05:35:13.448Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This happens because you have presumably opened a trusted workspace - which is now when we allow these to be run if the setting is "auto" for allow automatic task
The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our . Happy Coding!
! If I understood it correctly, the popup that supposedly asks you whether you want to run these tasks is not actually meant to appear ever because if the workspace is trusted it will be executed without asking you and if it is not trusted then it will just not exeute them instead of asking you. Doesn't it look kinda pointless to have in the description of the option of the configuration "Prompt for permission for each folder"? You are never prompted anyways.
I this configuration and I am still not prompted anyways:
No I did not. Please next time ask the user if he did X before assuming it and closing the issue. I tried reproducing the problem with and without a trusted workspace and the problem persists anyways.
i'll investigate this that shouldn't happen
Tasks will only run in trusted workspaces, so I will update the setting description to indicate that. Also need to fix the prompt not happening per folder.

return { tasks, taskNames, locations }; } <del> public static async promptForPermission(taskService: ITaskService, storageService: IStorageService, notificationService: INotificationService, workspaceTrustManagementService: IWorkspaceTrustManagementService, </del> <ins> public static async runWithPermission(taskService: ITaskService, storageService: IStorageService, notificationService: INotificationService, workspaceTrustManagementService: IWorkspaceTrustManagementService, </ins> openerService: IOpenerService, configurationService: IConfigurationService, workspaceTaskResult: Map<string, IWorkspaceFolderTaskResult>) { const isWorkspaceTrusted = workspaceTrustManagementService.isWorkspaceTrusted; <del> if (!isWorkspaceTrusted) { </del> <ins> if (!isWorkspaceTrusted || configurationService.getValue(ALLOW_AUTOMATIC_TASKS) === 'off') { </ins> return; } <del> if (configurationService.getValue(ALLOW_AUTOMATIC_TASKS) === 'off') { </del> <ins> const hasShownPromptForAutomaticTasks = storageService.getBoolean(HAS_PROMPTED_FOR_AUTOMATIC_TASKS, StorageScope.WORKSPACE, false); const { tasks, taskNames, locations } = RunAutomaticTasks._findAutoTasks(taskService, workspaceTaskResult); if (taskNames.length === 0) { </ins> return; } <del> const hasShownPromptForAutomaticTasks = storageService.getBoolean(HAS_PROMPTED_FOR_AUTOMATIC_TASKS, StorageScope.WORKSPACE, undefined); const { tasks, taskNames, locations } = RunAutomaticTasks._findAutoTasks(taskService, workspaceTaskResult); if (taskNames.length > 0) { if (configurationService.getValue(ALLOW_AUTOMATIC_TASKS) === 'on') { RunAutomaticTasks._runTasks(taskService, tasks); } else if (!hasShownPromptForAutomaticTasks) { // We have automatic tasks, prompt to allow. this._showPrompt(notificationService, storageService, openerService, configurationService, taskNames, locations).then(allow => { if (allow) { RunAutomaticTasks._runTasks(taskService, tasks); } }); } </del> <ins> if (configurationService.getValue(ALLOW_AUTOMATIC_TASKS) === 'on') { RunAutomaticTasks._runTasks(taskService, tasks); } else if (configurationService.getValue(ALLOW_AUTOMATIC_TASKS) === 'auto' && !hasShownPromptForAutomaticTasks) { // by default, only prompt once per folder // otherwise, this can be configured via the setting this._showPrompt(notificationService, storageService, openerService, configurationService, taskNames, locations).then(allow => { if (allow) { storageService.store(HAS_PROMPTED_FOR_AUTOMATIC_TASKS, true, StorageScope.WORKSPACE, StorageTarget.USER); RunAutomaticTasks._runTasks(taskService, tasks); } }); </ins> } }


Question:
Type: <bBug</bVSCode, create a folder named, for instance, "XXXX". that folder create another called .vscode .vscode create a file named with this content: VSCode sure the setting "task.allowAutomaticTasks" is not set or is set to its defautl value "auto". "XXXX" with VSCode. VSCode will run "echo Hello" without asking you whether you want to run tasks configured with "runOn": "folderOpen" or not. VS Code version: Code 1.70.2 (, 2022-08-16T05:35:13.448Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This happens because you have presumably opened a trusted workspace - which is now when we allow these to be run if the setting is "auto" for allow automatic task
The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our . Happy Coding!
! If I understood it correctly, the popup that supposedly asks you whether you want to run these tasks is not actually meant to appear ever because if the workspace is trusted it will be executed without asking you and if it is not trusted then it will just not exeute them instead of asking you. Doesn't it look kinda pointless to have in the description of the option of the configuration "Prompt for permission for each folder"? You are never prompted anyways.
I this configuration and I am still not prompted anyways:
No I did not. Please next time ask the user if he did X before assuming it and closing the issue. I tried reproducing the problem with and without a trusted workspace and the problem persists anyways.
i'll investigate this that shouldn't happen
Tasks will only run in trusted workspaces, so I will update the setting description to indicate that. Also need to fix the prompt not happening per folder.

type: 'string', enum: ['on', 'auto', 'off'], enumDescriptions: [ <del> nls.localize('ttask.allowAutomaticTasks.on', "Always"), </del> <ins> nls.localize('task.allowAutomaticTasks.on', "Always"), </ins> nls.localize('task.allowAutomaticTasks.auto', "Prompt for permission for each folder"), nls.localize('task.allowAutomaticTasks.off', "Never"), ], <del> description: nls.localize('task.allowAutomaticTasks', "Enable automatic tasks in the folder."), </del> <ins> description: nls.localize('task.allowAutomaticTasks', "Enable automatic tasks in the folder - note that tasks won't run in an untrusted workspace."), </ins> default: 'auto', restricted: true },


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. --Noticed that SourcePawn extension has this feature, it should be enabled for built-in C/C++ preprocessor #if and #endif, just like for brackets [] () {} SourcePawn: ! C/C++: ! Could probably be done for other languages that have keywords rather than braces for opening and closing a block, e.g. Lua's if-then-end: !
Not sure if this is editor or C/C++ language config / text mate.
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
Hello there,is this issue open?If so,could i work on this?
Should make request to Just add as brackets to !
This change should be reverted if it can't be made work with all the other preprocessor statements that match the endif: #if, #ifdef, #ifndef, #else, #elif, #elifdef, #elifndef, see matching isn't required, but it shouldn't show the #endif as unmatched.
it'll work fine with the rest of the #if's just #else etc won't work as vscode doesn't support inside/middle brackets but it won't cause any issues
ah..... one thing I forgot about ! bit of a deal breaker vscode would have to support 'transcendent' brackets similar problem to
Oh -- that seems like a different bug? ! -- The red }, not sure how you got the red {. It doesn't repro with VS Code (non-Insiders). Repro code is Should someone file a new bug on that or is it the same root issue?
Yeah, looks like the PR at fixes it though.
Thanks for reporting this! We will revert the PR as it causes too many unexpected issues. If you like to have this, you can configure the brackets to colorize in the user settings.
Okay, I figured it out via The directives remain the unmatched color.
We closed this issue because we in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider. If you wonder what we are up to, please see our and . Thanks for your understanding, and happy coding!

"brackets": [ ["{", "}"], ["[", "]"], <del> ["(", ")"] </del> <ins> ["(", ")"], ["#if","#endif"], </ins> ], "autoClosingPairs": [ { "open": "[", "close": "]" },


Question:
<img width="584" alt="image" src="https://user-"//cc for views
I assume this is nothing to do with the views instead its about how entires are rendered in list/tree. CC
Tree row contents are outside of the tree's jurisdiction, but are in fact responsibility of the widget user.
Timeline doesn't use the extension tree view and instead does it's own thing. I think works on timeline.
curious, do we have an understanding what caused this? it seems relatively recent?
Might be related to . any ideas here?
It was caused by , can you check? I see a visual difference not only with the alignment but also the spacing: Before <img width="254" alt="image" src="https://user-"After <img width="269" alt="image" src="https://user-"
it looks like timeline relies on the custom tree view css. I made a change in the nesting/ordering of elements in the tree view recently and I updated the css to reflect that. Because timeline relies on the css but doesn't actually use the custom tree view, this broke the timeline. I've opened a PR with a timeline specific css fix.

.customview-tree .monaco-list .monaco-list-row .custom-view-tree-node-item { display: flex; <ins> align-items: center; </ins> height: 22px; line-height: 22px; flex: 1;


Question:
<img width="584" alt="image" src="https://user-"//cc for views
I assume this is nothing to do with the views instead its about how entires are rendered in list/tree. CC
Tree row contents are outside of the tree's jurisdiction, but are in fact responsibility of the widget user.
Timeline doesn't use the extension tree view and instead does it's own thing. I think works on timeline.
curious, do we have an understanding what caused this? it seems relatively recent?
Might be related to . any ideas here?
It was caused by , can you check? I see a visual difference not only with the alignment but also the spacing: Before <img width="254" alt="image" src="https://user-"After <img width="269" alt="image" src="https://user-"
it looks like timeline relies on the custom tree view css. I made a change in the nesting/ordering of elements in the tree view recently and I updated the css to reflect that. Because timeline relies on the css but doesn't actually use the custom tree view, this broke the timeline. I've opened a PR with a timeline specific css fix.

display: block; } <ins> .timeline-tree-view .monaco-list .monaco-list-row .custom-view-tree-node-item > .custom-view-tree-node-item-icon, </ins> .customview-tree .monaco-list .monaco-list-row .custom-view-tree-node-item > .custom-view-tree-node-item-resourceLabel > .custom-view-tree-node-item-icon { background-size: 16px; background-position: left center;


Question:
<img width="584" alt="image" src="https://user-"//cc for views
I assume this is nothing to do with the views instead its about how entires are rendered in list/tree. CC
Tree row contents are outside of the tree's jurisdiction, but are in fact responsibility of the widget user.
Timeline doesn't use the extension tree view and instead does it's own thing. I think works on timeline.
curious, do we have an understanding what caused this? it seems relatively recent?
Might be related to . any ideas here?
It was caused by , can you check? I see a visual difference not only with the alignment but also the spacing: Before <img width="254" alt="image" src="https://user-"After <img width="269" alt="image" src="https://user-"
it looks like timeline relies on the custom tree view css. I made a change in the nesting/ordering of elements in the tree view recently and I updated the css to reflect that. Because timeline relies on the css but doesn't actually use the custom tree view, this broke the timeline. I've opened a PR with a timeline specific css fix.

.customview-tree .monaco-list .monaco-list-row .custom-view-tree-node-item .custom-view-tree-node-item-resourceLabel::after { padding-right: 0px; <ins> margin-right: 4px; </ins> } .customview-tree .monaco-list .monaco-list-row .custom-view-tree-node-item .actions {


Question: ox1D426 all char in a-z without m has unicode highlight. ! ps. Can I get a map table for unicode char and its common type?


constructor(controllerId: string, controllerLabel: string, editors: ExtHostDocumentsAndEditors) { super({ controllerId, <del> getDocumentVersion: (uri: URI) => editors.getDocument(uri)?.version, </del> <ins> getDocumentVersion: uri => uri && editors.getDocument(uri)?.version, </ins> getApiFor: getPrivateApiFor as (impl: TestItemImpl) => ITestItemApi<TestItemImpl>, getChildren: (item) => item.children as ITestChildrenLike<TestItemImpl>, root: new TestItemRootImpl(controllerId, controllerLabel),


Question:
Chinese (Simplified) : <img width="321" alt="image" src="https://user-"English : <img width="272" alt="image" src="https://user-""Create Manual Folding Ranges from Selection" is not in Command Palette when use Chinese (Simplified) VSCode Version: 1.71.0 (both macOS & Win10) Chinese (Simplified) Version: 1.71.
Thank you for your feedback. We are currently reviewing it (reference ).
Could you please assist here? Thank you.
The problem is this label: should accept an  but it only accepts a string. deeper: and deeper:
The workaround is to use  to find this item.

super({ id: 'editor.createFoldingRangeFromSelection', label: nls.localize('createManualFoldRange.label', "Create Manual Folding Range from Selection"), <del> alias: 'Create Folding Range from Selection', </del> <ins> alias: 'Create Manual Folding Range from Selection', </ins> precondition: CONTEXT_FOLDING_ENABLED, kbOpts: { kbExpr: EditorContextKeys.editorTextFocus,


Question:
GitHub Tags:#A11yMAS;#A11yTCS;#A11ySev2;#DesktopApp;#Win32;#Visual Studio Code Client;#BM-VisualStudioCodeClient-Win32-Aug2022;#WCAG1.3.1;#NVDA; #ScreenReader;#JAWS;#AILimited;#Element:Button; Application Name: Visual Studio Live Share Application version: 1.56.2 (user setup) Windows Version: Win10 VS Code a project (e.g., vsls-guestbook) in VSCode. till “sign in” button. till "Live share" under Extensions and hit enter on the NVDA and tab to drop down 'Visual Studio live share work' screen. The label of the 'Visual Studio live share work….' is being read as 'folder section button' when the screen reader focus moves to it using tab key. Similar issue is observed with JAWS. The screen reader should read it as 'Visual Studio live share work button' when screen reader focus moves to it. People who uses screen reader may face difficulty while activating an object when the accessible label is different than that of the visible labels. https://user-
logged for primary bug
I think this issue makes sense. In short - aria label of the explorer view should contain the name of the top folder. Currently it is just "Folders". So it should be dynamic. Assigning to
Actually not too sure how to fix this one. The section being read out is the static section name of the view pane We do have an aria label within that section header with the name of the folder which dynamically updates but that never gets focused. The pane registration is static and we don't know the folder name at that time
there's the  method in the . Update header should set the aria label of the header. And the explorer should call updateHeader every time the content of the header changes (which it might do already).
could you please the bug in open state the bug can be closed only by trusted tester after verification right now the fix is not present in the app Version: 1.72.0-insider (user setup) Commit: Date: 2022-09-23T05:17:37.024Z Electron: 19.0.17 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes !
please look at the label that the VS Code bot has to the issue. It says "unreleased". Once the bot adds the label "released" that means the fix is present. We can not leave the issue open for the tester to close this since this does not align with the rest of our VS Code processes. In case the bug is not fixed after it is released, just comment on the issue and we will reopen it. Thanks!
GitHubTags:#Closed;

private _headerVisible = true; private _minimumBodySize: number; private _maximumBodySize: number; <del> private ariaHeaderLabel: string; </del> <ins> private _ariaHeaderLabel: string; </ins> private styles: IPaneStyles = {}; private animationTimer: number | undefined = undefined;


Question:
GitHub Tags:#A11yMAS;#A11yTCS;#A11ySev2;#DesktopApp;#Win32;#Visual Studio Code Client;#BM-VisualStudioCodeClient-Win32-Aug2022;#WCAG1.3.1;#NVDA; #ScreenReader;#JAWS;#AILimited;#Element:Button; Application Name: Visual Studio Live Share Application version: 1.56.2 (user setup) Windows Version: Win10 VS Code a project (e.g., vsls-guestbook) in VSCode. till “sign in” button. till "Live share" under Extensions and hit enter on the NVDA and tab to drop down 'Visual Studio live share work' screen. The label of the 'Visual Studio live share work….' is being read as 'folder section button' when the screen reader focus moves to it using tab key. Similar issue is observed with JAWS. The screen reader should read it as 'Visual Studio live share work button' when screen reader focus moves to it. People who uses screen reader may face difficulty while activating an object when the accessible label is different than that of the visible labels. https://user-
logged for primary bug
I think this issue makes sense. In short - aria label of the explorer view should contain the name of the top folder. Currently it is just "Folders". So it should be dynamic. Assigning to
Actually not too sure how to fix this one. The section being read out is the static section name of the view pane We do have an aria label within that section header with the name of the folder which dynamically updates but that never gets focused. The pane registration is static and we don't know the folder name at that time
there's the  method in the . Update header should set the aria label of the header. And the explorer should call updateHeader every time the content of the header changes (which it might do already).
could you please the bug in open state the bug can be closed only by trusted tester after verification right now the fix is not present in the app Version: 1.72.0-insider (user setup) Commit: Date: 2022-09-23T05:17:37.024Z Electron: 19.0.17 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes !
please look at the label that the VS Code bot has to the issue. It says "unreleased". Once the bot adds the label "released" that means the fix is present. We can not leave the issue open for the tester to close this since this does not align with the rest of our VS Code processes. In case the bug is not fixed after it is released, just comment on the issue and we will reopen it. Thanks!
GitHubTags:#Closed;

private readonly _onDidChangeExpansionState = this._register(new Emitter<boolean>()); readonly onDidChangeExpansionState: Event<boolean> = this._onDidChangeExpansionState.event; <ins> get ariaHeaderLabel(): string { return this._ariaHeaderLabel; } set ariaHeaderLabel(newLabel: string) { this._ariaHeaderLabel = newLabel; this.header.setAttribute('aria-label', this.ariaHeaderLabel); } </ins> get draggableElement(): HTMLElement { return this.header; }


Question:
GitHub Tags:#A11yMAS;#A11yTCS;#A11ySev2;#DesktopApp;#Win32;#Visual Studio Code Client;#BM-VisualStudioCodeClient-Win32-Aug2022;#WCAG1.3.1;#NVDA; #ScreenReader;#JAWS;#AILimited;#Element:Button; Application Name: Visual Studio Live Share Application version: 1.56.2 (user setup) Windows Version: Win10 VS Code a project (e.g., vsls-guestbook) in VSCode. till “sign in” button. till "Live share" under Extensions and hit enter on the NVDA and tab to drop down 'Visual Studio live share work' screen. The label of the 'Visual Studio live share work….' is being read as 'folder section button' when the screen reader focus moves to it using tab key. Similar issue is observed with JAWS. The screen reader should read it as 'Visual Studio live share work button' when screen reader focus moves to it. People who uses screen reader may face difficulty while activating an object when the accessible label is different than that of the visible labels. https://user-
logged for primary bug
I think this issue makes sense. In short - aria label of the explorer view should contain the name of the top folder. Currently it is just "Folders". So it should be dynamic. Assigning to
Actually not too sure how to fix this one. The section being read out is the static section name of the view pane We do have an aria label within that section header with the name of the folder which dynamically updates but that never gets focused. The pane registration is static and we don't know the folder name at that time
there's the  method in the . Update header should set the aria label of the header. And the explorer should call updateHeader every time the content of the header changes (which it might do already).
could you please the bug in open state the bug can be closed only by trusted tester after verification right now the fix is not present in the app Version: 1.72.0-insider (user setup) Commit: Date: 2022-09-23T05:17:37.024Z Electron: 19.0.17 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes !
please look at the label that the VS Code bot has to the issue. It says "unreleased". Once the bot adds the label "released" that means the fix is present. We can not leave the issue open for the tester to close this since this does not align with the rest of our VS Code processes. In case the bug is not fixed after it is released, just comment on the issue and we will reopen it. Thanks!
GitHubTags:#Closed;

super(); this._expanded = typeof options.expanded === 'undefined' ? true : !!options.expanded; this._orientation = typeof options.orientation === 'undefined' ? Orientation.VERTICAL : options.orientation; <del> this.ariaHeaderLabel = localize('viewSection', "{0} Section", options.title); </del> <ins> this._ariaHeaderLabel = localize('viewSection', "{0} Section", options.title); </ins> this._minimumBodySize = typeof options.minimumBodySize === 'number' ? options.minimumBodySize : this._orientation === Orientation.HORIZONTAL ? 200 : 120; this._maximumBodySize = typeof options.maximumBodySize === 'number' ? options.maximumBodySize : Number.POSITIVE_INFINITY;


Question:
GitHub Tags:#A11yMAS;#A11yTCS;#A11ySev2;#DesktopApp;#Win32;#Visual Studio Code Client;#BM-VisualStudioCodeClient-Win32-Aug2022;#WCAG1.3.1;#NVDA; #ScreenReader;#JAWS;#AILimited;#Element:Button; Application Name: Visual Studio Live Share Application version: 1.56.2 (user setup) Windows Version: Win10 VS Code a project (e.g., vsls-guestbook) in VSCode. till “sign in” button. till "Live share" under Extensions and hit enter on the NVDA and tab to drop down 'Visual Studio live share work' screen. The label of the 'Visual Studio live share work….' is being read as 'folder section button' when the screen reader focus moves to it using tab key. Similar issue is observed with JAWS. The screen reader should read it as 'Visual Studio live share work button' when screen reader focus moves to it. People who uses screen reader may face difficulty while activating an object when the accessible label is different than that of the visible labels. https://user-
logged for primary bug
I think this issue makes sense. In short - aria label of the explorer view should contain the name of the top folder. Currently it is just "Folders". So it should be dynamic. Assigning to
Actually not too sure how to fix this one. The section being read out is the static section name of the view pane We do have an aria label within that section header with the name of the folder which dynamically updates but that never gets focused. The pane registration is static and we don't know the folder name at that time
there's the  method in the . Update header should set the aria label of the header. And the explorer should call updateHeader every time the content of the header changes (which it might do already).
could you please the bug in open state the bug can be closed only by trusted tester after verification right now the fix is not present in the app Version: 1.72.0-insider (user setup) Commit: Date: 2022-09-23T05:17:37.024Z Electron: 19.0.17 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes !
please look at the label that the VS Code bot has to the issue. It says "unreleased". Once the bot adds the label "released" that means the fix is present. We can not leave the issue open for the tester to close this since this does not align with the rest of our VS Code processes. In case the bug is not fixed after it is released, just comment on the issue and we will reopen it. Thanks!
GitHubTags:#Closed;

const title = workspace.folders.map(folder => folder.name).join(); titleElement.textContent = this.name; titleElement.title = title; <del> titleElement.setAttribute('aria-label', nls.localize('explorerSection', "Explorer Section: {0}", this.name)); </del> <ins> this.ariaHeaderLabel = nls.localize('explorerSection', "Explorer Section: {0}", this.name); titleElement.setAttribute('aria-label', this.ariaHeaderLabel); </ins> }; this._register(this.contextService.onDidChangeWorkspaceName(setHeader));


NoPathFound = 'NoPathFound', UnknownPath = 'UnknownPath', EmptyCommitMessage = 'EmptyCommitMessage', <del> BranchFastForwardRejected = 'BranchFastForwardRejected' </del> <ins> BranchFastForwardRejected = 'BranchFastForwardRejected', TagConflict = 'TagConflict' </ins> }


} } <ins> async fetchTags(options: { remote: string; tags: string[]; force?: boolean }): Promise<void> { const args = ['fetch']; const spawnOptions: SpawnOptions = { env: { 'GIT_HTTP_USER_AGENT': this.git.userAgent } }; args.push(options.remote); for (const tag of options.tags) { args.push(`refs/tags/${tag}:refs/tags/${tag}`); } if (options.force) { args.push('--force'); } await this.exec(args, spawnOptions); } </ins> async pull(rebase?: boolean, remote?: string, branch?: string, options: PullOptions = {}): Promise<void> { const args = ['pull'];


err.gitErrorCode = GitErrorCodes.CantLockRef; } else if (/cannot rebase onto multiple branches/i.test(err.stderr || '')) { err.gitErrorCode = GitErrorCodes.CantRebaseMultipleBranches; <ins> } else if (/! [rejected].*(would clobber existing tag)/m.test(err.stderr || '')) { err.gitErrorCode = GitErrorCodes.TagConflict; </ins> } throw err;


import { Branch, Change, ForcePushMode, GitErrorCodes, LogOptions, Ref, RefType, Remote, Status, CommitOptions, BranchQuery, FetchOptions } from './api/git'; import { AutoFetcher } from './autofetch'; import { debounce, memoize, throttle } from './decorators'; <del> import { Commit, GitError, Repository as BaseRepository, Stash, Submodule, LogFileOptions } from './git'; </del> <ins> import { Commit, GitError, Repository as BaseRepository, Stash, Submodule, LogFileOptions, PullOptions } from './git'; </ins> import { StatusBarCommands } from './statusbar'; import { toGitUri } from './uri'; import { anyEvent, combinedDisposable, debounceEvent, dispose, EmptyDisposable, eventToPromise, filterEvent, find, IDisposable, isDescendant, onceEvent, pathEquals, relativePath } from './util';


} if (await this.checkIfMaybeRebased(this.HEAD?.name)) { <del> await this.repository.pull(rebase, remote, branch, { unshallow, tags }); </del> <ins> this._pullAndHandleTagConflict(rebase, remote, branch, { unshallow, tags }); </ins> } }); }); } <ins> private async _pullAndHandleTagConflict(rebase?: boolean, remote?: string, branch?: string, options: PullOptions = {}): Promise<void> { try { await this.repository.pull(rebase, remote, branch, options); } catch (err) { if (err.gitErrorCode !== GitErrorCodes.TagConflict) { throw err; } // Handle tag(s) conflict if (await this.handleTagConflict(remote, err.stderr)) { await this.repository.pull(rebase, remote, branch, options); } } } </ins> @throttle async push(head: Branch, forcePushMode?: ForcePushMode): Promise<void> { let remote: string | undefined;


} if (await this.checkIfMaybeRebased(this.HEAD?.name)) { <del> await this.repository.pull(rebase, remoteName, pullBranch, { tags, cancellationToken }); </del> <ins> this._pullAndHandleTagConflict(rebase, remoteName, pullBranch, { tags, cancellationToken }); </ins> } };


return config.get<boolean>('optimisticUpdate') === true; } <ins> private async handleTagConflict(remote: string | undefined, raw: string): Promise<boolean> { // Ensure there is a remote remote = remote ?? this.HEAD?.upstream?.remote; if (!remote) { throw new Error('Unable to resolve tag conflict due to missing remote.'); } // Extract tag names from message const tags: string[] = []; for (const match of raw.matchAll(/^ ! [rejected]s+([^s]+)s+->s+([^s]+)s+(would clobber existing tag)$/gm)) { if (match.length === 3) { tags.push(match[1]); } } if (tags.length === 0) { throw new Error(`Unable to extract tag names from error message: ${raw}`); } // Notification const replaceLocalTags = l10n.t('Replace Local Tag(s)'); const message = l10n.t('Unable to pull from remote repository due to conflicting tag(s): {0}. Would you like to resolve the conflict by replacing the local tag(s)?', tags.join(', ')); const choice = await window.showErrorMessage(message, { modal: true }, replaceLocalTags); if (choice !== replaceLocalTags) { return false; } // Force fetch tags await this.repository.fetchTags({ remote, tags, force: true }); return true; } </ins> public isBranchProtected(name: string = this.HEAD?.name ?? ''): boolean { return this.isBranchProtectedMatcher ? this.isBranchProtectedMatcher(name) : false; }


Question:
Type: <bBug</bI saw the schema prompt for 'types' under terminal contribute, but setting it does not take effect. After checking the vscode source code and issue, I found that this contribution point has been removed. VS Code version: Code 1.71.0 (Universal) (, 2022-09-01T07:25:38.437Z) OS version: Darwin x64 21.4.0 Modes: Sandboxed: No Remote OS version: Linux x64 5.10.3+ <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
!
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.71.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Related Links:
After upgrading to , it still remain.

description: nls.localize('vscode.extension.contributes.terminal', 'Contributes terminal functionality.'), type: 'object', properties: { <del> types: { type: 'array', description: nls.localize('vscode.extension.contributes.terminal.types', "Defines additional terminal types that the user can create."), items: { type: 'object', required: ['command', 'title'], properties: { command: { description: nls.localize('vscode.extension.contributes.terminal.types.command', "Command to execute when the user creates this type of terminal."), type: 'string', }, title: { description: nls.localize('vscode.extension.contributes.terminal.types.title', "Title for this type of terminal."), type: 'string', }, icon: { description: nls.localize('vscode.extension.contributes.terminal.types.icon', "A codicon, URI, or light and dark URIs to associate with this terminal type."), anyOf: [{ type: 'string', }, { type: 'object', properties: { light: { description: nls.localize('vscode.extension.contributes.terminal.types.icon.light', 'Icon path when a light theme is used'), type: 'string' }, dark: { description: nls.localize('vscode.extension.contributes.terminal.types.icon.dark', 'Icon path when a dark theme is used'), type: 'string' } } }] }, }, }, }, </del> profiles: { type: 'array', description: nls.localize('vscode.extension.contributes.terminal.profiles', "Defines additional terminal profiles that the user can create."),


Question:
Here is my code snippet Trying to run this creates:
I can't seem to reproduce this on code-web or
I was using The only changes were these in
I can still reproduce this in my code. I ran out of source to see what might cause the problem and here is a detailed stack trace: Might be some timing issue
More digging. Here are my findings: I do open the terminal from a debug adapter which brings the debugger viewlet to front right after I created the terminal if I wrap my code into a everything works fine
any tip or fix for this. I improved the performance on my end and a 2 sec delay is now very bad. My Python execution in the Web is now < 500 ms.
I need to reopen this. I tested it on todays insider and I still get
Build I used is: <img width="500" alt="image" src="https://user-"
I will compile steps today on how to reproduce this.
Steps to reproduce: clone cd vscode-python-web-wasm git co dbaeumer/noTimeout npm install npm run compile npm run esbuild open VS Code run as a task or in the terminal run as a task or in the terminal click on the link in the tunnel terminal and press continue open a browser on Run command Use the link from the tunnel open developer tools open in the browser window From the play menu in the editor run Observe: you get the above exception and the terminal is not showing the output Run the action again Observe: the terminal reveals correctly and shows the output
Can reproduce with those steps, the only thing missing was enabling workspace trust and reloading after installing the web extension
Debugging this section: It's visible before so it doesn't do the extra open view, and not visible after it because the debug console steals the opened view.
Even if this issue was fixed such that did not throw (eg. make an optionally synchronous version of or just try ), it would still set visible and then immediately show the debug console. So if you wanted to show the terminal, you would need to call it after the debug console shows (eg. via timeout as you have). I don't think this is an issue that needs to be fixed in the terminal, but rather you should either prevent whatever is showing the debug console as it happens some time after the terminal is created, or move the call to after the debug console shows. let me know if you disagree.
IMO there are two different things: the fact that the terminal is not in front because the debug terminal comes to front. I do agree that this is something I should address the fact that the terminal seems broken (e.g. it doesn't render the output for the first created terminal). This I agrue is a bug in the terminal. IMO the terminal should function correctly after a create even if I don't call show. So if a user later on clicks on the terminal the output is shown correctly.
the second issue should be fixed by , it won't fix your problem though
to understand it correctly. This will ensure that the terminal is functional after . I can then ensure that I bring the terminal to front () after the debugger is initialized.
yeah, removing that await should ensure the view is visible so the element will be there to attach which means no exception that ruins the state.

await timeout(0); const instance = this.activeInstance; if (instance) { <ins> // HACK: Ensure the panel is still visible at this point as there may have been // a request since it was opened to show a different panel if (pane && !pane.isVisible()) { await this._viewsService.openView(TERMINAL_VIEW_ID, focus); } </ins> await instance.focusWhenReady(true); // HACK: as a workaround for https://github.com/microsoft/vscode/issues/134692, // this will trigger a forced refresh of the viewport to sync the viewport and scroll bar.


Question:
Here is my code snippet Trying to run this creates:
I can't seem to reproduce this on code-web or
I was using The only changes were these in
I can still reproduce this in my code. I ran out of source to see what might cause the problem and here is a detailed stack trace: Might be some timing issue
More digging. Here are my findings: I do open the terminal from a debug adapter which brings the debugger viewlet to front right after I created the terminal if I wrap my code into a everything works fine
any tip or fix for this. I improved the performance on my end and a 2 sec delay is now very bad. My Python execution in the Web is now < 500 ms.
I need to reopen this. I tested it on todays insider and I still get
Build I used is: <img width="500" alt="image" src="https://user-"
I will compile steps today on how to reproduce this.
Steps to reproduce: clone cd vscode-python-web-wasm git co dbaeumer/noTimeout npm install npm run compile npm run esbuild open VS Code run as a task or in the terminal run as a task or in the terminal click on the link in the tunnel terminal and press continue open a browser on Run command Use the link from the tunnel open developer tools open in the browser window From the play menu in the editor run Observe: you get the above exception and the terminal is not showing the output Run the action again Observe: the terminal reveals correctly and shows the output
Can reproduce with those steps, the only thing missing was enabling workspace trust and reloading after installing the web extension
Debugging this section: It's visible before so it doesn't do the extra open view, and not visible after it because the debug console steals the opened view.
Even if this issue was fixed such that did not throw (eg. make an optionally synchronous version of or just try ), it would still set visible and then immediately show the debug console. So if you wanted to show the terminal, you would need to call it after the debug console shows (eg. via timeout as you have). I don't think this is an issue that needs to be fixed in the terminal, but rather you should either prevent whatever is showing the debug console as it happens some time after the terminal is created, or move the call to after the debug console shows. let me know if you disagree.
IMO there are two different things: the fact that the terminal is not in front because the debug terminal comes to front. I do agree that this is something I should address the fact that the terminal seems broken (e.g. it doesn't render the output for the first created terminal). This I agrue is a bug in the terminal. IMO the terminal should function correctly after a create even if I don't call show. So if a user later on clicks on the terminal the output is shown correctly.
the second issue should be fixed by , it won't fix your problem though
to understand it correctly. This will ensure that the terminal is functional after . I can then ensure that I bring the terminal to front () after the debugger is initialized.
yeah, removing that await should ensure the view is visible so the element will be there to attach which means no exception that ruins the state.

if (pane && !pane.isVisible()) { await this._viewsService.openView(TERMINAL_VIEW_ID, focus); } <del> await instance.focusWhenReady(true); </del> <ins> // Do not await the focus as setVisible must be called immediately to ensure // something else didn't steal focus instance.focusWhenReady(true); </ins> // HACK: as a workaround for https://github.com/microsoft/vscode/issues/134692, // this will trigger a forced refresh of the viewport to sync the viewport and scroll bar. // This can likely be removed after https://github.com/xtermjs/xterm.js/issues/291 is


Question:
Locally I have an empty cell at the bottom of my notebook because I executed the last cell When I try to merge in a change that has new cells, I get a merge conflict that requires I open the ipynb in a text editor to resolve. !
We can explore how to handle this gracefully in the serializer.
not sure what needs to be done in the serializer here. can you provide more information, i would have thought this was purely an issue with merge conflicts.
Can this please be solved? It's hard to work collaboratively within a team using Jupyter notebooks and VS Code if we can't sort out merge conflicts.
I suggest there be an option to disable the notebook renderer temporarily in all editors. git operates at the text level and when merge conflict happens, it will likely produce a malformed JSON file. We now have an error message to notify users to fallback to text editor, but "resolve in merge editor" button still don't work. !
Note: When there are merge conflicts, one will always have to open a plain text (json) editor to resolve the merge confligs I.e. its not possible to use Notebook UI to resolve merge conflicts (at least not yet) Steps to test Ensure you have merge conflicts in a Notebook document Open the SCM view, and click on the IPYNB file, and verify you can see the merge conflicts in plain text editor view Click on the button and verify you get the merge editor (again plain text), see here When you have merge conflicts, try opening the ipynb file from the explorer view, if this fails verify you are displayed with an error message with the option to open the file in plain text view

import { Disposable, DisposableStore, IDisposable, toDisposable } from 'vs/base/common/lifecycle'; import { ResourceMap } from 'vs/base/common/map'; import { Schemas } from 'vs/base/common/network'; <del> import { isEqual } from 'vs/base/common/resources'; </del> <ins> import { basename, isEqual } from 'vs/base/common/resources'; </ins> import { isDefined } from 'vs/base/common/types'; import { URI } from 'vs/base/common/uri'; import { IAccessibilityService } from 'vs/platform/accessibility/common/accessibility';


Question:
Locally I have an empty cell at the bottom of my notebook because I executed the last cell When I try to merge in a change that has new cells, I get a merge conflict that requires I open the ipynb in a text editor to resolve. !
We can explore how to handle this gracefully in the serializer.
not sure what needs to be done in the serializer here. can you provide more information, i would have thought this was purely an issue with merge conflicts.
Can this please be solved? It's hard to work collaboratively within a team using Jupyter notebooks and VS Code if we can't sort out merge conflicts.
I suggest there be an option to disable the notebook renderer temporarily in all editors. git operates at the text level and when merge conflict happens, it will likely produce a malformed JSON file. We now have an error message to notify users to fallback to text editor, but "resolve in merge editor" button still don't work. !
Note: When there are merge conflicts, one will always have to open a plain text (json) editor to resolve the merge confligs I.e. its not possible to use Notebook UI to resolve merge conflicts (at least not yet) Steps to test Ensure you have merge conflicts in a Notebook document Open the SCM view, and click on the IPYNB file, and verify you can see the merge conflicts in plain text editor view Click on the button and verify you get the merge editor (again plain text), see here When you have merge conflicts, try opening the ipynb file from the explorer view, if this fails verify you are displayed with an error message with the option to open the file in plain text view

import { NotebookOutputRendererInfo, NotebookStaticPreloadInfo as NotebookStaticPreloadInfo } from 'vs/workbench/contrib/notebook/common/notebookOutputRenderer'; import { NotebookEditorDescriptor, NotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookProvider'; import { INotebookSerializer, INotebookService, SimpleNotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookService'; <del> import { DiffEditorInputFactoryFunction, EditorInputFactoryFunction, EditorInputFactoryObject, IEditorResolverService, IEditorType, RegisteredEditorInfo, RegisteredEditorPriority, UntitledEditorInputFactoryFunction } from 'vs/workbench/services/editor/common/editorResolverService'; </del> <ins> import { DiffEditorInputFactoryFunction, EditorInputFactoryFunction, EditorInputFactoryObject, IEditorResolverService, IEditorType, RegisteredEditorInfo, RegisteredEditorPriority, UntitledEditorInputFactoryFunction, type MergeEditorInputFactoryFunction } from 'vs/workbench/services/editor/common/editorResolverService'; </ins> import { IExtensionService, isProposedApiEnabled } from 'vs/workbench/services/extensions/common/extensions'; import { IExtensionPointUser } from 'vs/workbench/services/extensions/common/extensionsRegistry'; import { InstallRecommendedExtensionAction } from 'vs/workbench/contrib/extensions/browser/extensionsActions'; import { IUriIdentityService } from 'vs/platform/uriIdentity/common/uriIdentity'; import { INotebookDocument, INotebookDocumentService } from 'vs/workbench/services/notebook/common/notebookDocumentService'; <ins> import { MergeEditorInput } from 'vs/workbench/contrib/mergeEditor/browser/mergeEditorInput'; import type { EditorInputWithOptions, IResourceMergeEditorInput } from 'vs/workbench/common/editor'; </ins> export class NotebookProviderInfoStore extends Disposable {


Question:
Locally I have an empty cell at the bottom of my notebook because I executed the last cell When I try to merge in a change that has new cells, I get a merge conflict that requires I open the ipynb in a text editor to resolve. !
We can explore how to handle this gracefully in the serializer.
not sure what needs to be done in the serializer here. can you provide more information, i would have thought this was purely an issue with merge conflicts.
Can this please be solved? It's hard to work collaboratively within a team using Jupyter notebooks and VS Code if we can't sort out merge conflicts.
I suggest there be an option to disable the notebook renderer temporarily in all editors. git operates at the text level and when merge conflict happens, it will likely produce a malformed JSON file. We now have an error message to notify users to fallback to text editor, but "resolve in merge editor" button still don't work. !
Note: When there are merge conflicts, one will always have to open a plain text (json) editor to resolve the merge confligs I.e. its not possible to use Notebook UI to resolve merge conflicts (at least not yet) Steps to test Ensure you have merge conflicts in a Notebook document Open the SCM view, and click on the IPYNB file, and verify you can see the merge conflicts in plain text editor view Click on the button and verify you get the merge editor (again plain text), see here When you have merge conflicts, try opening the ipynb file from the explorer view, if this fails verify you are displayed with an error message with the option to open the file in plain text view

const notebookDiffEditorInputFactory: DiffEditorInputFactoryFunction = ({ modified, original, label, description }) => { return { editor: NotebookDiffEditorInput.create(this._instantiationService, modified.resource!, label, description, original.resource!, notebookProviderInfo.id) }; }; <ins> const mergeEditorInputFactory: MergeEditorInputFactoryFunction = (mergeEditor: IResourceMergeEditorInput): EditorInputWithOptions => { return { editor: this._instantiationService.createInstance( MergeEditorInput, mergeEditor.base.resource, { uri: mergeEditor.input1.resource, title: mergeEditor.input1.label ?? basename(mergeEditor.input1.resource), description: mergeEditor.input1.description ?? '', detail: mergeEditor.input1.detail }, { uri: mergeEditor.input2.resource, title: mergeEditor.input2.label ?? basename(mergeEditor.input2.resource), description: mergeEditor.input2.description ?? '', detail: mergeEditor.input2.detail }, mergeEditor.result.resource ) }; }; </ins> const notebookFactoryObject: EditorInputFactoryObject = { createEditorInput: notebookEditorInputFactory, createDiffEditorInput: notebookDiffEditorInputFactory, createUntitledEditorInput: notebookUntitledEditorFactory, <ins> createMergeEditorInput: mergeEditorInputFactory </ins> }; const notebookCellFactoryObject: EditorInputFactoryObject = { createEditorInput: notebookEditorInputFactory,


Question:
Fyi there is no long running shutdown support on web, so this warning gets printed on unload: <img width="955" alt="image" src="https://user-"
In web we probably cannot support the value.
This is still on
I cannot reproduce this, just to be sure this is on the latest
Yes, reproduces even with caches disabled: !

import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { EditSessionsDataViews } from 'vs/workbench/contrib/editSessions/browser/editSessionsViews'; import { EditSessionsFileSystemProvider } from 'vs/workbench/contrib/editSessions/browser/editSessionsFileSystemProvider'; <del> import { isNative } from 'vs/base/common/platform'; </del> <ins> import { isNative, isWeb } from 'vs/base/common/platform'; </ins> import { VirtualWorkspaceContext, WorkspaceFolderCountContext } from 'vs/workbench/common/contextkeys'; import { CancellationToken, CancellationTokenSource } from 'vs/base/common/cancellation'; import { equals } from 'vs/base/common/objects';


Question:
Fyi there is no long running shutdown support on web, so this warning gets printed on unload: <img width="955" alt="image" src="https://user-"
In web we probably cannot support the value.
This is still on
I cannot reproduce this, just to be sure this is on the latest
Yes, reproduces even with caches disabled: !

} private async autoStoreEditSession() { <del> if (this.configurationService.getValue('workbench.experimental.cloudChanges.autoStore') === 'onShutdown') { </del> <ins> if (this.configurationService.getValue('workbench.experimental.cloudChanges.autoStore') === 'onShutdown' && !isWeb) { </ins> const cancellationTokenSource = new CancellationTokenSource(); await this.progressService.withProgress({ location: ProgressLocation.Window,


Question:
Fyi there is no long running shutdown support on web, so this warning gets printed on unload: <img width="955" alt="image" src="https://user-"
In web we probably cannot support the value.
This is still on
I cannot reproduce this, just to be sure this is on the latest
Yes, reproduces even with caches disabled: !

'type': 'string', 'tags': ['experimental', 'usesOnlineServices'], 'default': 'off', <del> 'markdownDescription': localize('autoStoreWorkingChangesDescription', "Controls whether to automatically store available working changes in the cloud for the current workspace."), </del> <ins> 'markdownDescription': localize('autoStoreWorkingChangesDescription', "Controls whether to automatically store available working changes in the cloud for the current workspace. This setting has no effect in the web."), </ins> }, 'workbench.cloudChanges.autoResume': { enum: ['onReload', 'off'],


Question:
Fyi there is no long running shutdown support on web, so this warning gets printed on unload: <img width="955" alt="image" src="https://user-"
In web we probably cannot support the value.
This is still on
I cannot reproduce this, just to be sure this is on the latest
Yes, reproduces even with caches disabled: !

this.shouldShowViewsContext = EDIT_SESSIONS_SHOW_VIEW.bindTo(this.contextKeyService); this._register(this.fileService.registerProvider(EditSessionsFileSystemProvider.SCHEMA, new EditSessionsFileSystemProvider(this.editSessionsStorageService))); <del> this.lifecycleService.onWillShutdown((e) => e.join(this.autoStoreEditSession(), { id: 'autoStoreWorkingChanges', label: localize('autoStoreWorkingChanges', 'Storing current working changes...') })); </del> <ins> this.lifecycleService.onWillShutdown((e) => { if (this.configurationService.getValue('workbench.experimental.cloudChanges.autoStore') === 'onShutdown' && !isWeb) { e.join(this.autoStoreEditSession(), { id: 'autoStoreWorkingChanges', label: localize('autoStoreWorkingChanges', 'Storing current working changes...') }); } }); </ins> this._register(this.editSessionsStorageService.onDidSignIn(() => this.updateAccountsMenuBadge())); this._register(this.editSessionsStorageService.onDidSignOut(() => this.updateAccountsMenuBadge())); }


Question:
Fyi there is no long running shutdown support on web, so this warning gets printed on unload: <img width="955" alt="image" src="https://user-"
In web we probably cannot support the value.
This is still on
I cannot reproduce this, just to be sure this is on the latest
Yes, reproduces even with caches disabled: !

} private async autoStoreEditSession() { <del> if (this.configurationService.getValue('workbench.experimental.cloudChanges.autoStore') === 'onShutdown' && !isWeb) { const cancellationTokenSource = new CancellationTokenSource(); await this.progressService.withProgress({ location: ProgressLocation.Window, type: 'syncing', title: localize('store working changes', 'Storing working changes...') }, async () => this.storeEditSession(false, cancellationTokenSource.token), () => { cancellationTokenSource.cancel(); cancellationTokenSource.dispose(); }); } </del> <ins> const cancellationTokenSource = new CancellationTokenSource(); await this.progressService.withProgress({ location: ProgressLocation.Window, type: 'syncing', title: localize('store working changes', 'Storing working changes...') }, async () => this.storeEditSession(false, cancellationTokenSource.token), () => { cancellationTokenSource.cancel(); cancellationTokenSource.dispose(); }); </ins> } private registerViews() {


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.71.2 OS Version: macOS Monterey 12.5.1 (21G83) Steps to Reproduce: file named the file to the title of the file's editor tab <img width="199" alt="image" src="https://user-"Is still , not the new name . until reopen the file. But rename to is ok. Also reanme to is ok. Just rename to is not ok.
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
rename to is not ok. rename to is ok. It seems that some intersting things work wrong here.
Can you try to run where is an empty folder? This will ensure Code is starting with a fresh data directory, e.g. no specific settings and without any extensions running.
As you see, nothing changed.
Hm yeah I think I see it too, the first rename works fine but then renaming back does not work, is that what you see?
this is a funny one and indeed a regression from our work to always go through the editor resolver when resolving editors and not go through the as a shortcut. Steps open an empty folder with 1 file open the file rename it from the explorer to verify the tab label updates rename it from the explorer to the label does not update Here is how it used to be the rename operation will eventually hit since this is a default text editor we would directly use we figure out that we have an existing editor input so we do not create a new one however we update its preferred resource this triggers a label change event that will update the tab label =this works every time you rename, irrespective of going back and forward of the name Here is how it is today we also end up in however we always now go to the editor resolver (which imho is good) the editor resolver however does not consider the input to be a new input after the first rename because the canonical resource is still how it was in the begining, it will do an early return as such, the inputs preferred resource is never updated Now I am actually not so sure how to fix this. I am a bit worried that updating the method to respect resource path casing may break other behaviour that relies on the current behaviour. Maybe the resolver should not be so clever to do an early return? Why do we do this?
Yeah maybe, I think it was to prevent creating too many inputs and calling unnecessary factories when things are not actually changing at all. I guess we could always remove the early return and see what breaks.
At least for text file editors, there is caching so that we do not end up with an editor input each time, but I think the same issue already exists today: if you do not have a tab as active and the editor resolver is used to bring up that editor, we would delegate the decision whether to create an editor input or not to the provider and so its up to the provider imho to do the caching.
Sorry, got caught up in other work and missed this. Will attempt a fix early in debt week for the November release as it is too risky to go in this late

} let resource = EditorResourceAccessor.getCanonicalUri(untypedEditor, { supportSideBySide: SideBySideEditor.PRIMARY }); <del> const options = untypedEditor.options; </del> // If it was resolved before we await for the extensions to activate and then proceed with resolution or else the backing extensions won't be registered if (this.cache && resource && this.resourceMatchesCache(resource)) {


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.71.2 OS Version: macOS Monterey 12.5.1 (21G83) Steps to Reproduce: file named the file to the title of the file's editor tab <img width="199" alt="image" src="https://user-"Is still , not the new name . until reopen the file. But rename to is ok. Also reanme to is ok. Just rename to is not ok.
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
rename to is not ok. rename to is ok. It seems that some intersting things work wrong here.
Can you try to run where is an empty folder? This will ensure Code is starting with a fresh data directory, e.g. no specific settings and without any extensions running.
As you see, nothing changed.
Hm yeah I think I see it too, the first rename works fine but then renaming back does not work, is that what you see?
this is a funny one and indeed a regression from our work to always go through the editor resolver when resolving editors and not go through the as a shortcut. Steps open an empty folder with 1 file open the file rename it from the explorer to verify the tab label updates rename it from the explorer to the label does not update Here is how it used to be the rename operation will eventually hit since this is a default text editor we would directly use we figure out that we have an existing editor input so we do not create a new one however we update its preferred resource this triggers a label change event that will update the tab label =this works every time you rename, irrespective of going back and forward of the name Here is how it is today we also end up in however we always now go to the editor resolver (which imho is good) the editor resolver however does not consider the input to be a new input after the first rename because the canonical resource is still how it was in the begining, it will do an early return as such, the inputs preferred resource is never updated Now I am actually not so sure how to fix this. I am a bit worried that updating the method to respect resource path casing may break other behaviour that relies on the current behaviour. Maybe the resolver should not be so clever to do an early return? Why do we do this?
Yeah maybe, I think it was to prevent creating too many inputs and calling unnecessary factories when things are not actually changing at all. I guess we could always remove the early return and see what breaks.
At least for text file editors, there is caching so that we do not end up with an editor input each time, but I think the same issue already exists today: if you do not have a tab as active and the editor resolver is used to bring up that editor, we would delegate the decision whether to create an editor input or not to the provider and so its up to the provider imho to do the caching.
Sorry, got caught up in other work and missed this. Will attempt a fix early in debt week for the November release as it is too risky to go in this late

return ResolvedStatus.NONE; } <del> // If it's the currently active editor we shouldn't do anything const activeEditor = group.activeEditor; const isActive = activeEditor ? activeEditor.matches(untypedEditor) : false; if (activeEditor && isActive) { return { editor: activeEditor, options, group }; } </del> const input = await this.doResolveEditor(untypedEditor, group, selectedEditor); if (conflictingDefault && input) { // Show the conflicting default dialog


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.71.2 OS Version: macOS Monterey 12.5.1 (21G83) Steps to Reproduce: file named the file to the title of the file's editor tab <img width="199" alt="image" src="https://user-"Is still , not the new name . until reopen the file. But rename to is ok. Also reanme to is ok. Just rename to is not ok.
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
rename to is not ok. rename to is ok. It seems that some intersting things work wrong here.
Can you try to run where is an empty folder? This will ensure Code is starting with a fresh data directory, e.g. no specific settings and without any extensions running.
As you see, nothing changed.
Hm yeah I think I see it too, the first rename works fine but then renaming back does not work, is that what you see?
this is a funny one and indeed a regression from our work to always go through the editor resolver when resolving editors and not go through the as a shortcut. Steps open an empty folder with 1 file open the file rename it from the explorer to verify the tab label updates rename it from the explorer to the label does not update Here is how it used to be the rename operation will eventually hit since this is a default text editor we would directly use we figure out that we have an existing editor input so we do not create a new one however we update its preferred resource this triggers a label change event that will update the tab label =this works every time you rename, irrespective of going back and forward of the name Here is how it is today we also end up in however we always now go to the editor resolver (which imho is good) the editor resolver however does not consider the input to be a new input after the first rename because the canonical resource is still how it was in the begining, it will do an early return as such, the inputs preferred resource is never updated Now I am actually not so sure how to fix this. I am a bit worried that updating the method to respect resource path casing may break other behaviour that relies on the current behaviour. Maybe the resolver should not be so clever to do an early return? Why do we do this?
Yeah maybe, I think it was to prevent creating too many inputs and calling unnecessary factories when things are not actually changing at all. I guess we could always remove the early return and see what breaks.
At least for text file editors, there is caching so that we do not end up with an editor input each time, but I think the same issue already exists today: if you do not have a tab as active and the editor resolver is used to bring up that editor, we would delegate the decision whether to create an editor input or not to the provider and so its up to the provider imho to do the caching.
Sorry, got caught up in other work and missed this. Will attempt a fix early in debt week for the November release as it is too risky to go in this late

import { EditorActivation, IResourceEditorInput } from 'vs/platform/editor/common/editor'; import { URI } from 'vs/base/common/uri'; import { Event } from 'vs/base/common/event'; <del> import { DEFAULT_EDITOR_ASSOCIATION, EditorCloseContext, EditorsOrder, IEditorCloseEvent, EditorInputWithOptions, IEditorPane, IResourceDiffEditorInput, isEditorInputWithOptions, IUntitledTextResourceEditorInput, IUntypedEditorInput, SideBySideEditor } from 'vs/workbench/common/editor'; </del> <ins> import { DEFAULT_EDITOR_ASSOCIATION, EditorCloseContext, EditorsOrder, IEditorCloseEvent, EditorInputWithOptions, IEditorPane, IResourceDiffEditorInput, isEditorInputWithOptions, IUntitledTextResourceEditorInput, IUntypedEditorInput, SideBySideEditor, isEditorInput } from 'vs/workbench/common/editor'; </ins> import { workbenchInstantiationService, TestServiceAccessor, registerTestEditor, TestFileEditorInput, ITestInstantiationService, registerTestResourceEditor, registerTestSideBySideEditor, createEditorPart, registerTestFileEditor, TestTextFileEditor, TestSingletonFileEditorInput } from 'vs/workbench/test/browser/workbenchTestServices'; import { EditorService } from 'vs/workbench/services/editor/browser/editorService'; import { IEditorGroup, IEditorGroupsService, GroupDirection, GroupsArrangement } from 'vs/workbench/services/editor/common/editorGroupsService';


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.71.2 OS Version: macOS Monterey 12.5.1 (21G83) Steps to Reproduce: file named the file to the title of the file's editor tab <img width="199" alt="image" src="https://user-"Is still , not the new name . until reopen the file. But rename to is ok. Also reanme to is ok. Just rename to is not ok.
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
rename to is not ok. rename to is ok. It seems that some intersting things work wrong here.
Can you try to run where is an empty folder? This will ensure Code is starting with a fresh data directory, e.g. no specific settings and without any extensions running.
As you see, nothing changed.
Hm yeah I think I see it too, the first rename works fine but then renaming back does not work, is that what you see?
this is a funny one and indeed a regression from our work to always go through the editor resolver when resolving editors and not go through the as a shortcut. Steps open an empty folder with 1 file open the file rename it from the explorer to verify the tab label updates rename it from the explorer to the label does not update Here is how it used to be the rename operation will eventually hit since this is a default text editor we would directly use we figure out that we have an existing editor input so we do not create a new one however we update its preferred resource this triggers a label change event that will update the tab label =this works every time you rename, irrespective of going back and forward of the name Here is how it is today we also end up in however we always now go to the editor resolver (which imho is good) the editor resolver however does not consider the input to be a new input after the first rename because the canonical resource is still how it was in the begining, it will do an early return as such, the inputs preferred resource is never updated Now I am actually not so sure how to fix this. I am a bit worried that updating the method to respect resource path casing may break other behaviour that relies on the current behaviour. Maybe the resolver should not be so clever to do an early return? Why do we do this?
Yeah maybe, I think it was to prevent creating too many inputs and calling unnecessary factories when things are not actually changing at all. I guess we could always remove the early return and see what breaks.
At least for text file editors, there is caching so that we do not end up with an editor input each time, but I think the same issue already exists today: if you do not have a tab as active and the editor resolver is used to bring up that editor, we would delegate the decision whether to create an editor input or not to the provider and so its up to the provider imho to do the caching.
Sorry, got caught up in other work and missed this. Will attempt a fix early in debt week for the November release as it is too risky to go in this late

async function openEditor(editor: EditorInputWithOptions | IUntypedEditorInput, group?: PreferredGroup): Promise<IEditorPane | undefined> { if (useOpenEditors) { <ins> // The type safety isn't super good here, so we assist with runtime checks // Open editors expects untyped or editor input with options, you cannot pass a typed editor input // without options if (!isEditorInputWithOptions(editor) && isEditorInput(editor)) { editor = { editor: editor, options: {} }; } </ins> const panes = await service.openEditors([editor], group); return panes[0]; }


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.71.2 OS Version: macOS Monterey 12.5.1 (21G83) Steps to Reproduce: file named the file to the title of the file's editor tab <img width="199" alt="image" src="https://user-"Is still , not the new name . until reopen the file. But rename to is ok. Also reanme to is ok. Just rename to is not ok.
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from:
rename to is not ok. rename to is ok. It seems that some intersting things work wrong here.
Can you try to run where is an empty folder? This will ensure Code is starting with a fresh data directory, e.g. no specific settings and without any extensions running.
As you see, nothing changed.
Hm yeah I think I see it too, the first rename works fine but then renaming back does not work, is that what you see?
this is a funny one and indeed a regression from our work to always go through the editor resolver when resolving editors and not go through the as a shortcut. Steps open an empty folder with 1 file open the file rename it from the explorer to verify the tab label updates rename it from the explorer to the label does not update Here is how it used to be the rename operation will eventually hit since this is a default text editor we would directly use we figure out that we have an existing editor input so we do not create a new one however we update its preferred resource this triggers a label change event that will update the tab label =this works every time you rename, irrespective of going back and forward of the name Here is how it is today we also end up in however we always now go to the editor resolver (which imho is good) the editor resolver however does not consider the input to be a new input after the first rename because the canonical resource is still how it was in the begining, it will do an early return as such, the inputs preferred resource is never updated Now I am actually not so sure how to fix this. I am a bit worried that updating the method to respect resource path casing may break other behaviour that relies on the current behaviour. Maybe the resolver should not be so clever to do an early return? Why do we do this?
Yeah maybe, I think it was to prevent creating too many inputs and calling unnecessary factories when things are not actually changing at all. I guess we could always remove the early return and see what breaks.
At least for text file editors, there is caching so that we do not end up with an editor input each time, but I think the same issue already exists today: if you do not have a tab as active and the editor resolver is used to bring up that editor, we would delegate the decision whether to create an editor input or not to the provider and so its up to the provider imho to do the caching.
Sorry, got caught up in other work and missed this. Will attempt a fix early in debt week for the November release as it is too risky to go in this late

assert.ok(typedEditor instanceof TestFileEditorInput); assert.strictEqual(typedEditor?.resource?.toString(), untypedEditorReplacement.resource.toString()); <del> assert.strictEqual(editorFactoryCalled, 2); </del> <ins> assert.strictEqual(editorFactoryCalled, 3); </ins> assert.strictEqual(untitledEditorFactoryCalled, 0); assert.strictEqual(diffEditorFactoryCalled, 0);