jiebi/CodeConvo huggingface dataset:
Code change:
private readonly _onDidStateChange: Emitter<ITaskEvent>; <ins> get taskShellIntegrationStartSequence(): string { return this._configurationService.getValue('task.showDecorations') ? VSCodeSequence(VSCodeOscPt.PromptStart) + VSCodeSequence(VSCodeOscPt.Property, `${VSCodeOscProperty.Task}=True`) + VSCodeSequence(VSCodeOscPt.CommandStart) : ''; } get taskShellIntegrationOutputSequence(): string { return this._configurationService.getValue('task.showDecorations') ? VSCodeSequence(VSCodeOscPt.CommandExecuted) : ''; } </ins> constructor( private _terminalService: ITerminalService, private _terminalGroupService: ITerminalGroupService,

Related discussion:
text: VS Code Version: insiders/from sources Task terminals don't respect setting so decorations cannot be disabled.
thanks for creating this issue. I remember noticing this then got distracted by some other issue
we're separating the task decorations from terminal decorations (shell integration), so will have a setting
Verified that works
Code change:
} })); this._sessionDisposables.add(this._editor.onDidChangeModelContent((e) => { <ins> cts?.cancel(); </ins> // update less aggressive when typing const delay = Math.max(scheduler.delay, 1250); scheduler.schedule(delay);

Related discussion:
text: Sometimes inlay hints are off for a short amount of time: ! It happens randomly and fixes itself quickly: ! I cannot reproduce it in isolation or in the monaco editor playground, but I see it very often when working in the VS Code repo. I think this is what happens: I type somewhere to trigger a delayed update I wait until the delay completes and the provider is asked I add new lines The provider comes back, but does not consider the edits in between The inlay hints are off I'm not sure if this is an issue of the inlay hints feature or typescripts implementation.
/duplicate of
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for . See also our . Happy Coding!
I still do think is buggy behavior and not a problem of delays. The initial screenshot should not be observed, regardless of delays. I'm not sure though if this is a typescript bug or inlay hint bug. And I can still reproduce it by doing random edits (took me some minutes though): !
this is still a duplicate of
Repro steps: Wait for 4 seconds, notice the inlay hint afer Press enter in line 1 Wait for 1 second Press enter in line 1 every 100 ms Notice that after 3 seconds there are invalid inline suggestions ! Validation: In the playground, click on "Compare with latest dev" Verify that there are no invalid inline suggestions after doing the steps again
Code change:
if (!language || !locale || locale === 'en' || locale.indexOf('en-') === 0) { return; } <del> if (language === locale || languagePackSuggestionIgnoreList.indexOf(language) > -1) { </del> <ins> if (language === locale || languagePackSuggestionIgnoreList.indexOf(locale) > -1) { </ins> return; }

Related discussion:
text: STR: VS Code with locale set for language prompt and close it VS Code and repeat 1st step Language prompt shows again. has logic for storing an ignore key after a prompt was shown, but is using the wrong key (language instead of locale). The same variable mixup has caused prior breakage of the feature.
Forwarding to since he owns localization.
I partly own localizations support in VS Code especially recommending. It seems you come up with a fix. Do you mind opening a PR?
Ignore above comment, I see the PR now.
I'm still seeing this in insiders I clicked the on the notification and then restarted. After a few seconds, the prompt came up again
Found it. Only "Don't show again" triggers that logic, but just canceling doesn't. I wonder what the right behavior should be. Other prompts also depend on "Don't show again" (using the option, ) for a similar logic and otherwise pop up again on next launch. cc for guidance.
Clicking is never meant to be not to show again and user has to explicitly select action. I think this is general behavior for all prompts. I would recommend to discuss this UX change separately and mark this as verified otherwise.
Marking as verified based on comments above
Code change:
return this.configurationService.getValue(LayoutSettings.ACTIVITY_BAR_LOCATION) !== ActivityBarPosition.HIDDEN; } <ins> private rememberActivityBarVisiblePosition(): void { const activityBarPosition = this.configurationService.getValue<string>(LayoutSettings.ACTIVITY_BAR_LOCATION); if (activityBarPosition !== ActivityBarPosition.HIDDEN) { this.storageService.store(LayoutSettings.ACTIVITY_BAR_LOCATION, activityBarPosition, StorageScope.PROFILE, StorageTarget.USER); } } private getRememberedActivityBarVisiblePosition(): ActivityBarPosition { const activityBarPosition = this.storageService.get(LayoutSettings.ACTIVITY_BAR_LOCATION, StorageScope.PROFILE); switch (activityBarPosition) { case ActivityBarPosition.SIDE: return ActivityBarPosition.SIDE; default: return ActivityBarPosition.TOP; } } </ins> private updateActivityBarVisiblity(): void { if (this.shouldShowActivityBar()) { this.acitivityBarPart.show();

Related discussion:
text: Steps to Reproduce: the Activity Bar Position as Hidden Command: View: Focus Activity Bar Then: ! Activity Bar still takes up screen space, but doesn't display the icons Version: 1.84.0 Commit: Date: 2023-11-01T11:29:04.398Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.84.0 Chrome/114.0.5735.289 Electron/25.9.2 Safari/537.36
Probably depends on
Probably
Not related to
!
Code change:
id: MenuId.NotebookCellTitle, when: NOTEBOOK_EDITOR_FOCUSED, group: CellOverflowToolbarGroups.Copy, <ins> order: 2, </ins> }, keybinding: platform.isNative ? undefined : { primary: KeyMod.CtrlCmd | KeyCode.KeyC,

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Steps to Reproduce: a ntoebook click on a cell, and notice the order of the cell actions same entries for regular editors is All places the order is We might want to consider changing this.
is this a papercut or ux issue I'm concerned that changing this now could result in issues due to muscle memory (i.e. users being used to this order). Thus changing this might not be a good idea, then again, i don't think it is. Thoughts?
discussed with team, Lets change this
Code change:
keybinding: { weight: KeybindingWeight.WorkbenchContrib, primary: KeyMod.CtrlCmd | KeyCode.DownArrow, <ins> when: CONTEXT_IN_CHAT_INPUT </ins> } }); }

Related discussion:
text: Testing Repro: /explain in inline chat to get a long response. using to focus the last response (does not work) to focus the last response using to scroll up in list view of chat messages. (does not work)
Same for panel chat. I believe the keybinding simply isn't bound
You may have to press it twice, once to move the cursor to the top of the editor, and then another time to trigger the chat keybinding, does that work? It's working fine for me.
Oh, not in inline chat though
I can't remember what terminal chat looked like in March, do you still want this disabled? I think we probably want it enabled in all chat widgets now:
I fixed this so that cmd+up/down will work in the terminal and inline chat widgets. But in the terminal, once the list is focused, then the arrow keys still navigate history. It looks like the terminal widget is registering a bunch of its own commands for history and for moving focus around. You shouldn't need to do that anymore, since you can use the commands that the ChatWidget has.
Code change:
stats?: IFileSearchProviderStats; } <ins> /** * For backwards compatibility, store both a cancellation token and a session object. The session object is the new implementation, where */ class SessionLifecycle extends Disposable { public readonly obj: object; public readonly tokenSource: CancellationTokenSource; constructor() { super(); this.obj = new Object(); this.tokenSource = new CancellationTokenSource(); } public override dispose(): void { this.tokenSource.cancel(); super.dispose(); } } </ins> export class FileSearchManager { private static readonly BATCH_SIZE = 512; <del> private readonly sessions = new Map<string, unknown>(); </del> <ins> private readonly sessions = new Map<string, SessionLifecycle>(); </ins> fileSearch(config: IFileQuery, provider: FileSearchProviderNew, onBatch: (matches: IFileMatch[]) => void, token: CancellationToken): Promise<ISearchCompleteStats> { const sessionTokenSource = this.getSessionTokenSource(config.cacheKey);

Related discussion:
text: a traditional . , listen for debugging the extension, open a file picker, then close it. session token's never gets triggered when the session is done (aka when the file picker is closed) :bug: This contradicts
regression from
Code change:
stats?: IFileSearchProviderStats; } <ins> /** * For backwards compatibility, store both a cancellation token and a session object. The session object is the new implementation, where */ class SessionLifecycle extends Disposable { public readonly obj: object; public readonly tokenSource: CancellationTokenSource; constructor() { super(); this.obj = new Object(); this.tokenSource = new CancellationTokenSource(); } public override dispose(): void { this.tokenSource.cancel(); super.dispose(); } } </ins> export class FileSearchManager { private static readonly BATCH_SIZE = 512; <del> private readonly sessions = new Map<string, unknown>(); </del> <ins> private readonly sessions = new Map<string, SessionLifecycle>(); </ins> fileSearch(config: IFileQuery, provider: FileSearchProviderNew, onBatch: (matches: IFileMatch[]) => void, token: CancellationToken): Promise<ISearchCompleteStats> { const sessionTokenSource = this.getSessionTokenSource(config.cacheKey);

Related discussion:
text: Testing The type cannot be used with because that requires objects (no primitives). We should accommodate for that and change the API accordingly.
Code change:
dependencies: object-keys "~0.4.0" <del> xterm-addon-canvas@0.4.0-beta.7: version "0.4.0-beta.7" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.4.0-beta.7.tgz#ae365d8e10c900292186529f70f7f275ac94b3d5" integrity sha512-r1hbQTsulI49orR5G3qWrJCwn2dKsEUCrgj6xsmgXuTeoUcGfed6lly+MvYlL3P8aPrxS2fC2TEzSM0Au4SX+w== </del> <ins> xterm-addon-canvas@0.4.0-beta.9: version "0.4.0-beta.9" resolved "https://registry.yarnpkg.com/xterm-addon-canvas/-/xterm-addon-canvas-0.4.0-beta.9.tgz#e570fa4592890f92cc86706f2bba0dd128a8641d" integrity sha512-BWRVWyUW7NY2g4BBMm3ecPQvbdyKXFgABnpmh4m0TVHqFJMNeXdNuTc94KiDbE+cvw8jtAY9NC/OIM4HcgjAIQ== </ins> xterm-addon-search@0.11.0: version "0.11.0"

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --With the above settings in effect and a terminal open in the bottom panel: If the terminal has focus, the cursor blinks If the terminal doesn't have focus, then the cursor remains visible without blinking Unlike the block-shaped cursor, which becomes hollow when the terminal loses focus, the line-shaped cursor doesn't change appearance when the terminal loses focus; it merely stops blinking. This makes it hard to tell at a glance whether the terminal has focus. So that it's easier to tell whether the terminal has focus, I would like an option to customize how the line-shaped cursor appears in the terminal when it doesn't have focus. Possible options (not exhaustive): Hide the cursor altogether Keep it visible, but make it (say) 50% opacity Show the same hollow block that's used with the block-shaped cursor
I actually thought it showed the hollow block in this case, I think that makes the most sense
try try
We're going back on the decision made in and making unfocused show the rectangle regardless of cursor style. Discussion:
Code change:
scope: scopeData.scopeStr, sessionId, account: { <del> label, </del> <ins> label: claims.email ?? claims.preferred_username ?? claims.unique_name ?? 'user@example.com', </ins> id, type: claims.tid === MSA_TID || claims.tid === MSA_PASSTHRU_TID ? MicrosoftAccountType.MSA : MicrosoftAccountType.AAD }

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: No. Related to extension api <!-- 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.79.0-insider OS Version: Macintosh; Intel Mac OS X 1340 Getting a session for a Microsoft account for the default tenant, and also getting a session for the account but for a specific tenant results in two items for the same account appearing in the Accounts menu. <img width="546" alt="image" src=""Steps to Reproduce: First call with the following scopes: . And another call to with these scopes: I want to point out that the account objects on the returned sessions are actually different: <br<details<summaryMicrosoft Authentication provider logs</summary<p</p</detailscc:
These accounts aren't duplicate, they are sessions that exist for each signed-in tenant. I think the best solution would be to change the account label to . This would match what the Azure portal does. <img width="201" alt="image" src=""I think this is an important change to make because this really doesn't look good and is confusing to users. Especially when users are trying to sign out. The screenshot below is after I sign in with a single Microsoft account that has 4 tenants. Having 4 tenants is not uncommon. <img width="515" alt="image" src=""
Yeah this goes back to that "technically they're different accounts because they're in different tenants" thing. I'm inclined to agree with you and dedupe per-label.
Although that would present better, I think deduping on the label wouldn't be great unless you made the label more standard across tenants.
Code change:
scope: scopeData.scopeStr, sessionId, account: { <del> label, </del> <ins> label: claims.email ?? claims.preferred_username ?? claims.unique_name ?? 'user@example.com', </ins> id, type: claims.tid === MSA_TID || claims.tid === MSA_PASSTHRU_TID ? MicrosoftAccountType.MSA : MicrosoftAccountType.AAD }

Related discussion:
text: In that case, I think changing the label to be just email would be best. Then all of these sessions in my example screenshot could be grouped as one. If you deduped per-label with the current labelling it would show two accounts, one that represents 3 tenants, and another representing another single tenant. That would still be pretty confusing. IMO there's two options: Dedupe by email and hide all tenant related stuff. Signing out of that account removes all sessions associated with that email, regardless of tenant. Don't dedupe at all, instead include the tenant display name in the label as .
says this works!
Code change:
console.error(`Playwright ERROR: HTTP status ${response.status()} for ${response.url()}`); } }); <ins> page.on('console', async msg => { try { consoleLogFn(msg)(msg.text(), await Promise.all(msg.args().map(async arg => await arg.jsonValue()))); } catch (err) { console.error('Error logging console', err); } }); page.on('requestfailed', e => { console.error('Request Failed', e.url(), e.failure()?.errorText); }); </ins> const host = endpoint.host; const protocol = 'vscode-remote';

Related discussion:
text: They used to finish in 3m24s before - […]-5f82-0dbc-&t=-371d-5daa-d7a2-
I can confirm that tests started timing out after this commit - The first commit that is started happening is Checking what commits in between would have caused it. FYI
Assigning to as one of his commits has caused this timeout.
Mac seems to be passing pretty reliably now but now windows fails consistently on two tests Been adding a bunch of logging to investigate this. Here's the relevant new error: The service worker should be intercepting this request so it should never be going to the network at all here. Taking a look to see if I can figure out what is going on
Actually it's not windows specific: its Firefox specific. The windows browser tests just happen to be the only ones using Firefox Can reproduce on Mac too
Code change:
return filename; } <del> // Trim whitespaces filename = strings.trim(strings.trim(filename, ' '), 't'); </del> <ins> // Trim tabs filename = strings.trim(filename, 't'); </ins> <del> // Remove trailing dots </del> <ins> // Remove trailing dots, slashes, and spaces </ins> filename = strings.rtrim(filename, '.'); <del> // Remove trailing slashes </del> <ins> filename = strings.rtrim(filename, ' '); </ins> filename = strings.rtrim(filename, '/'); filename = strings.rtrim(filename, '');

Related discussion:
text: <!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: OS Version: Steps to Reproduce: a new file with a name starting with a space (using MacOS Finder) to rename the file by removing the space at the beginning of the file name (using the VS Code explorer). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No
Confirmed on Windows too.. Edit: problem is . trims file names, but (in this case? in all cases?) should only remove trailing spaces.
Code change:
this._terminalCreationQueue = this._terminalCreationQueue.then(() => this._doCreateTerminal(task, group, launchConfigs!)); const terminal: ITerminalInstance = (await this._terminalCreationQueue)!; <del> terminal.shellLaunchConfig.reconnectionProperties = { ownerId: ReconnectionType, data: { lastTask: task.getCommonTaskId(), group, label: task._label, id: task._id } }; </del> <ins> if (task.configurationProperties.isBackground) { terminal.shellLaunchConfig.reconnectionProperties = { ownerId: ReconnectionType, data: { lastTask: task.getCommonTaskId(), group, label: task._label, id: task._id } }; } </ins> const terminalKey = terminal.instanceId.toString(); const terminalData = { terminal: terminal, lastTask: taskKey, group }; terminal.onDisposed(() => this._deleteTaskAndTerminal(terminal, terminalData));

Related discussion:
text: <!-- 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.77.3 OS Version: MacOS 13.3.1 Steps to Reproduce: Run the following commands Trust the workspace, then start the script from the "NPM Scripts" panel. The script runs, and the name of the script appears to the right of the output panel, together with a spinner showing that it's running. Now run the script again. A popup window appears saying that it's already running, and do you want to terminate or restart it (just close it without doing either). This is all expected behavior. Now (with the task running) run Cmd-Shift-P "Developer: Reload Window". The window reloads, and the script continues to run (you can tell it's the same script because it's printing its pid, and it doesn't change). The name is still in the right hand pane, but now the spinner has gone, as if vscode no longer knows that it's running. Now run the script again, and although it's already running, it starts a second copy. This is the bug. It's especially painful for "runOnOpen" tasks, because every time you reload the window (eg because an extension needs updating) they all continue to run AND a new copy of each one starts. I thought there might be another bug in the recently (since that was supposed to fix exactly this issue - ), and took a look at that.