Question:
Install Java extension pack Open VS Code repo Cmd+Shift+B Java extension prompts error and the task detection never finishes
We have to wait for extensions to be registered before reading the tasks because of task contributions from extensions. I don't think we can change this. thoughts?
We could have a timeout per task provider. If a task provider doesn't provide tasks for 3 minutes after we ask for tasks then it's likely it will never provide tasks. That would let us show the tasks for all the other extensions except the slow one.
I just hit this again , in a VS Code instance that had been running for quite some time. Are there logs that we can provide next time this happens? I enabled trace logging and looked in the Tasks output channel but did not see anything other than a warning about shell tasks being unavailable.
I will try to get to this in March, no logs are needed as we understand how this could happen
Original repro steps still work
Steps still work sometimes - saw this when I reproduced !
Alright, onto something - the consistent repro for me is when there's a multi-root workspace - with each repo contributing a default build task. the build task see quick pick with a bunch of tasks, not just the default build tasks When that's the case, yields none because none of the tasks have a property set yet and that is required for this predicate to be true So enters here and by that time, the group is defined ! and since there are multiple, this gets called
Then it enters and concatenates non-defaults to the defaults. I don't think we want to do that. !
the fix is to only get the defaults and show those. we don't care about the others here. !
Regression introduced by , but there's also the timing component as indicated above - the group isn't set when we expect it to be. Perhaps in the single repo case, the hasn't yet been set by the time , the second attempt, occurs
I think we should be awaiting before running the build command
Apparently this still happens
ok in OSS where I'm reproducing, it goes in here like I thought ! then there are no workspace tasks found ! so it goes here !
only the are used here !
so the issue is the aren't resolved in this case. it's not timing dependent - I can repro long after the window has opened. !
I think here should have a size 0 !
interesting - I wonder if this is the issue !
worked: ! failed: !
so I think what's happening is if I trigger the build task before folder open, the promise is set but the tasks for that folder aren't parsed. then we return that promise indefinitely. I think checking if the is is in order here and in that case, we want to update the workspace tasks instead of returning the promise
yep - I believe that works. ! So the repro is to run the build task before the folder opens.
Just reproduced twice. When I did, both times it said this:
still happens in the build I created with the latest fix. note that i don't see extensions getting activated in the status bar here at all I also don't see the workspace folder undefined message anymore, but still see that the tasks are unavailable in the current environment.
the moment I change the file, it starts to work. IE when this is called
While it's possible (extremely rare) that a user will still hit this if they run the build task before a particular execution context has been set, this fix will prevent that from reproducing. To verify, open VS code (typically a restart) and run the build task. If you do see the quickpick instead of the default build task getting, run, then the next time you run the build task, you should not see it. The above should be hard to reproduce though - and only possible if you time it just right. Before, this would happen more frequently and was reproducible until window reload.

this._tasksReconnected = true; return; } <del> this._getTaskSystem(); </del> this.getWorkspaceTasks().then(async () => { this._tasksReconnected = await this._reconnectTasks(); });


Question:
Install Java extension pack Open VS Code repo Cmd+Shift+B Java extension prompts error and the task detection never finishes
We have to wait for extensions to be registered before reading the tasks because of task contributions from extensions. I don't think we can change this. thoughts?
We could have a timeout per task provider. If a task provider doesn't provide tasks for 3 minutes after we ask for tasks then it's likely it will never provide tasks. That would let us show the tasks for all the other extensions except the slow one.
I just hit this again , in a VS Code instance that had been running for quite some time. Are there logs that we can provide next time this happens? I enabled trace logging and looked in the Tasks output channel but did not see anything other than a warning about shell tasks being unavailable.
I will try to get to this in March, no logs are needed as we understand how this could happen
Original repro steps still work
Steps still work sometimes - saw this when I reproduced !
Alright, onto something - the consistent repro for me is when there's a multi-root workspace - with each repo contributing a default build task. the build task see quick pick with a bunch of tasks, not just the default build tasks When that's the case, yields none because none of the tasks have a property set yet and that is required for this predicate to be true So enters here and by that time, the group is defined ! and since there are multiple, this gets called
Then it enters and concatenates non-defaults to the defaults. I don't think we want to do that. !
the fix is to only get the defaults and show those. we don't care about the others here. !
Regression introduced by , but there's also the timing component as indicated above - the group isn't set when we expect it to be. Perhaps in the single repo case, the hasn't yet been set by the time , the second attempt, occurs
I think we should be awaiting before running the build command
Apparently this still happens
ok in OSS where I'm reproducing, it goes in here like I thought ! then there are no workspace tasks found ! so it goes here !
only the are used here !
so the issue is the aren't resolved in this case. it's not timing dependent - I can repro long after the window has opened. !
I think here should have a size 0 !
interesting - I wonder if this is the issue !
worked: ! failed: !
so I think what's happening is if I trigger the build task before folder open, the promise is set but the tasks for that folder aren't parsed. then we return that promise indefinitely. I think checking if the is is in order here and in that case, we want to update the workspace tasks instead of returning the promise
yep - I believe that works. ! So the repro is to run the build task before the folder opens.
Just reproduced twice. When I did, both times it said this:
still happens in the build I created with the latest fix. note that i don't see extensions getting activated in the status bar here at all I also don't see the workspace folder undefined message anymore, but still see that the tasks are unavailable in the current environment.
the moment I change the file, it starts to work. IE when this is called
While it's possible (extremely rare) that a user will still hit this if they run the build task before a particular execution context has been set, this fix will prevent that from reproducing. To verify, open VS code (typically a restart) and run the build task. If you do see the quickpick instead of the default build task getting, run, then the next time you run the build task, you should not see it. The above should be hard to reproduce though - and only possible if you time it just right. Before, this would happen more frequently and was reproducible until window reload.

return new Map(); } await this._waitForSupportedExecutions; <del> // The build task might be run before folder open. On folder open, we need to update the tasks so that // all tasks are parsed. #173384 if (runSource !== TaskRunSource.FolderOpen && this._workspaceTasksPromise) { </del> <ins> await this._whenTaskSystemReady; if (this._workspaceTasksPromise) { </ins> return this._workspaceTasksPromise; } return this._updateWorkspaceTasks(runSource);


Question:
Install Java extension pack Open VS Code repo Cmd+Shift+B Java extension prompts error and the task detection never finishes
We have to wait for extensions to be registered before reading the tasks because of task contributions from extensions. I don't think we can change this. thoughts?
We could have a timeout per task provider. If a task provider doesn't provide tasks for 3 minutes after we ask for tasks then it's likely it will never provide tasks. That would let us show the tasks for all the other extensions except the slow one.
I just hit this again , in a VS Code instance that had been running for quite some time. Are there logs that we can provide next time this happens? I enabled trace logging and looked in the Tasks output channel but did not see anything other than a warning about shell tasks being unavailable.
I will try to get to this in March, no logs are needed as we understand how this could happen
Original repro steps still work
Steps still work sometimes - saw this when I reproduced !
Alright, onto something - the consistent repro for me is when there's a multi-root workspace - with each repo contributing a default build task. the build task see quick pick with a bunch of tasks, not just the default build tasks When that's the case, yields none because none of the tasks have a property set yet and that is required for this predicate to be true So enters here and by that time, the group is defined ! and since there are multiple, this gets called
Then it enters and concatenates non-defaults to the defaults. I don't think we want to do that. !
the fix is to only get the defaults and show those. we don't care about the others here. !
Regression introduced by , but there's also the timing component as indicated above - the group isn't set when we expect it to be. Perhaps in the single repo case, the hasn't yet been set by the time , the second attempt, occurs
I think we should be awaiting before running the build command
Apparently this still happens
ok in OSS where I'm reproducing, it goes in here like I thought ! then there are no workspace tasks found ! so it goes here !
only the are used here !
so the issue is the aren't resolved in this case. it's not timing dependent - I can repro long after the window has opened. !
I think here should have a size 0 !
interesting - I wonder if this is the issue !
worked: ! failed: !
so I think what's happening is if I trigger the build task before folder open, the promise is set but the tasks for that folder aren't parsed. then we return that promise indefinitely. I think checking if the is is in order here and in that case, we want to update the workspace tasks instead of returning the promise
yep - I believe that works. ! So the repro is to run the build task before the folder opens.
Just reproduced twice. When I did, both times it said this:
still happens in the build I created with the latest fix. note that i don't see extensions getting activated in the status bar here at all I also don't see the workspace folder undefined message anymore, but still see that the tasks are unavailable in the current environment.
the moment I change the file, it starts to work. IE when this is called
While it's possible (extremely rare) that a user will still hit this if they run the build task before a particular execution context has been set, this fix will prevent that from reproducing. To verify, open VS code (typically a restart) and run the build task. If you do see the quickpick instead of the default build task getting, run, then the next time you run the build task, you should not see it. The above should be hard to reproduce though - and only possible if you time it just right. Before, this would happen more frequently and was reproducible until window reload.

const processContext = ProcessExecutionSupportedContext.bindTo(this._contextKeyService); processContext.set(process && !isVirtual); } <ins> // update tasks so an incomplete list isn't returned when getWorkspaceTasks is called this._workspaceTasksPromise = undefined; </ins> this._onDidRegisterSupportedExecutions.fire(); }


Question:
Install Java extension pack Open VS Code repo Cmd+Shift+B Java extension prompts error and the task detection never finishes
We have to wait for extensions to be registered before reading the tasks because of task contributions from extensions. I don't think we can change this. thoughts?
We could have a timeout per task provider. If a task provider doesn't provide tasks for 3 minutes after we ask for tasks then it's likely it will never provide tasks. That would let us show the tasks for all the other extensions except the slow one.
I just hit this again , in a VS Code instance that had been running for quite some time. Are there logs that we can provide next time this happens? I enabled trace logging and looked in the Tasks output channel but did not see anything other than a warning about shell tasks being unavailable.
I will try to get to this in March, no logs are needed as we understand how this could happen
Original repro steps still work
Steps still work sometimes - saw this when I reproduced !
Alright, onto something - the consistent repro for me is when there's a multi-root workspace - with each repo contributing a default build task. the build task see quick pick with a bunch of tasks, not just the default build tasks When that's the case, yields none because none of the tasks have a property set yet and that is required for this predicate to be true So enters here and by that time, the group is defined ! and since there are multiple, this gets called
Then it enters and concatenates non-defaults to the defaults. I don't think we want to do that. !
the fix is to only get the defaults and show those. we don't care about the others here. !
Regression introduced by , but there's also the timing component as indicated above - the group isn't set when we expect it to be. Perhaps in the single repo case, the hasn't yet been set by the time , the second attempt, occurs
I think we should be awaiting before running the build command
Apparently this still happens
ok in OSS where I'm reproducing, it goes in here like I thought ! then there are no workspace tasks found ! so it goes here !
only the are used here !
so the issue is the aren't resolved in this case. it's not timing dependent - I can repro long after the window has opened. !
I think here should have a size 0 !
interesting - I wonder if this is the issue !
worked: ! failed: !
so I think what's happening is if I trigger the build task before folder open, the promise is set but the tasks for that folder aren't parsed. then we return that promise indefinitely. I think checking if the is is in order here and in that case, we want to update the workspace tasks instead of returning the promise
yep - I believe that works. ! So the repro is to run the build task before the folder opens.
Just reproduced twice. When I did, both times it said this:
still happens in the build I created with the latest fix. note that i don't see extensions getting activated in the status bar here at all I also don't see the workspace folder undefined message anymore, but still see that the tasks are unavailable in the current environment.
the moment I change the file, it starts to work. IE when this is called
While it's possible (extremely rare) that a user will still hit this if they run the build task before a particular execution context has been set, this fix will prevent that from reproducing. To verify, open VS code (typically a restart) and run the build task. If you do see the quickpick instead of the default build task getting, run, then the next time you run the build task, you should not see it. The above should be hard to reproduce though - and only possible if you time it just right. Before, this would happen more frequently and was reproducible until window reload.

this._tasksReconnected = true; return; } <del> this.getWorkspaceTasks().then(async () => { </del> <ins> this.getWorkspaceTasks(TaskRunSource.Reconnect).then(async () => { </ins> this._tasksReconnected = await this._reconnectTasks(); }); }


Question:
Install Java extension pack Open VS Code repo Cmd+Shift+B Java extension prompts error and the task detection never finishes
We have to wait for extensions to be registered before reading the tasks because of task contributions from extensions. I don't think we can change this. thoughts?
We could have a timeout per task provider. If a task provider doesn't provide tasks for 3 minutes after we ask for tasks then it's likely it will never provide tasks. That would let us show the tasks for all the other extensions except the slow one.
I just hit this again , in a VS Code instance that had been running for quite some time. Are there logs that we can provide next time this happens? I enabled trace logging and looked in the Tasks output channel but did not see anything other than a warning about shell tasks being unavailable.
I will try to get to this in March, no logs are needed as we understand how this could happen
Original repro steps still work
Steps still work sometimes - saw this when I reproduced !
Alright, onto something - the consistent repro for me is when there's a multi-root workspace - with each repo contributing a default build task. the build task see quick pick with a bunch of tasks, not just the default build tasks When that's the case, yields none because none of the tasks have a property set yet and that is required for this predicate to be true So enters here and by that time, the group is defined ! and since there are multiple, this gets called
Then it enters and concatenates non-defaults to the defaults. I don't think we want to do that. !
the fix is to only get the defaults and show those. we don't care about the others here. !
Regression introduced by , but there's also the timing component as indicated above - the group isn't set when we expect it to be. Perhaps in the single repo case, the hasn't yet been set by the time , the second attempt, occurs
I think we should be awaiting before running the build command
Apparently this still happens
ok in OSS where I'm reproducing, it goes in here like I thought ! then there are no workspace tasks found ! so it goes here !
only the are used here !
so the issue is the aren't resolved in this case. it's not timing dependent - I can repro long after the window has opened. !
I think here should have a size 0 !
interesting - I wonder if this is the issue !
worked: ! failed: !
so I think what's happening is if I trigger the build task before folder open, the promise is set but the tasks for that folder aren't parsed. then we return that promise indefinitely. I think checking if the is is in order here and in that case, we want to update the workspace tasks instead of returning the promise
yep - I believe that works. ! So the repro is to run the build task before the folder opens.
Just reproduced twice. When I did, both times it said this:
still happens in the build I created with the latest fix. note that i don't see extensions getting activated in the status bar here at all I also don't see the workspace folder undefined message anymore, but still see that the tasks are unavailable in the current environment.
the moment I change the file, it starts to work. IE when this is called
While it's possible (extremely rare) that a user will still hit this if they run the build task before a particular execution context has been set, this fix will prevent that from reproducing. To verify, open VS code (typically a restart) and run the build task. If you do see the quickpick instead of the default build task getting, run, then the next time you run the build task, you should not see it. The above should be hard to reproduce though - and only possible if you time it just right. Before, this would happen more frequently and was reproducible until window reload.

return { workspaceFolder, set: undefined, configurations: undefined, hasErrors: false }; } <del> private async _computeTasksForSingleConfig(workspaceFolder: IWorkspaceFolder | undefined, config: TaskConfig.IExternalTaskRunnerConfiguration | undefined, runSource: TaskRunSource, custom: CustomTask[], customized: IStringDictionary<ConfiguringTask>, source: TaskConfig.TaskConfigSource, isRecentTask: boolean = false): Promise<boolean> { if (!config || !workspaceFolder) { </del> <ins> private async _computeTasksForSingleConfig(workspaceFolder: IWorkspaceFolder, config: TaskConfig.IExternalTaskRunnerConfiguration | undefined, runSource: TaskRunSource, custom: CustomTask[], customized: IStringDictionary<ConfiguringTask>, source: TaskConfig.TaskConfigSource, isRecentTask: boolean = false): Promise<boolean> { if (!config) { </ins> return false; } <del> const taskSystemInfo: ITaskSystemInfo | undefined = workspaceFolder ? this._getTaskSystemInfo(workspaceFolder.uri.scheme) : undefined; </del> <ins> const taskSystemInfo: ITaskSystemInfo | undefined = this._getTaskSystemInfo(workspaceFolder.uri.scheme); </ins> const problemReporter = new ProblemReporter(this._outputChannel); if (!taskSystemInfo) { problemReporter.fatal(nls.localize('TaskSystem.workspaceFolderError', 'Workspace folder was undefined'));


Question:
Install Java extension pack Open VS Code repo Cmd+Shift+B Java extension prompts error and the task detection never finishes
We have to wait for extensions to be registered before reading the tasks because of task contributions from extensions. I don't think we can change this. thoughts?
We could have a timeout per task provider. If a task provider doesn't provide tasks for 3 minutes after we ask for tasks then it's likely it will never provide tasks. That would let us show the tasks for all the other extensions except the slow one.
I just hit this again , in a VS Code instance that had been running for quite some time. Are there logs that we can provide next time this happens? I enabled trace logging and looked in the Tasks output channel but did not see anything other than a warning about shell tasks being unavailable.
I will try to get to this in March, no logs are needed as we understand how this could happen
Original repro steps still work
Steps still work sometimes - saw this when I reproduced !
Alright, onto something - the consistent repro for me is when there's a multi-root workspace - with each repo contributing a default build task. the build task see quick pick with a bunch of tasks, not just the default build tasks When that's the case, yields none because none of the tasks have a property set yet and that is required for this predicate to be true So enters here and by that time, the group is defined ! and since there are multiple, this gets called
Then it enters and concatenates non-defaults to the defaults. I don't think we want to do that. !
the fix is to only get the defaults and show those. we don't care about the others here. !
Regression introduced by , but there's also the timing component as indicated above - the group isn't set when we expect it to be. Perhaps in the single repo case, the hasn't yet been set by the time , the second attempt, occurs
I think we should be awaiting before running the build command
Apparently this still happens
ok in OSS where I'm reproducing, it goes in here like I thought ! then there are no workspace tasks found ! so it goes here !
only the are used here !
so the issue is the aren't resolved in this case. it's not timing dependent - I can repro long after the window has opened. !
I think here should have a size 0 !
interesting - I wonder if this is the issue !
worked: ! failed: !
so I think what's happening is if I trigger the build task before folder open, the promise is set but the tasks for that folder aren't parsed. then we return that promise indefinitely. I think checking if the is is in order here and in that case, we want to update the workspace tasks instead of returning the promise
yep - I believe that works. ! So the repro is to run the build task before the folder opens.
Just reproduced twice. When I did, both times it said this:
still happens in the build I created with the latest fix. note that i don't see extensions getting activated in the status bar here at all I also don't see the workspace folder undefined message anymore, but still see that the tasks are unavailable in the current environment.
the moment I change the file, it starts to work. IE when this is called
While it's possible (extremely rare) that a user will still hit this if they run the build task before a particular execution context has been set, this fix will prevent that from reproducing. To verify, open VS code (typically a restart) and run the build task. If you do see the quickpick instead of the default build task getting, run, then the next time you run the build task, you should not see it. The above should be hard to reproduce though - and only possible if you time it just right. Before, this would happen more frequently and was reproducible until window reload.

return true; } <del> private async _ensureWorkspaceTasks(): Promise<void> { if (!this._workspaceTasksPromise) { await this.getWorkspaceTasks(); } else { await this._workspaceTasksPromise; } } </del> private async _runTaskCommand(filter?: string | ITaskIdentifier): Promise<void> { <del> await this._ensureWorkspaceTasks(); </del> if (!filter) { return this._doRunTaskCommand(); }


Question:
Install Java extension pack Open VS Code repo Cmd+Shift+B Java extension prompts error and the task detection never finishes
We have to wait for extensions to be registered before reading the tasks because of task contributions from extensions. I don't think we can change this. thoughts?
We could have a timeout per task provider. If a task provider doesn't provide tasks for 3 minutes after we ask for tasks then it's likely it will never provide tasks. That would let us show the tasks for all the other extensions except the slow one.
I just hit this again , in a VS Code instance that had been running for quite some time. Are there logs that we can provide next time this happens? I enabled trace logging and looked in the Tasks output channel but did not see anything other than a warning about shell tasks being unavailable.
I will try to get to this in March, no logs are needed as we understand how this could happen
Original repro steps still work
Steps still work sometimes - saw this when I reproduced !
Alright, onto something - the consistent repro for me is when there's a multi-root workspace - with each repo contributing a default build task. the build task see quick pick with a bunch of tasks, not just the default build tasks When that's the case, yields none because none of the tasks have a property set yet and that is required for this predicate to be true So enters here and by that time, the group is defined ! and since there are multiple, this gets called
Then it enters and concatenates non-defaults to the defaults. I don't think we want to do that. !
the fix is to only get the defaults and show those. we don't care about the others here. !
Regression introduced by , but there's also the timing component as indicated above - the group isn't set when we expect it to be. Perhaps in the single repo case, the hasn't yet been set by the time , the second attempt, occurs
I think we should be awaiting before running the build command
Apparently this still happens
ok in OSS where I'm reproducing, it goes in here like I thought ! then there are no workspace tasks found ! so it goes here !
only the are used here !
so the issue is the aren't resolved in this case. it's not timing dependent - I can repro long after the window has opened. !
I think here should have a size 0 !
interesting - I wonder if this is the issue !
worked: ! failed: !
so I think what's happening is if I trigger the build task before folder open, the promise is set but the tasks for that folder aren't parsed. then we return that promise indefinitely. I think checking if the is is in order here and in that case, we want to update the workspace tasks instead of returning the promise
yep - I believe that works. ! So the repro is to run the build task before the folder opens.
Just reproduced twice. When I did, both times it said this:
still happens in the build I created with the latest fix. note that i don't see extensions getting activated in the status bar here at all I also don't see the workspace folder undefined message anymore, but still see that the tasks are unavailable in the current environment.
the moment I change the file, it starts to work. IE when this is called
While it's possible (extremely rare) that a user will still hit this if they run the build task before a particular execution context has been set, this fix will prevent that from reproducing. To verify, open VS code (typically a restart) and run the build task. If you do see the quickpick instead of the default build task getting, run, then the next time you run the build task, you should not see it. The above should be hard to reproduce though - and only possible if you time it just right. Before, this would happen more frequently and was reproducible until window reload.

title: strings.fetching }; const promise = (async () => { <del> await this._ensureWorkspaceTasks(); </del> let taskGroupTasks: (Task | ConfiguringTask)[] = []; async function runSingleTask(task: Task | undefined, problemMatcherOptions: IProblemMatcherRunOptions | undefined, that: AbstractTaskService) {


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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.

// We only want to fire a telemetry if we haven't seen this account yet in this session. if (!this._accountsSeen.has(session.account.id)) { this._accountsSeen.add(session.account.id); <del> this._githubServer.sendAdditionalTelemetryInfo(session.accessToken); </del> <ins> this._githubServer.sendAdditionalTelemetryInfo(session); </ins> } }


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.

export interface IGitHubServer { login(scopes: string): Promise<string>; getUserInfo(token: string): Promise<{ id: string; accountName: string }>; <del> sendAdditionalTelemetryInfo(token: string): Promise<void>; </del> <ins> sendAdditionalTelemetryInfo(session: vscode.AuthenticationSession): Promise<void>; </ins> friendlyName: string; }


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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.

const result = await fetching(serverUri.toString(), { headers: { Authorization: `token ${token}`, <del> 'User-Agent': 'Visual-Studio-Code' </del> <ins> 'User-Agent': `${vscode.env.appName} (${vscode.env.appHost})` </ins> } });


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.

result = await fetching(this.getServerUri('/user').toString(), { headers: { Authorization: `token ${token}`, <del> 'User-Agent': 'Visual-Studio-Code' </del> <ins> 'User-Agent': `${vscode.env.appName} (${vscode.env.appHost})` </ins> } }); } catch (ex) {


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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.

} } <del> public async sendAdditionalTelemetryInfo(token: string): Promise<void> { </del> <ins> public async sendAdditionalTelemetryInfo(session: vscode.AuthenticationSession): Promise<void> { </ins> if (!vscode.env.isTelemetryEnabled) { return; }


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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.

} if (this._type === AuthProviderType.github) { <del> return await this.checkUserDetails(token); </del> <ins> return await this.checkUserDetails(session); </ins> } // GHES <del> await this.checkEnterpriseVersion(token); </del> <ins> await this.checkEnterpriseVersion(session.accessToken); </ins> } <del> private async checkUserDetails(token: string): Promise<void> { </del> <ins> private async checkUserDetails(session: vscode.AuthenticationSession): Promise<void> { </ins> let edu: string | undefined; try { const result = await fetching('https://education.github.com/api/user', { headers: { <del> Authorization: `token ${token}`, </del> <ins> Authorization: `token ${session.accessToken}`, </ins> 'faculty-check-preview': 'true', <del> 'User-Agent': 'Visual-Studio-Code' </del> <ins> 'User-Agent': `${vscode.env.appName} (${vscode.env.appHost})` </ins> } });


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.

: json.faculty ? 'faculty' : 'none'; <ins> } else { edu = 'unknown'; </ins> } } catch (e) { <del> // No-op } let managed: string | undefined; try { const user = await this.getUserInfo(token); // Apparently, this is how you tell if a user is an EMU... managed = user.accountName.includes('_') ? 'true' : 'false'; } catch (e) { // No-op } if (edu === undefined && managed === undefined) { return; </del> <ins> edu = 'unknown'; </ins> } /* __GDPR__


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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.

} */ this._telemetryReporter.sendTelemetryEvent('session', { <del> isEdu: edu ?? 'unknown', isManaged: managed ?? 'unknown' </del> <ins> isEdu: edu, // Apparently, this is how you tell if a user is an EMU... isManaged: session.account.label.includes('_') ? 'true' : 'false' </ins> }); }


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.

const result = await fetching(this.getServerUri('/meta').toString(), { headers: { Authorization: `token ${token}`, <del> 'User-Agent': 'Visual-Studio-Code' </del> <ins> 'User-Agent': `${vscode.env.appName} (${vscode.env.appHost})` </ins> } });


Question:
I try to add a keybinding with ${selectedText}. but it will resloved as a normal string. Steps to Reproduce: ! Version: 1.75.0 (user setup) Commit: OS: Windows_NT x64 10.0. Sandboxed: No
would you happen to know why the variable isn't resolving to a value here? Is there something that the command must contain to resolve variables?
The decision for whether variables should be resolved in a command needs to be made on a per command bases. If you want, you can run your commands arguments through the variable resolve when your command is called. For example, the terminal uses the variable resolver here:
From It would be great if more variable resolution was achieved in keybindings - I think it has been requested many times.
verif steps: a keybinding for : that the keybinding correctly sets to the current path.

import { ExplorerViewPaneContainer } from 'vs/workbench/contrib/files/browser/explorerViewlet'; import { onUnexpectedError } from 'vs/base/common/errors'; import { category, getElementsToOperateOn, getSearchView, openSearchView } from 'vs/workbench/contrib/search/browser/searchActionsBase'; <ins> import { withNullAsUndefined } from 'vs/base/common/types'; import { IConfigurationResolverService } from 'vs/workbench/services/configurationResolver/common/configurationResolver'; import { IHistoryService } from 'vs/workbench/services/history/common/history'; import { Schemas } from 'vs/base/common/network'; </ins> //#region Interfaces


Question:
I try to add a keybinding with ${selectedText}. but it will resloved as a normal string. Steps to Reproduce: ! Version: 1.75.0 (user setup) Commit: OS: Windows_NT x64 10.0. Sandboxed: No
would you happen to know why the variable isn't resolving to a value here? Is there something that the command must contain to resolve variables?
The decision for whether variables should be resolved in a command needs to be made on a per command bases. If you want, you can run your commands arguments through the variable resolve when your command is called. For example, the terminal uses the variable resolver here:
From It would be great if more variable resolution was achieved in keybindings - I think it has been requested many times.
verif steps: a keybinding for : that the keybinding correctly sets to the current path.

.filter((renderableMatch): renderableMatch is URI => (renderableMatch !== null)); } <del> export function findInFilesCommand(accessor: ServicesAccessor, args: IFindInFilesArgs = {}) { </del> <ins> export async function findInFilesCommand(accessor: ServicesAccessor, _args: IFindInFilesArgs = {}) { </ins> const searchConfig = accessor.get(IConfigurationService).getValue<ISearchConfiguration>().search; <ins> const viewsService = accessor.get(IViewsService); const args: IFindInFilesArgs = {}; if (Object.keys(_args).length !== 0) { // resolve variables in the same way as in // https://github.com/microsoft/vscode/blob/8b76efe9d317d50cb5b57a7658e09ce6ebffaf36/src/vs/workbench/contrib/searchEditor/browser/searchEditorActions.ts#L152-L158 const configurationResolverService = accessor.get(IConfigurationResolverService); const historyService = accessor.get(IHistoryService); const workspaceContextService = accessor.get(IWorkspaceContextService); const activeWorkspaceRootUri = historyService.getLastActiveWorkspaceRoot(Schemas.file); const lastActiveWorkspaceRoot = activeWorkspaceRootUri ? withNullAsUndefined(workspaceContextService.getWorkspaceFolder(activeWorkspaceRootUri)) : undefined; for (const entry of Object.entries(_args)) { const name = entry[0]; const value = entry[1]; if (value !== undefined) { (args as any)[name as any] = (typeof value === 'string') ? await configurationResolverService.resolveAsync(lastActiveWorkspaceRoot, value) : value; } } } </ins> const mode = searchConfig.mode; if (mode === 'view') { <del> const viewsService = accessor.get(IViewsService); </del> openSearchView(viewsService, false).then(openedView => { if (openedView) { const searchAndReplaceWidget = openedView.searchAndReplaceWidget;


Question:
This is a weird statement that seem to do nothing. I am creating this bug to accompany a PR to fix it. If there is an actual reason I am also happy to add a comment for it.
Thanks for the fix

// if it's clearing all outputs, or outputs are all rendered synchronously // shrink immediately as the final output height will be zero. // if it's rerun, then the output clearing might be temporary, so we don't shrink immediately <del> this._validateFinalOutputHeight(false || (context === CellOutputUpdateContext.Other && this.viewCell.outputsViewModels.length === 0)); </del> <ins> this._validateFinalOutputHeight(context === CellOutputUpdateContext.Other && this.viewCell.outputsViewModels.length === 0); </ins> } private _generateShowMoreElement(disposables: DisposableStore): HTMLElement {


Question:
an object that has many long property values There is no scrollbar the prototype There is a scrollbar !
Probably only with the horizontalscrolling setting enabled? I know that's a bit tricky
What's the setting for that? I don't have any scroll setting that appears debug related enabled. Just sticky scroll for the editor.
I think you have set, right?
No I do not.

import { CancellationToken, CancellationTokenSource } from 'vs/base/common/cancellation'; import { KeyCode } from 'vs/base/common/keyCodes'; import * as lifecycle from 'vs/base/common/lifecycle'; <ins> import { clamp } from 'vs/base/common/numbers'; </ins> import { isMacintosh } from 'vs/base/common/platform'; import { ScrollbarVisibility } from 'vs/base/common/scrollable'; import { ContentWidgetPositionPreference, ICodeEditor, IContentWidget, IContentWidgetPosition } from 'vs/editor/browser/editorBrowser'; import { ConfigurationChangedEvent, EditorOption } from 'vs/editor/common/config/editorOptions'; <ins> import { IDimension } from 'vs/editor/common/core/dimension'; </ins> import { Position } from 'vs/editor/common/core/position'; import { Range } from 'vs/editor/common/core/range'; import { ModelDecorationOptions } from 'vs/editor/common/model/textModel';


Question:
an object that has many long property values There is no scrollbar the prototype There is a scrollbar !
Probably only with the horizontalscrolling setting enabled? I know that's a bit tricky
What's the setting for that? I don't have any scroll setting that appears debug related enabled. Just sticky scroll for the editor.
I think you have set, right?
No I do not.

private scrollbar!: DomScrollableElement; private debugHoverComputer: DebugHoverComputer; <ins> private expressionToRender: IExpression | undefined; private isUpdatingTree = false; </ins> constructor( private editor: ICodeEditor, @IDebugService private readonly debugService: IDebugService,


Question:
an object that has many long property values There is no scrollbar the prototype There is a scrollbar !
Probably only with the horizontalscrolling setting enabled? I know that's a bit tricky
What's the setting for that? I don't have any scroll setting that appears debug related enabled. Just sticky scroll for the editor.
I think you have set, right?
No I do not.

private create(): void { this.domNode = $('.debug-hover-widget'); this.complexValueContainer = dom.append(this.domNode, $('.complex-value')); <ins> this.complexValueContainer.style.visibility = 'hidden'; </ins> this.complexValueTitle = dom.append(this.complexValueContainer, $('.title')); this.treeContainer = dom.append(this.complexValueContainer, $('.debug-hover-tree')); this.treeContainer.setAttribute('role', 'tree');


Question:
an object that has many long property values There is no scrollbar the prototype There is a scrollbar !
Probably only with the horizontalscrolling setting enabled? I know that's a bit tricky
What's the setting for that? I don't have any scroll setting that appears debug related enabled. Just sticky scroll for the editor.
I think you have set, right?
No I do not.

this.domNode.style.border = `1px solid ${asCssVariable(editorHoverBorder)}`; this.domNode.style.color = asCssVariable(editorHoverForeground); <del> this.toDispose.push(this.tree.onDidChangeContentHeight(() => this.layoutTreeAndContainer(false))); </del> <ins> this.toDispose.push(this.tree.onDidChangeContentHeight(() => { if (!this.isUpdatingTree) { // Don't do a layout in the middle of the async setInput this.layoutTreeAndContainer(); } })); </ins> this.registerListeners(); this.editor.addContentWidget(this);


Question:
an object that has many long property values There is no scrollbar the prototype There is a scrollbar !
Probably only with the horizontalscrolling setting enabled? I know that's a bit tricky
What's the setting for that? I don't have any scroll setting that appears debug related enabled. Just sticky scroll for the editor.
I think you have set, right?
No I do not.

this.valueContainer.hidden = true; <del> await this.tree.setInput(expression); </del> <ins> this.expressionToRender = expression; </ins> this.complexValueTitle.textContent = expression.value; this.complexValueTitle.title = expression.value; <del> this.layoutTreeAndContainer(true); </del> <ins> this.editor.layoutContentWidget(this); </ins> this.tree.scrollTop = 0; this.tree.scrollLeft = 0; this.complexValueContainer.hidden = false;


Question:
an object that has many long property values There is no scrollbar the prototype There is a scrollbar !
Probably only with the horizontalscrolling setting enabled? I know that's a bit tricky
What's the setting for that? I don't have any scroll setting that appears debug related enabled. Just sticky scroll for the editor.
I think you have set, right?
No I do not.

} } <del> private layoutTreeAndContainer(initialLayout: boolean): void { </del> <ins> private layoutTreeAndContainer(): void { this.layoutTree(); this.editor.layoutContentWidget(this); } private layoutTree(): void { </ins> const scrollBarHeight = 10; const treeHeight = Math.min(Math.max(266, this.editor.getLayoutInfo().height * 0.55), this.tree.contentHeight + scrollBarHeight); <ins> // Reset to a smaller width, if it was previously rendered wide this.tree.layout(treeHeight, 400); // const titleWidth = this.complexValueTitle.clientWidth; const realTreeWidth = this.tree.getHTMLElement().offsetWidth; // const contentWidth = Math.max(titleWidth, realTreeWidth); const treeWidth = clamp(realTreeWidth, 400, 550); this.tree.layout(treeHeight, treeWidth); </ins> this.treeContainer.style.height = `${treeHeight}px`; <del> this.tree.layout(treeHeight, initialLayout ? 400 : undefined); this.editor.layoutContentWidget(this); </del> this.scrollbar.scanDomNode(); } <ins> beforeRender(): IDimension | null { // beforeRender will be called each time the hover size changes, and the content widget is layed out again. if (this.expressionToRender) { const expression = this.expressionToRender; this.expressionToRender = undefined; // Do this in beforeRender once the content widget is no longer display=none so that its elements' sizes will be measured correctly. this.isUpdatingTree = true; this.tree.setInput(expression).then(() => { this.isUpdatingTree = false; dom.scheduleAtNextAnimationFrame(() => { // Wait for scrollWidth to update after a frame this.layoutTree(); this.editor.layoutContentWidget(this); this.complexValueContainer.style.visibility = ''; }); }); } return null; } </ins> afterRender(positionPreference: ContentWidgetPositionPreference | null) { if (positionPreference) { // Remember where the editor placed you to keep position stable #109226


Question:
an object that has many long property values There is no scrollbar the prototype There is a scrollbar !
Probably only with the horizontalscrolling setting enabled? I know that's a bit tricky
What's the setting for that? I don't have any scroll setting that appears debug related enabled. Just sticky scroll for the editor.
I think you have set, right?
No I do not.

hide(): void { <ins> this.complexValueContainer.style.visibility = 'hidden'; </ins> if (this.showCancellationSource) { this.showCancellationSource.cancel(); this.showCancellationSource = undefined;


Question:
Testing When I was on the section of the walkthrough I clicked on "open remote repository" and it had the dropdown. I noticed that I couldn't just click outside the dropdown (back on the welcome page) to make the dropdown disappear and instead had to use the "esc" button. From my experience with other dropdowns if you click away from the dropdown it disappears and think that behavior would make sense here.
does the quick pick come from ? If yes, who should I direct this issue to?
Yes that's where the quickpick comes from. owns the desktop git extension.
could you please help with this? Thanks.
Clicking outside of the dropdown still doesn't escape. !
It turns out that the "Remote Repositories" extension does not leverage the picker from the git-base extension so the fix that I made is not relevant. To verify this, please download the latest pre-release version of the "Remote Repositories" extension.

export async function pickRemoteSource(model: Model, options: PickRemoteSourceOptions & { branch: true }): Promise<PickRemoteSourceResult | undefined>; export async function pickRemoteSource(model: Model, options: PickRemoteSourceOptions = {}): Promise<string | PickRemoteSourceResult | undefined> { const quickpick = window.createQuickPick<(QuickPickItem & { provider?: RemoteSourceProvider; url?: string })>(); <del> quickpick.ignoreFocusOut = true; </del> quickpick.title = options.title; if (options.providerName) {


Question: With `"editor.wordWrap": "on"`, the color hints (inline color decorators) may be double-displayed near the wrapped view edges. ---- Version: 1.75.1 Commit: User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/ Firefox/111.0 Embedder:

if (options.inlineClassName) { const offset = (outputLineIndex > 0 ? lineBreakData.wrappedTextIndentLength : 0); const start = offset + Math.max(injectedTextStartOffsetInInputWithInjections - lineStartOffsetInInputWithInjections, 0); <del> const end = offset + Math.min(injectedTextEndOffsetInInputWithInjections - lineStartOffsetInInputWithInjections, lineEndOffsetInInputWithInjections); </del> <ins> const end = offset + Math.min(injectedTextEndOffsetInInputWithInjections - lineStartOffsetInInputWithInjections, lineEndOffsetInInputWithInjections - lineStartOffsetInInputWithInjections); </ins> if (start !== end) { inlineDecorations.push(new SingleLineInlineDecoration(start, end, options.inlineClassName, options.inlineClassNameAffectsLetterSpacing!)); }


Question: With `"editor.wordWrap": "on"`, the color hints (inline color decorators) may be double-displayed near the wrapped view edges. ---- Version: 1.75.1 Commit: User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/ Firefox/111.0 Embedder:

})), [ { inlineDecorations: [{ startOffset: 8, endOffset: 23 }] }, <del> { inlineDecorations: [{ startOffset: 4, endOffset: 42 }] }, </del> <ins> { inlineDecorations: [{ startOffset: 4, endOffset: 30 }] }, </ins> { inlineDecorations: [{ startOffset: 4, endOffset: 16 }] }, { inlineDecorations: undefined }, { inlineDecorations: undefined },


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.76.0 OS Version: Windows 10 The most recent VS Code update broke bracket colorization for PHP files, when you close a PHP tag then open it again before using a closing bracket. Steps to Reproduce: a PHP file a PHP open tag , open a bracket with , use an end tag , step 2, but with a closed bracket show as red, and the coloured line that joins the brackets doesn't show. Note: The red brackets are normally only used for errors, so it makes it look like there's errors in the file Screenshot: !
Same problem here on Unbutu! Could you fix it please?
Same error on ubuntu Ubuntu 22.04.2 LTS
Also happens if you just have the opening tag but no closing tag at the end: !
Hello, thank you to open this topic. I have the same issue while writing PHP code on VSC. It would be great if could be fixed. Have a nice day !!
Same issue here on Mac OS 13.2.1
Same here
For anyone who needs this fix before the next update: Add this to your settings JSON (fix via PR )
I have a similar issue using math equations in markdown, the image on the left is version 1.76 and the one on the right is 1.75.1, both of them with the same settings (by sharing them). The fix suggested by did not resolve my problem. Should I open a new issue since it is a different language and context? !
Possibly related on Stack Overflow:
Related: :
Same issue with me
You should scope it to language, otherwise the bracket setting applys to all languages
The update and modified settings as suggested by didn't solve the issue I mentioned in . Might be related to . Below is the today's insiders version w/o any extensions with the same issue despite even scoping the brackets as suggested by above. !
omh same here lol..

}, "brackets": [ ["<!--", "-->"], <del> ["<", ">"], </del> ["{", "}"], ["(", ")"] ],


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.76.0 OS Version: Windows 10 The most recent VS Code update broke bracket colorization for PHP files, when you close a PHP tag then open it again before using a closing bracket. Steps to Reproduce: a PHP file a PHP open tag , open a bracket with , use an end tag , step 2, but with a closed bracket show as red, and the coloured line that joins the brackets doesn't show. Note: The red brackets are normally only used for errors, so it makes it look like there's errors in the file Screenshot: !
Same problem here on Unbutu! Could you fix it please?
Same error on ubuntu Ubuntu 22.04.2 LTS
Also happens if you just have the opening tag but no closing tag at the end: !
Hello, thank you to open this topic. I have the same issue while writing PHP code on VSC. It would be great if could be fixed. Have a nice day !!
Same issue here on Mac OS 13.2.1
Same here
For anyone who needs this fix before the next update: Add this to your settings JSON (fix via PR )
I have a similar issue using math equations in markdown, the image on the left is version 1.76 and the one on the right is 1.75.1, both of them with the same settings (by sharing them). The fix suggested by did not resolve my problem. Should I open a new issue since it is a different language and context? !
Possibly related on Stack Overflow:
Related: :
Same issue with me
You should scope it to language, otherwise the bracket setting applys to all languages
The update and modified settings as suggested by didn't solve the issue I mentioned in . Might be related to . Below is the today's insiders version w/o any extensions with the same issue despite even scoping the brackets as suggested by above. !
omh same here lol..


Question:
On Windows: clone open workspace look at the workspace settings: all files are associated with schema . Note that this is a relative path to the workspace file open both files and check that code completion gives back property . You can also click on the JSON language selector ( next to JSON in the status bar) to see the schema that is associated :bug: No code code completion or schema association
76 candidate PR:

"@vscode/l10n": "^0.0.11", "jsonc-parser": "^3.2.0", "request-light": "^0.7.0", <del> "vscode-json-languageservice": "^5.3.1", </del> <ins> "vscode-json-languageservice": "^5.3.2", </ins> "vscode-languageserver": "^8.1.0", "vscode-uri": "^3.0.7" },


Question:
On Windows: clone open workspace look at the workspace settings: all files are associated with schema . Note that this is a relative path to the workspace file open both files and check that code completion gives back property . You can also click on the JSON language selector ( next to JSON in the status bar) to see the schema that is associated :bug: No code code completion or schema association
76 candidate PR:

resolved "https://registry.yarnpkg.com/request-light/-/request-light-0.7.0.tgz#885628bb2f8040c26401ebf258ec51c4ae98ac2a" integrity sha512-lMbBMrDoxgsyO+yB3sDcrDuX85yYt7sS8BfQd11jtbW/z5ZWgLZRcEGLsLoYw7I0WSUGQBs8CC8ScIxkTX1+6Q== <del> vscode-json-languageservice@^5.3.1: version "5.3.1" resolved "https://registry.yarnpkg.com/vscode-json-languageservice/-/vscode-json-languageservice-5.3.1.tgz#c36175d05f425fbd8f47dcee6f2a72096bdda36f" integrity sha512-tPRf/2LOBS6uFflFLABdj8T3ol2/QgZ0kpzZHFCs+cbxpnjBNiCo+rfh3th0dtdytq5dSnWo5iFJj99zF6jZWQ== </del> <ins> vscode-json-languageservice@^5.3.2: version "5.3.2" resolved "https://registry.yarnpkg.com/vscode-json-languageservice/-/vscode-json-languageservice-5.3.2.tgz#11e530ba9ec541eaeb421dc274a22efdb5d580ef" integrity sha512-5td6olfoNdtyxnNA4uocq7V9jdTJt63o9mGEntQb6cbD2HiObZW2XgbSj6nRaebWwBCiYdWpFklNjm6Wz6Xy1Q== </ins> dependencies: "@vscode/l10n" "^0.0.11" jsonc-parser "^3.2.0"


Question:
On Windows: clone open workspace look at the workspace settings: all files are associated with schema . Note that this is a relative path to the workspace file open both files and check that code completion gives back property . You can also click on the JSON language selector ( next to JSON in the status bar) to see the schema that is associated :bug: No code code completion or schema association
76 candidate PR:


Question:
On Windows: clone open workspace look at the workspace settings: all files are associated with schema . Note that this is a relative path to the workspace file open both files and check that code completion gives back property . You can also click on the JSON language selector ( next to JSON in the status bar) to see the schema that is associated :bug: No code code completion or schema association
76 candidate PR:


Question:
Type: <bBug</bContext changes causes images to flicker and, worse, quick picks to close. Run Open walkthrough Open step or Hit the button Quick pick closes right after clicking and image flashes. VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-08T05:22:25.379Z) OS version: Darwin x64 22.3.0 Modes: Sandboxed: Yes <!-- generated by issue reporter --
Seems as the context changes, which changes focus and closes the quick picks.
I can't repo this on OSS. But used the developer tools on insiders to debug it. fires the context changed event too many times which causes us to reload the media I removed rebuilding step if the step is already open which should fix the issue for the walkthroughs. But there is likely a larger issue to be fixed with the being fired too many times. You can turn off settings sync and try the steps described above - no repro.

} } <del> private async selectStep(id: string | undefined, delayFocus = true, forceRebuild = false) { if (id && this.editorInput.selectedStep === id && !forceRebuild) { return; } </del> <ins> private async selectStep(id: string | undefined, delayFocus = true) { if (id && this.editorInput.selectedStep === id) { return; } </ins> if (id) { let stepElement = this.container.querySelector<HTMLDivElement>(`[data-step-id="${id}"]`);


Question:
Type: <bBug</bContext changes causes images to flicker and, worse, quick picks to close. Run Open walkthrough Open step or Hit the button Quick pick closes right after clicking and image flashes. VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-08T05:22:25.379Z) OS version: Darwin x64 22.3.0 Modes: Sandboxed: Yes <!-- generated by issue reporter --
Seems as the context changes, which changes focus and closes the quick picks.
I can't repo this on OSS. But used the developer tools on insiders to debug it. fires the context changed event too many times which causes us to reload the media I removed rebuilding step if the step is already open which should fix the issue for the walkthroughs. But there is likely a larger issue to be fixed with the being fired too many times. You can turn off settings sync and try the steps described above - no repro.

if (event.keyCode === KeyCode.UpArrow) { const toExpand = category.steps.filter((step, index) => index < currentStepIndex() && this.contextService.contextMatchesRules(step.when)); if (toExpand.length) { <del> this.selectStep(toExpand[toExpand.length - 1].id, false, false); </del> <ins> this.selectStep(toExpand[toExpand.length - 1].id, false); </ins> } } if (event.keyCode === KeyCode.DownArrow) { const toExpand = category.steps.find((step, index) => index > currentStepIndex() && this.contextService.contextMatchesRules(step.when)); if (toExpand) { <del> this.selectStep(toExpand.id, false, false); </del> <ins> this.selectStep(toExpand.id, false); </ins> } } }));


Question:
Type: <bBug</bContext changes causes images to flicker and, worse, quick picks to close. Run Open walkthrough Open step or Hit the button Quick pick closes right after clicking and image flashes. VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-08T05:22:25.379Z) OS version: Darwin x64 22.3.0 Modes: Sandboxed: Yes <!-- generated by issue reporter --
Seems as the context changes, which changes focus and closes the quick picks.
I can't repo this on OSS. But used the developer tools on insiders to debug it. fires the context changed event too many times which causes us to reload the media I removed rebuilding step if the step is already open which should fix the issue for the walkthroughs. But there is likely a larger issue to be fixed with the being fired too many times. You can turn off settings sync and try the steps described above - no repro.

if (e.affectsSome(contextKeysToWatch)) { buildStepList(); this.registerDispatchListeners(); <del> this.selectStep(this.editorInput.selectedStep, false, true); </del> <ins> this.selectStep(this.editorInput.selectedStep, false); </ins> } }));


Question:
Type: <bBug</bContext changes causes images to flicker and, worse, quick picks to close. Run Open walkthrough Open step or Hit the button Quick pick closes right after clicking and image flashes. VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-08T05:22:25.379Z) OS version: Darwin x64 22.3.0 Modes: Sandboxed: Yes <!-- generated by issue reporter --
Seems as the context changes, which changes focus and closes the quick picks.
I can't repo this on OSS. But used the developer tools on insiders to debug it. fires the context changed event too many times which causes us to reload the media I removed rebuilding step if the step is already open which should fix the issue for the walkthroughs. But there is likely a larger issue to be fixed with the being fired too many times. You can turn off settings sync and try the steps described above - no repro.

reset(this.stepsContent, categoryDescriptorComponent, stepListComponent, this.stepMediaComponent, categoryFooter); const toExpand = category.steps.find(step => this.contextService.contextMatchesRules(step.when) && !step.done) ?? category.steps[0]; <del> this.selectStep(selectedStep ?? toExpand.id, !selectedStep, true); </del> <ins> this.selectStep(selectedStep ?? toExpand.id, !selectedStep); </ins> this.detailsScrollbar.scanDomNode(); this.detailsPageScrollbar?.scanDomNode();


Question:
Version : 1.76.1 Commit : Date : 2023-03-08T16:32:15.546Z Navigateur : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.4985.0 Safari/537.36 Edg/102.0.1235.1 with the extension installed (stable) switch the display language to French, reload VS Code switch the display language to English, reload VS Code open the remote menu, see that there's still a French menu entry in there ! Open the extension view ! I also see it the other way around: !
Ahhh so it looks like this is returning remote-repositories extension: with the old german manifest. What’s odd to me is that remote-repositories is being returned by and ... but even still, I don't know much about this code, but I would expect that the cache would cache the manifest in its raw form with the placeholders and then allow the runtime to translate the manifest (which could be optimized to cache both raw and translated form and only re-compute when language changes)
I'm giving this one to you since it seems like a issue from the caching changes.
It seems we are translating the manifest always even if it is cached. But, I observed that some how (I do not know, may be in the old code), cache is having the already translated manifest. Therefore, while translating nothing gets translated. We do update cache every time but it seems if the version has not changed, we reuse the entry from the cache. There is no reason we have to reuse the entry from the cache. So fixed it by recomputing the cache entry always while updating the cache.

if (!this._updateCustomBuiltinExtensionsCachePromise) { this._updateCustomBuiltinExtensionsCachePromise = (async () => { this.logService.info('Updating additional builtin extensions cache'); <del> const cached = await this.getCustomBuiltinExtensionsFromCache(); </del> const webExtensions: IWebExtension[] = []; const { extensions } = await this.readCustomBuiltinExtensionsInfoFromEnv(); if (extensions.length) {


Question:
Version : 1.76.1 Commit : Date : 2023-03-08T16:32:15.546Z Navigateur : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.4985.0 Safari/537.36 Edg/102.0.1235.1 with the extension installed (stable) switch the display language to French, reload VS Code switch the display language to English, reload VS Code open the remote menu, see that there's still a French menu entry in there ! Open the extension view ! I also see it the other way around: !
Ahhh so it looks like this is returning remote-repositories extension: with the old german manifest. What’s odd to me is that remote-repositories is being returned by and ... but even still, I don't know much about this code, but I would expect that the cache would cache the manifest in its raw form with the placeholders and then allow the runtime to translate the manifest (which could be optimized to cache both raw and translated form and only re-compute when language changes)
I'm giving this one to you since it seems like a issue from the caching changes.
It seems we are translating the manifest always even if it is cached. But, I observed that some how (I do not know, may be in the old code), cache is having the already translated manifest. Therefore, while translating nothing gets translated. We do update cache every time but it seems if the version has not changed, we reuse the entry from the cache. There is no reason we have to reuse the entry from the cache. So fixed it by recomputing the cache entry always while updating the cache.

} await Promise.all([...galleryExtensionsMap.values()].map(async gallery => { try { <del> const webExtension = cached.find(e => areSameExtensions(e.identifier, gallery.identifier) && e.version === gallery.version) ?? await this.toWebExtensionFromGallery(gallery, { isPreReleaseVersion: gallery.properties.isPreReleaseVersion, preRelease: gallery.properties.isPreReleaseVersion, isBuiltin: true }); </del> <ins> const webExtension = await this.toWebExtensionFromGallery(gallery, { isPreReleaseVersion: gallery.properties.isPreReleaseVersion, preRelease: gallery.properties.isPreReleaseVersion, isBuiltin: true }); </ins> webExtensions.push(webExtension); } catch (error) { this.logService.info(`Ignoring additional builtin extension ${gallery.identifier.id} because there is an error while converting it into web extension`, getErrorMessage(error));


Question:
Type: <bBug</bWhen working in a CSS document, if I use the query, a pop-up occurs stating: I have not noticed any negative impact besides the pop-up obscuring terminal menu. When looking at the output, the log states: VS Code version: Code 1.76.1 (, 2023-03-08T16:32:00.131Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ better-comments3.0.2 prettier-vscode9.10.4 gml-support1.7.4 vscode-language-babel0.0.37 git-graph1.30.0 powershell2023.2.1 vsliveshare1.0.5834 vscode-css-variables-autocomplete0.3.1 LiveServer5.7.9 code-spell-checker2.19.0 vscode-icons12.2.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Type: Bug same probleme, working in a CSS document, using query, a pop-up occurs stating: VS Code Version: 1.76.1 (Universal) (, 2023-03-08T16:32:00.131Z) OS version: MacOs Monterey 12.6.3 (21G419) Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin x64 21.6.0 Sandboxed: No
A similar error seem to be happening when writing in a .scss file. Writing or pasting makes the error popup appear, but a does not. To be a little clearer, here's a list of patterns with that can be pasted in a .scss file to trigger the error : - ( there's a space here at the end) - - (note: does not trigger the error.)
Type: Bug same problem here, working in a CSS document, using query, a pop-up and related terminal occurs stating: Error: selectionRange must be contained in fullRange at Function.validate (/Users/james/Desktop/Visual Studio ) at new t (/Users/james/Desktop/Visual Studio ) at V (/Users/james/Desktop/Visual Studio ) at c (/Users/james/Desktop/Visual Studio ) at (/Users/james/Desktop/Visual Studio ) at Object.asDocumentSymbols (/Users/james/Desktop/Visual Studio ) at i (/Users/james/Desktop/Visual Studio ) at n.provideDocumentSymbols (/Users/james/Desktop/Visual Studio ) <img width="1231" alt="스크린샷 2023-03-26 오전 10 32 42" src="https://user-"
Mismo problema, esperar alguna actualización para que lo corrijan? ! !
I'm having the same issue.
I'm confused. It says this was fixed but I'm still having the same issue. Nothing i've clicked on in this page is telling me how to fix it and use
I will be in the next insider build
Same issue
Same issue
As mentioned, the fix is in 1.78. If you still see this, please add the build you are on and a small code sample to reproduce.

MonacoEditorSchemas['http://opentools.azurewebsites.net/jsconfig'] = { 'title': nls.localize('jsconfig.json.title', "JSON schema for the JavaScript configuration file"), 'type': 'object', <del> 'default': { 'compilerOptions': { 'target': 'ES5' } }, </del> <ins> 'default': { 'compilerOptions': { 'target': 'ES6' } }, </ins> 'properties': { 'compilerOptions': { 'type': 'object',


Question:
Type: <bBug</bWhen working in a CSS document, if I use the query, a pop-up occurs stating: I have not noticed any negative impact besides the pop-up obscuring terminal menu. When looking at the output, the log states: VS Code version: Code 1.76.1 (, 2023-03-08T16:32:00.131Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ better-comments3.0.2 prettier-vscode9.10.4 gml-support1.7.4 vscode-language-babel0.0.37 git-graph1.30.0 powershell2023.2.1 vsliveshare1.0.5834 vscode-css-variables-autocomplete0.3.1 LiveServer5.7.9 code-spell-checker2.19.0 vscode-icons12.2.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Type: Bug same probleme, working in a CSS document, using query, a pop-up occurs stating: VS Code Version: 1.76.1 (Universal) (, 2023-03-08T16:32:00.131Z) OS version: MacOs Monterey 12.6.3 (21G419) Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin x64 21.6.0 Sandboxed: No
A similar error seem to be happening when writing in a .scss file. Writing or pasting makes the error popup appear, but a does not. To be a little clearer, here's a list of patterns with that can be pasted in a .scss file to trigger the error : - ( there's a space here at the end) - - (note: does not trigger the error.)
Type: Bug same problem here, working in a CSS document, using query, a pop-up and related terminal occurs stating: Error: selectionRange must be contained in fullRange at Function.validate (/Users/james/Desktop/Visual Studio ) at new t (/Users/james/Desktop/Visual Studio ) at V (/Users/james/Desktop/Visual Studio ) at c (/Users/james/Desktop/Visual Studio ) at (/Users/james/Desktop/Visual Studio ) at Object.asDocumentSymbols (/Users/james/Desktop/Visual Studio ) at i (/Users/james/Desktop/Visual Studio ) at n.provideDocumentSymbols (/Users/james/Desktop/Visual Studio ) <img width="1231" alt="스크린샷 2023-03-26 오전 10 32 42" src="https://user-"
Mismo problema, esperar alguna actualización para que lo corrijan? ! !
I'm having the same issue.
I'm confused. It says this was fixed but I'm still having the same issue. Nothing i've clicked on in this page is telling me how to fix it and use
I will be in the next insider build
Same issue
Same issue
As mentioned, the fix is in 1.78. If you still see this, please add the build you are on and a small code sample to reproduce.

this._compilerOptions = options || ts.getDefaultCompilerOptions(); this._compilerOptions.allowNonTsExtensions = true; // because of JS* and mirror model we need this this._compilerOptions.module = ts.ModuleKind.CommonJS; // because of JS* <ins> this._compilerOptions.target = options && options.target !== undefined ? options.target : ts.ScriptTarget.Latest; // because of JS* </ins> } getCompilationSettings(): ts.CompilerOptions {


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.76.1 OS Version: macOS 13.2.1 (22D68) an that uses a schema other than or . For example, : text renders as a hyperlink (dotted underline), but isn't cmd/ctrl+clickable like other like OSC 8 hyperlinks with the / scheme. Other OSC 8-capable terminals (like ) will open the link correctly. Here's a video demonstrating the issue with several other URL schemes: https://user- As you can see, only and URL schemes result in clickable links. If I remember correctly, this regressed in the 1.74 -1.75 update, which leads me to believe it might be related the introduced in that version. This functionality can be super useful for tools like , which let you add hyperlinks to line numbers in diffs. When this functionality worked in VS Code 1.74, those links would be clickable: !
Since everything supported this, I relied on it, damn. Would be amazing to have this back. Only non-heuristic way to get clickable file links in the terminal that handle all paths (e.g. paths with spaces)
We currently do not allow non-http(s) links due to allowNonHttpProtocols here: This may just be a case of adding that property to , but we need to make sure it won't introduce a security issue.
Hm, running code in a terminal generally means one trusts it. After all at this point it has access to a lot of things. Displaying data from untrusted sources without stripping ANSI escapes is more a problem of the tool displaying the data. I think when a terminal link is hovered, VS Code should just show a little link target floaty thing that shows where the link points to. Other terminal emulators do that. If you’re being paranoid, show a little when a link label looks like an URI but the corresponding link points to another URI. But that’s a situation people have in the web all the time, so they should know it can happen.
sure, but you can some file and it will evaluate sequences which is a common attack vector. The user is typically unaware that could result in execution and/or malicious links being inserted. The hover is probably sufficient, I would want to double check with someone on the team who has done some general URI handling when looking at the PR.
I understand the reasoning for disabling this, as VS Code focuses pretty strongly on security given its popularity (workspace trust, confirmations when opening links, well-defined extension API), but would it be possible to allow non-HTTP hyperlinks in the terminal via a setting? Something like ? It seems like implementing this would be a simple pass-through to 's property on (which you previously linked to). The setting could even have a security warning in its description. It'd be really nice to have this functionality back.
Who needs to sign off on a decision here? This is affecting me pretty much daily (since my testing framework uses this and I simply can’t make VS Code behave)
If would be nice to support at least links, so that one could open files within VS Code, by clicking on a link in a terminal.
+1, our framework uses OSC 8 links as one of the exclusive features vs competitors. Missing support in VS Code makes it irrelevant and degrades our productivity.
Easy testing below, only the first 2 work: Note that we wouldn't be able to support any arbitrary link without additional work as there are security concerns.
bash should work
yeah the file needs to exist for it to work
are you connected to the window via the Remote - WSL extension? If not this is as expected currently.
created to track your 1. For 2 right now proper WSL link support only works within Remote - WSL windows, so making this work well in local windows would be a new feature request.

WindowsEnableConpty = 'terminal.integrated.windowsEnableConpty', WordSeparators = 'terminal.integrated.wordSeparators', EnableFileLinks = 'terminal.integrated.enableFileLinks', <ins> AllowedLinkSchemes = 'terminal.integrated.allowedLinkSchemes', </ins> UnicodeVersion = 'terminal.integrated.unicodeVersion', LocalEchoLatencyThreshold = 'terminal.integrated.localEchoLatencyThreshold', LocalEchoEnabled = 'terminal.integrated.localEchoEnabled',


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.76.1 OS Version: macOS 13.2.1 (22D68) an that uses a schema other than or . For example, : text renders as a hyperlink (dotted underline), but isn't cmd/ctrl+clickable like other like OSC 8 hyperlinks with the / scheme. Other OSC 8-capable terminals (like ) will open the link correctly. Here's a video demonstrating the issue with several other URL schemes: https://user- As you can see, only and URL schemes result in clickable links. If I remember correctly, this regressed in the 1.74 -1.75 update, which leads me to believe it might be related the introduced in that version. This functionality can be super useful for tools like , which let you add hyperlinks to line numbers in diffs. When this functionality worked in VS Code 1.74, those links would be clickable: !
Since everything supported this, I relied on it, damn. Would be amazing to have this back. Only non-heuristic way to get clickable file links in the terminal that handle all paths (e.g. paths with spaces)
We currently do not allow non-http(s) links due to allowNonHttpProtocols here: This may just be a case of adding that property to , but we need to make sure it won't introduce a security issue.
Hm, running code in a terminal generally means one trusts it. After all at this point it has access to a lot of things. Displaying data from untrusted sources without stripping ANSI escapes is more a problem of the tool displaying the data. I think when a terminal link is hovered, VS Code should just show a little link target floaty thing that shows where the link points to. Other terminal emulators do that. If you’re being paranoid, show a little when a link label looks like an URI but the corresponding link points to another URI. But that’s a situation people have in the web all the time, so they should know it can happen.
sure, but you can some file and it will evaluate sequences which is a common attack vector. The user is typically unaware that could result in execution and/or malicious links being inserted. The hover is probably sufficient, I would want to double check with someone on the team who has done some general URI handling when looking at the PR.
I understand the reasoning for disabling this, as VS Code focuses pretty strongly on security given its popularity (workspace trust, confirmations when opening links, well-defined extension API), but would it be possible to allow non-HTTP hyperlinks in the terminal via a setting? Something like ? It seems like implementing this would be a simple pass-through to 's property on (which you previously linked to). The setting could even have a security warning in its description. It'd be really nice to have this functionality back.
Who needs to sign off on a decision here? This is affecting me pretty much daily (since my testing framework uses this and I simply can’t make VS Code behave)
If would be nice to support at least links, so that one could open files within VS Code, by clicking on a link in a terminal.
+1, our framework uses OSC 8 links as one of the exclusive features vs competitors. Missing support in VS Code makes it irrelevant and degrades our productivity.
Easy testing below, only the first 2 work: Note that we wouldn't be able to support any arbitrary link without additional work as there are security concerns.
bash should work
yeah the file needs to exist for it to work
are you connected to the window via the Remote - WSL extension? If not this is as expected currently.
created to track your 1. For 2 right now proper WSL link support only works within Remote - WSL windows, so making this work well in local windows would be a new feature request.

windowsEnableConpty: boolean; wordSeparators: string; enableFileLinks: 'off' | 'on' | 'notRemote'; <ins> allowedLinkSchemes: string[]; </ins> unicodeVersion: '6' | '11'; localEchoLatencyThreshold: number; localEchoExcludePrograms: ReadonlyArray<string>;