Question:
Type: <bBug</bPreparation: create the following file: the terminals panel, create a new shell terminal it to the main editor area to make it a full-size terminal open an editor tab (any file will do, including Command-N) sure the panel is closed (press Command-J to close it if it is open) the above task (e.g. with Command-P, then type ) Expected: the panel opens and shows the running task Actual: the editor terminal is brought to the front, and the panel stays closed VS Code version: Code - Insiders 1.92.0-insider (, 2024-07-11T05:03:58.450Z) OS version: Darwin arm64 23.5.0 Modes: <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
In this scenario, focus also fails.
I can confirm that fixes the problem for me. Thanks!

this._onDidChangeActiveInstance.fire(this.activeInstance); } <ins> async focusInstance(instance: ITerminalInstance): Promise<void> { return instance.focusWhenReady(true); } </ins> async focusActiveInstance(): Promise<void> { return this.activeInstance?.focusWhenReady(true); }


Question:
Type: <bBug</bPreparation: create the following file: the terminals panel, create a new shell terminal it to the main editor area to make it a full-size terminal open an editor tab (any file will do, including Command-N) sure the panel is closed (press Command-J to close it if it is open) the above task (e.g. with Command-P, then type ) Expected: the panel opens and shows the running task Actual: the editor terminal is brought to the front, and the panel stays closed VS Code version: Code - Insiders 1.92.0-insider (, 2024-07-11T05:03:58.450Z) OS version: Darwin arm64 23.5.0 Modes: <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
In this scenario, focus also fails.
I can confirm that fixes the problem for me. Thanks!

pane?.terminalTabbedView?.focusHover(); } <ins> async focusInstance(_: ITerminalInstance): Promise<void> { return this.showPanel(true); } </ins> async focusActiveInstance(): Promise<void> { return this.showPanel(true); }


Question:
Type: <bBug</bPreparation: create the following file: the terminals panel, create a new shell terminal it to the main editor area to make it a full-size terminal open an editor tab (any file will do, including Command-N) sure the panel is closed (press Command-J to close it if it is open) the above task (e.g. with Command-P, then type ) Expected: the panel opens and shows the running task Actual: the editor terminal is brought to the front, and the panel stays closed VS Code version: Code - Insiders 1.92.0-insider (, 2024-07-11T05:03:58.450Z) OS version: Darwin arm64 23.5.0 Modes: <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
In this scenario, focus also fails.
I can confirm that fixes the problem for me. Thanks!

} } <ins> async focusInstance(instance: ITerminalInstance): Promise<void> { if (instance.target === TerminalLocation.Editor) { return this._terminalEditorService.focusInstance(instance); } return this._terminalGroupService.focusInstance(instance); } </ins> async focusActiveInstance(): Promise<void> { if (!this._activeInstance) { return; } <del> if (this._activeInstance.target === TerminalLocation.Editor) { return this._terminalEditorService.focusActiveInstance(); } return this._terminalGroupService.focusActiveInstance(); </del> <ins> return this.focusInstance(this._activeInstance); </ins> } async createContributedTerminalProfile(extensionIdentifier: string, id: string, options: ICreateContributedTerminalProfileOptions): Promise<void> {


Question:
Type: <bBug</bPreparation: create the following file: the terminals panel, create a new shell terminal it to the main editor area to make it a full-size terminal open an editor tab (any file will do, including Command-N) sure the panel is closed (press Command-J to close it if it is open) the above task (e.g. with Command-P, then type ) Expected: the panel opens and shows the running task Actual: the editor terminal is brought to the front, and the panel stays closed VS Code version: Code - Insiders 1.92.0-insider (, 2024-07-11T05:03:58.450Z) OS version: Darwin arm64 23.5.0 Modes: <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
In this scenario, focus also fails.
I can confirm that fixes the problem for me. Thanks!

return instance; } <ins> async revealTerminal(source: ITerminalInstance, preserveFocus?: boolean): Promise<void> { if (source.target === TerminalLocation.Editor) { await this._terminalEditorService.revealActiveEditor(preserveFocus); } else { await this._terminalGroupService.showPanel(); } } </ins> async revealActiveTerminal(preserveFocus?: boolean): Promise<void> { const instance = this.activeInstance; if (!instance) { return; } <del> if (instance.target === TerminalLocation.Editor) { await this._terminalEditorService.revealActiveEditor(preserveFocus); } else { await this._terminalGroupService.showPanel(); } </del> <ins> await this.revealTerminal(instance, preserveFocus); </ins> } setEditable(instance: ITerminalInstance, data?: IEditableData | null): void {


Question:
Type: <bBug</bPreparation: create the following file: the terminals panel, create a new shell terminal it to the main editor area to make it a full-size terminal open an editor tab (any file will do, including Command-N) sure the panel is closed (press Command-J to close it if it is open) the above task (e.g. with Command-P, then type ) Expected: the panel opens and shows the running task Actual: the editor terminal is brought to the front, and the panel stays closed VS Code version: Code - Insiders 1.92.0-insider (, 2024-07-11T05:03:58.450Z) OS version: Darwin arm64 23.5.0 Modes: <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
In this scenario, focus also fails.
I can confirm that fixes the problem for me. Thanks!

getInputFromResource(resource: URI): TerminalEditorInput { throw new Error('Method not implemented.'); } setActiveInstance(instance: ITerminalInstance): void { throw new Error('Method not implemented.'); } focusActiveInstance(): Promise<void> { throw new Error('Method not implemented.'); } <ins> focusInstance(instance: ITerminalInstance): void { throw new Error('Method not implemented.'); } </ins> getInstanceFromResource(resource: URI | undefined): ITerminalInstance | undefined { throw new Error('Method not implemented.'); } focusFindWidget(): void { throw new Error('Method not implemented.'); } hideFindWidget(): void { throw new Error('Method not implemented.'); }


Question:
Type: <bBug</bPreparation: create the following file: the terminals panel, create a new shell terminal it to the main editor area to make it a full-size terminal open an editor tab (any file will do, including Command-N) sure the panel is closed (press Command-J to close it if it is open) the above task (e.g. with Command-P, then type ) Expected: the panel opens and shows the running task Actual: the editor terminal is brought to the front, and the panel stays closed VS Code version: Code - Insiders 1.92.0-insider (, 2024-07-11T05:03:58.450Z) OS version: Darwin arm64 23.5.0 Modes: <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
In this scenario, focus also fails.
I can confirm that fixes the problem for me. Thanks!

focusHover(): void { throw new Error('Method not implemented.'); } setActiveInstance(instance: ITerminalInstance): void { throw new Error('Method not implemented.'); } focusActiveInstance(): Promise<void> { throw new Error('Method not implemented.'); } <ins> focusInstance(instance: ITerminalInstance): void { throw new Error('Method not implemented.'); } </ins> getInstanceFromResource(resource: URI | undefined): ITerminalInstance | undefined { throw new Error('Method not implemented.'); } focusFindWidget(): void { throw new Error('Method not implemented.'); } hideFindWidget(): void { throw new Error('Method not implemented.'); }


Question: Testing 1) select a cell 2) cmd+/ -cell commented 3) ESC 4) cmd+/ -nothing 5) arrow-up 6) Cmd+/ -nothing 7) Shift + arrow-up 8) Cmd+/ -two cells commented I don't really understand in which mode I'm in after step 3 and 5. I would expect Cmd+/ to work in those states.

// no parsed args, try handle active editor const editor = getEditorFromArgsOrActivePane(accessor); if (editor) { <ins> const selectedCellRange: ICellRange[] = editor.getSelections().length === 0 ? [editor.getFocus()] : editor.getSelections(); </ins> telemetryService.publicLog2<WorkbenchActionExecutedEvent, WorkbenchActionExecutedClassification>('workbenchActionExecuted', { id: this.desc.id, from: from }); return this.runWithContext(accessor, { ui: false, notebookEditor: editor, <del> selectedCells: cellRangeToViewCells(editor, editor.getSelections()) </del> <ins> selectedCells: cellRangeToViewCells(editor, selectedCellRange) </ins> }); } }


Question: Testing 1) select a cell 2) cmd+/ -cell commented 3) ESC 4) cmd+/ -nothing 5) arrow-up 6) Cmd+/ -nothing 7) Shift + arrow-up 8) Cmd+/ -two cells commented I don't really understand in which mode I'm in after step 3 and 5. I would expect Cmd+/ to work in those states.

keybinding: { when: ContextKeyExpr.and( NOTEBOOK_EDITOR_FOCUSED, <del> NOTEBOOK_CELL_LIST_FOCUSED, ContextKeyExpr.not(InputFocusedContextKey), </del> NOTEBOOK_EDITOR_EDITABLE, <del> NOTEBOOK_CELL_EDITABLE </del> <ins> ContextKeyExpr.not(InputFocusedContextKey), </ins> ), primary: KeyMod.CtrlCmd | KeyCode.Slash, weight: KeybindingWeight.WorkbenchContrib


Question: Testing 1) select a cell 2) cmd+/ -cell commented 3) ESC 4) cmd+/ -nothing 5) arrow-up 6) Cmd+/ -nothing 7) Shift + arrow-up 8) Cmd+/ -two cells commented I don't really understand in which mode I'm in after step 3 and 5. I would expect Cmd+/ to work in those states.

} }); selectedCellEditors.forEach(editor => { if (!editor.hasModel()) { return;


Question: Testing 1) select a cell 2) cmd+/ -cell commented 3) ESC 4) cmd+/ -nothing 5) arrow-up 6) Cmd+/ -nothing 7) Shift + arrow-up 8) Cmd+/ -two cells commented I don't really understand in which mode I'm in after step 3 and 5. I would expect Cmd+/ to work in those states.

const modelOptions = model.getOptions(); const commentsOptions = editor.getOption(EditorOption.comments); <ins> const selection = editor.getSelection(); </ins> commands.push(new LineCommentCommand( languageConfigurationService, new Selection(1, 1, model.getLineCount(), model.getLineMaxColumn(model.getLineCount())),


Question: Testing 1) select a cell 2) cmd+/ -cell commented 3) ESC 4) cmd+/ -nothing 5) arrow-up 6) Cmd+/ -nothing 7) Shift + arrow-up 8) Cmd+/ -two cells commented I don't really understand in which mode I'm in after step 3 and 5. I would expect Cmd+/ to work in those states.

editor.pushUndoStop(); editor.executeCommands(COMMENT_SELECTED_CELLS_ID, commands); editor.pushUndoStop(); <ins> editor.setSelection(selection); </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?: 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. --Version: 1.91.1 Commit: Date: 2024-07-09T22:06:49.809Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: a TreeView with an TreeItem the TreeItem's iconPath to the extension. The TreeItem's icon will still be yellow same as in debugging. After inspecting developer tools, this is likely due to how the icon debug-stackframe's color rule is set to !important. The ThemeColor fails to overwrite it due to low specificity. This may not only happen with the icon "debug-stackframe" and is affecting customisations of treeitems. Why is some icons' color rules given the !important flag et al? There might not be any easy fix due to this flag's present. I hope the team could look into it, and if possible fix this selector specificity issue (if it won't break vscode, somehow).
Edit: This not only occurs on special icons like debug-stackframe, but also on very ordinary ones like circle-filled. style attribute { color: rgb(204, 204, 204); } .monaco-workbench .codicon { } Adding !important to the color flag of .monaco-workbench .codicon will fix the issue though.. The problem is worse :C
I think the best solution would be to get rid of that . it's coming from here. Can it be removed? The css you shared is correct. The rbg value is the one you set in your ThemeIcon. !
Yea, we should scope these rules better (and also move them to css now that we have variables there)
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased

} registerThemingParticipant((theme, collector) => { <ins> const scope = '.monaco-editor .glyph-margin-widgets, .monaco-workbench .debug-breakpoints, .monaco-workbench .disassembly-view'; </ins> const debugIconBreakpointColor = theme.getColor(debugIconBreakpointForeground); if (debugIconBreakpointColor) { <del> collector.addRule(` ${icons.allBreakpoints.map(b => `.monaco-workbench ${ThemeIcon.asCSSSelector(b.regular)}`).join(',n		')}, .monaco-workbench ${ThemeIcon.asCSSSelector(icons.debugBreakpointUnsupported)}, .monaco-workbench ${ThemeIcon.asCSSSelector(icons.debugBreakpointHint)}:not([class*='codicon-debug-breakpoint']):not([class*='codicon-debug-stackframe']), .monaco-workbench ${ThemeIcon.asCSSSelector(icons.breakpoint.regular)}${ThemeIcon.asCSSSelector(icons.debugStackframeFocused)}::after, .monaco-workbench ${ThemeIcon.asCSSSelector(icons.breakpoint.regular)}${ThemeIcon.asCSSSelector(icons.debugStackframe)}::after { color: ${debugIconBreakpointColor} !important; } `); </del> <ins> collector.addRule(`${scope} { ${icons.allBreakpoints.map(b => `${ThemeIcon.asCSSSelector(b.regular)}`).join(',n		')}, ${ThemeIcon.asCSSSelector(icons.debugBreakpointUnsupported)}, ${ThemeIcon.asCSSSelector(icons.debugBreakpointHint)}:not([class*='codicon-debug-breakpoint']):not([class*='codicon-debug-stackframe']), ${ThemeIcon.asCSSSelector(icons.breakpoint.regular)}${ThemeIcon.asCSSSelector(icons.debugStackframeFocused)}::after, ${ThemeIcon.asCSSSelector(icons.breakpoint.regular)}${ThemeIcon.asCSSSelector(icons.debugStackframe)}::after { color: ${debugIconBreakpointColor} !important; } }`); </ins> <del> collector.addRule(` .monaco-workbench ${ThemeIcon.asCSSSelector(icons.breakpoint.pending)} { color: ${debugIconBreakpointColor} !important; font-size: 12px !important; } `); </del> <ins> collector.addRule(`${scope} { ${ThemeIcon.asCSSSelector(icons.breakpoint.pending)} { color: ${debugIconBreakpointColor} !important; font-size: 12px !important; } }`); </ins> } const debugIconBreakpointDisabledColor = theme.getColor(debugIconBreakpointDisabledForeground); if (debugIconBreakpointDisabledColor) { <del> collector.addRule(` ${icons.allBreakpoints.map(b => `.monaco-workbench ${ThemeIcon.asCSSSelector(b.disabled)}`).join(',n		')} { color: ${debugIconBreakpointDisabledColor}; } `); </del> <ins> collector.addRule(`${scope} { ${icons.allBreakpoints.map(b => ThemeIcon.asCSSSelector(b.disabled)).join(',n		')} { color: ${debugIconBreakpointDisabledColor}; } }`); </ins> } const debugIconBreakpointUnverifiedColor = theme.getColor(debugIconBreakpointUnverifiedForeground); if (debugIconBreakpointUnverifiedColor) { <del> collector.addRule(` ${icons.allBreakpoints.map(b => `.monaco-workbench ${ThemeIcon.asCSSSelector(b.unverified)}`).join(',n		')} { color: ${debugIconBreakpointUnverifiedColor}; } `); </del> <ins> collector.addRule(`${scope} { ${icons.allBreakpoints.map(b => ThemeIcon.asCSSSelector(b.unverified)).join(',n		')} { color: ${debugIconBreakpointUnverifiedColor}; } }`); </ins> } const debugIconBreakpointCurrentStackframeForegroundColor = theme.getColor(debugIconBreakpointCurrentStackframeForeground); if (debugIconBreakpointCurrentStackframeForegroundColor) { collector.addRule(` <del> .monaco-workbench ${ThemeIcon.asCSSSelector(icons.debugStackframe)}, </del> .monaco-editor .debug-top-stack-frame-column { color: ${debugIconBreakpointCurrentStackframeForegroundColor} !important; } <ins> ${scope} { ${ThemeIcon.asCSSSelector(icons.debugStackframe)} { color: ${debugIconBreakpointCurrentStackframeForegroundColor} !important; } } </ins> `); } const debugIconBreakpointStackframeFocusedColor = theme.getColor(debugIconBreakpointStackframeForeground); if (debugIconBreakpointStackframeFocusedColor) { <del> collector.addRule(` .monaco-workbench ${ThemeIcon.asCSSSelector(icons.debugStackframeFocused)} { color: ${debugIconBreakpointStackframeFocusedColor} !important; } `); </del> <ins> collector.addRule(`${scope} { ${ThemeIcon.asCSSSelector(icons.debugStackframeFocused)} { color: ${debugIconBreakpointStackframeFocusedColor} !important; } }`); </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?: 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. --Version: 1.91.1 Commit: Date: 2024-07-09T22:06:49.809Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: a TreeView with an TreeItem the TreeItem's iconPath to the extension. The TreeItem's icon will still be yellow same as in debugging. After inspecting developer tools, this is likely due to how the icon debug-stackframe's color rule is set to !important. The ThemeColor fails to overwrite it due to low specificity. This may not only happen with the icon "debug-stackframe" and is affecting customisations of treeitems. Why is some icons' color rules given the !important flag et al? There might not be any easy fix due to this flag's present. I hope the team could look into it, and if possible fix this selector specificity issue (if it won't break vscode, somehow).
Edit: This not only occurs on special icons like debug-stackframe, but also on very ordinary ones like circle-filled. style attribute { color: rgb(204, 204, 204); } .monaco-workbench .codicon { } Adding !important to the color flag of .monaco-workbench .codicon will fix the issue though.. The problem is worse :C
I think the best solution would be to get rid of that . it's coming from here. Can it be removed? The css you shared is correct. The rbg value is the one you set in your ThemeIcon. !
Yea, we should scope these rules better (and also move them to css now that we have variables there)
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased

} )) as WorkbenchTable<IDisassembledInstructionEntry>; <ins> this._disassembledInstructions.domNode.classList.add('disassembly-view'); </ins> if (this.focusedInstructionReference) { this.reloadDisassembly(this.focusedInstructionReference, 0); }


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: 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. --Version: 1.91.1 Commit: Date: 2024-07-09T22:06:49.809Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: a TreeView with an TreeItem the TreeItem's iconPath to the extension. The TreeItem's icon will still be yellow same as in debugging. After inspecting developer tools, this is likely due to how the icon debug-stackframe's color rule is set to !important. The ThemeColor fails to overwrite it due to low specificity. This may not only happen with the icon "debug-stackframe" and is affecting customisations of treeitems. Why is some icons' color rules given the !important flag et al? There might not be any easy fix due to this flag's present. I hope the team could look into it, and if possible fix this selector specificity issue (if it won't break vscode, somehow).
Edit: This not only occurs on special icons like debug-stackframe, but also on very ordinary ones like circle-filled. style attribute { color: rgb(204, 204, 204); } .monaco-workbench .codicon { } Adding !important to the color flag of .monaco-workbench .codicon will fix the issue though.. The problem is worse :C
I think the best solution would be to get rid of that . it's coming from here. Can it be removed? The css you shared is correct. The rbg value is the one you set in your ThemeIcon. !
Yea, we should scope these rules better (and also move them to css now that we have variables there)
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased

// align from the bottom so that it lines up with instruction when source code is present. container.style.alignSelf = 'flex-end'; <del> const icon = append(container, $('.disassembly-view')); icon.classList.add('codicon'); </del> <ins> const icon = append(container, $('.codicon')); </ins> icon.style.display = 'flex'; icon.style.alignItems = 'center'; icon.style.justifyContent = 'center';


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.92.0 Commit: Date: 2024-07-31T23:26:45.634Z Electron: 30.1.2 ElectronBuildId: Chromium: 124.0.6367.243 20.14.0 V8: 12.4.254.20-electron.0 OS: Linux x64 6.9.3--generic Steps to Reproduce: theme to Light High Contrast a Javascript file final bracket is black, not red as in other themes
I believe this may be the core cause: The value for hcLight here is just an empty string
Thanks for investigating, looks like this color got forgotten when creating the Light HC theme. I took the same color as used in the overview ruler

export const editorBracketHighlightingForeground5 = registerColor('editorBracketHighlight.foreground5', '#00000000', nls.localize('editorBracketHighlightForeground5', 'Foreground color of brackets (5). Requires enabling bracket pair colorization.')); export const editorBracketHighlightingForeground6 = registerColor('editorBracketHighlight.foreground6', '#00000000', nls.localize('editorBracketHighlightForeground6', 'Foreground color of brackets (6). Requires enabling bracket pair colorization.')); <del> export const editorBracketHighlightingUnexpectedBracketForeground = registerColor('editorBracketHighlight.unexpectedBracket.foreground', { dark: new Color(new RGBA(255, 18, 18, 0.8)), light: new Color(new RGBA(255, 18, 18, 0.8)), hcDark: new Color(new RGBA(255, 50, 50, 1)), hcLight: '' }, nls.localize('editorBracketHighlightUnexpectedBracketForeground', 'Foreground color of unexpected brackets.')); </del> <ins> export const editorBracketHighlightingUnexpectedBracketForeground = registerColor('editorBracketHighlight.unexpectedBracket.foreground', { dark: new Color(new RGBA(255, 18, 18, 0.8)), light: new Color(new RGBA(255, 18, 18, 0.8)), hcDark: 'new Color(new RGBA(255, 50, 50, 1))', hcLight: '#B5200D' }, nls.localize('editorBracketHighlightUnexpectedBracketForeground', 'Foreground color of unexpected brackets.')); </ins> export const editorBracketPairGuideBackground1 = registerColor('editorBracketPairGuide.background1', '#00000000', nls.localize('editorBracketPairGuide.background1', 'Background color of inactive bracket pair guides (1). Requires enabling bracket pair guides.')); export const editorBracketPairGuideBackground2 = registerColor('editorBracketPairGuide.background2', '#00000000', nls.localize('editorBracketPairGuide.background2', 'Background color of inactive bracket pair guides (2). Requires enabling bracket pair guides.'));


Question: As reported by open notebook open nb from timeline close diff close notebook then I got Can repro from stable

} override dispose() { <ins> // The editor isn't disposed yet, it can be re-used. // However the model can be disposed before the editor & that causes issues. if (this._editor) { this._editor.setModel(null); } </ins> if (this._editor && this._editorViewStateChanged) { this.cell.saveSpirceEditorViewState(this._editor.saveViewState()); }


Question: <img width="1072" alt="image" src=""<img width="838" alt="image" src=""

return $('tr', undefined, ...row.map(rowData => { if (typeof rowData === 'string') { <del> return $('td', undefined, rowData); </del> <ins> return $('td', undefined, $('p', undefined, rowData)); </ins> } const data = Array.isArray(rowData) ? rowData : [rowData]; return $('td', undefined, ...data.map(item => {


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 No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!

alias: { './node/authServer': path.resolve(__dirname, 'src/browser/authServer'), './node/buffer': path.resolve(__dirname, 'src/browser/buffer'), <ins> './node/fetch': path.resolve(__dirname, 'src/browser/fetch'), </ins> './node/authProvider': path.resolve(__dirname, 'src/browser/authProvider'), } }


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 No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!

import { BetterTokenStorage, IDidChangeInOtherWindowEvent } from './betterSecretStorage'; import { LoopbackAuthServer } from './node/authServer'; import { base64Decode } from './node/buffer'; <ins> import fetch from './node/fetch'; </ins> import { UriEventHandler } from './UriEventHandler'; import TelemetryReporter from '@vscode/extension-telemetry'; import { Environment } from '@azure/ms-rest-azure-env';


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 No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!

let result; let errorMessage: string | undefined; try { <del> result = await fetch(endpoint, { </del> <ins> result = await fetch(endpoint.toString(), { </ins> method: 'POST', headers: { <del> 'Content-Type': 'application/x-www-form-urlencoded', 'Content-Length': postData.length.toString() </del> <ins> 'Content-Type': 'application/x-www-form-urlencoded' </ins> }, body: postData });


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 No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!

<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ export default fetch; </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 No. The issue occurs in a built-in extension so extensions need to be enabled to see the issue. <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --Version: 1.93.0-insider (Universal) Commit: Date: 2024-08-26T05:04:02.640Z Electron: 30.3.1 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Darwin arm64 23.6.0 Steps to Reproduce: VS Code behind a proxy server and make a call to the function from the package included with VS Code similar to the one below. After the changes listed in , we began seeing failures from the Microsoft Authentication extension with the following log entries at startup. We rely on that extension to allow another extension we developed internally to authenticate our users. After debugging into the extension source, I found that the issue was originating here. After reading through the previously mentioned pull request, I figured that the call was hanging because the new function was not handling proxy configurations the same way (a common issue in corporate settings). I pulled down VS Code, built from source and tested a change that resolves the issue. I'd like to open a pull request with the fix if you agree that there is a bug in this flow. System Information
will be exploring fixing this type of issue transparently.
This will be in Monday's Insiders build. Can you please give that a try when it drops so we know for a fact we've fixed the issue for you?
that fixed the issue. Thanks so much for the quick response to our problem!

<ins> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ let _fetch: typeof fetch; try { _fetch = require('electron').net.fetch; } catch { _fetch = fetch; } export default _fetch; </ins>


Question:
Testing Repro steps: some changes to a cell, in my case I a cell with some content the changes some lines from the cell that was in step 1, and save. diff view launched from "changes" SCM view should diff between staged and working.
Now the diff view for the changes in the 'Staged Changes' group is the same as the diff view for the unstaged changes
I am seeing it as I would expect. This is diff launched from staged (where the cell was ) ! This is diff launched on unstaged: !
Works for me too, can you share the text file contents in the 3 cases Commited ipynb Staged ipynb & finally changed ipynb
Original steps LGTM
Original file: ! Modification 1: ! Modification 2: ! Observe that the diffs for the Staged and Working Changes regions below are identical !

this._versionId = this._textModel.getVersionId(); this._alternativeId = this._textModel.getAlternativeVersionId(); } <ins> this._textBufferHash = null; </ins> this._onDidChangeContent.fire('content'); }));


Question: Testing I think we have another issue discussing a similar issue. This hover and the main item hover can conflict with each other: <img width="579" alt="Screenshot 2024-08-27 at 10 37 49 AM" src=""Instead of having a special hover just for the badges I think the main hover accomplishes the goal just fine as the badge and its description shows up at the bottom: <img width="698" alt="Screenshot 2024-08-27 at 10 39 05 AM" src=""

import { $, append } from 'vs/base/browser/dom'; import { IHoverOptions, IManagedHover, IManagedHoverTooltipMarkdownString } from 'vs/base/browser/ui/hover/hover'; import { IHoverDelegate } from 'vs/base/browser/ui/hover/hoverDelegate'; <del> import { createInstantHoverDelegate, getDefaultHoverDelegate } from 'vs/base/browser/ui/hover/hoverDelegateFactory'; </del> <ins> import { getDefaultHoverDelegate } from 'vs/base/browser/ui/hover/hoverDelegateFactory'; </ins> import { IconLabel } from 'vs/base/browser/ui/iconLabel/iconLabel'; import { IIdentityProvider, IKeyboardNavigationLabelProvider, IListVirtualDelegate } from 'vs/base/browser/ui/list/list'; import { LabelFuzzyScore } from 'vs/base/browser/ui/tree/abstractTree';


Question: Testing I think we have another issue discussing a similar issue. This hover and the main item hover can conflict with each other: <img width="579" alt="Screenshot 2024-08-27 at 10 37 49 AM" src=""Instead of having a special hover just for the badges I think the main hover accomplishes the goal just fine as the badge and its description shows up at the bottom: <img width="698" alt="Screenshot 2024-08-27 at 10 39 05 AM" src=""

templateData.labelContainer.textContent = ''; if (historyItem.labels) { <del> const instantHoverDelegate = createInstantHoverDelegate(); templateData.elementDisposables.add(instantHoverDelegate); </del> // Get lits of labels to render (current, remote, base) const labels = this.getLabels(node.element.repository);


Question: Testing I think we have another issue discussing a similar issue. This hover and the main item hover can conflict with each other: <img width="579" alt="Screenshot 2024-08-27 at 10 37 49 AM" src=""Instead of having a special hover just for the badges I think the main hover accomplishes the goal just fine as the badge and its description shows up at the bottom: <img width="698" alt="Screenshot 2024-08-27 at 10 39 05 AM" src=""

if (label.icon && ThemeIcon.isThemeIcon(label.icon) && labels.includes(label.title)) { const icon = append(templateData.labelContainer, $('div.label')); icon.classList.add(...ThemeIcon.asClassNameArray(label.icon)); <del> const hover = this.hoverService.setupManagedHover(instantHoverDelegate, icon, label.title); templateData.elementDisposables.add(hover); </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. --Version: 1.93.0-insider Commit: Date: 2024-08-29T05:04:03.909Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Linux x64 6.9.3--generic Steps to Reproduce: a few editor groups in seemingly any split configuration one for text input or otherwise run to type: no result, as no editor has focus any more. This is especially frustrating when some of your other keyboard shortcuts rely on the editorFocus context, as they become unusable after using this feature.
In case this takes a while to fix, anyone looking for a workaround can rebind their preferred shortcut to automatically refocus the editor and then "move" the cursor to ensure if another window has now covered your cursor, the editor scrolls to reveal it again (also respecting scrolloff setting).
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

const editorGroupService = accessor.get(IEditorGroupsService); const newOrientation = (editorGroupService.orientation === GroupOrientation.VERTICAL) ? GroupOrientation.HORIZONTAL : GroupOrientation.VERTICAL; editorGroupService.setGroupOrientation(newOrientation); <ins> editorGroupService.activeGroup.focus(); </ins> } });


Question:
Enable the setting which enabled the native edit context adoption Copy some code which is more than 3 lines long Paste the code. The code that is pasted does not correspond to the code that is copied
After some investigation, I have noticed the following curious points. In the following, please note that to fix the long-press-E chromium issue, we essentially always write the screen reader content which means we always change the document selection. When screen reader is toggled off: When we read the copied text from the the electron clipboard in order to paste, it is incorrect When we remove the logic that sets the document selection for the screen reader content, the pasted text is correct When screen reader is toggled on: Text that is read from electron clipboard is always correct In fact interestingly when we revert the changes we have made for the long-press E issue, then this copy-paste issue no longer occurs! Since the long-press E issue is not important, and copy pasting is much more important, I believe that we should revert that fix. From this I believe this could be somehow related to a chromium bug. cc
I have made the following PR to revert the long press E fix : This fixed copy-pasting too.

this._compositionRangeWithinEditor = newCompositionRangeWithinEditor; } this._emitTypeEvent(viewController, e); <del> // TODO @aiday-mar calling write screen reader content so that the document selection is immediately set // remove the following when electron will be upgraded this._screenReaderSupport.writeScreenReaderContent(); </del> })); this._register(editContextAddDisposableListener(this._editContext, 'compositionstart', (e) => { const position = this._context.viewModel.getPrimaryCursorState().modelState.position;


Question:
Enable the setting which enabled the native edit context adoption Copy some code which is more than 3 lines long Paste the code. The code that is pasted does not correspond to the code that is copied
After some investigation, I have noticed the following curious points. In the following, please note that to fix the long-press-E chromium issue, we essentially always write the screen reader content which means we always change the document selection. When screen reader is toggled off: When we read the copied text from the the electron clipboard in order to paste, it is incorrect When we remove the logic that sets the document selection for the screen reader content, the pasted text is correct When screen reader is toggled on: Text that is read from electron clipboard is always correct In fact interestingly when we revert the changes we have made for the long-press E issue, then this copy-paste issue no longer occurs! Since the long-press E issue is not important, and copy pasting is much more important, I believe that we should revert that fix. From this I believe this could be somehow related to a chromium bug. cc
I have made the following PR to revert the long press E fix : This fixed copy-pasting too.

} private _getScreenReaderContentState(): ScreenReaderContentState | undefined { <del> // Make the screen reader content always be visible because of the bug and also set the selection // TODO @aiday-mar Ultimately uncomment this code when Electron will be upgraded // if (this._accessibilitySupport === AccessibilitySupport.Disabled) { // 	return; // } const accessibilityPageSize = this._accessibilitySupport === AccessibilitySupport.Disabled ? 1 : this._accessibilityPageSize; </del> <ins> if (this._accessibilitySupport === AccessibilitySupport.Disabled) { return; } </ins> const simpleModel: ISimpleModel = { getLineCount: (): number => { return this._context.viewModel.getLineCount();


Question:
Enable the setting which enabled the native edit context adoption Copy some code which is more than 3 lines long Paste the code. The code that is pasted does not correspond to the code that is copied
After some investigation, I have noticed the following curious points. In the following, please note that to fix the long-press-E chromium issue, we essentially always write the screen reader content which means we always change the document selection. When screen reader is toggled off: When we read the copied text from the the electron clipboard in order to paste, it is incorrect When we remove the logic that sets the document selection for the screen reader content, the pasted text is correct When screen reader is toggled on: Text that is read from electron clipboard is always correct In fact interestingly when we revert the changes we have made for the long-press E issue, then this copy-paste issue no longer occurs! Since the long-press E issue is not important, and copy pasting is much more important, I believe that we should revert that fix. From this I believe this could be somehow related to a chromium bug. cc
I have made the following PR to revert the long press E fix : This fixed copy-pasting too.

return this._context.viewModel.modifyPosition(position, offset); } }; <del> return PagedScreenReaderStrategy.fromEditorSelection(simpleModel, this._primarySelection, accessibilityPageSize, this._accessibilitySupport === AccessibilitySupport.Unknown); </del> <ins> return PagedScreenReaderStrategy.fromEditorSelection(simpleModel, this._primarySelection, this._accessibilityPageSize, this._accessibilitySupport === AccessibilitySupport.Unknown); </ins> } private _setSelectionOfScreenReaderContent(selectionOffsetStart: number, selectionOffsetEnd: number): void {


Question: Enable the setting Open the editor Open the find widget Type several letters The editor is focused as soon as there is a match for the find result It is no longer possible to continue typing in the find widget without retriggering the focusing of the find widget

*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { getActiveWindow } from '../../../../../base/browser/dom.js'; </del> <ins> import { getActiveWindow, isHTMLElement } from '../../../../../base/browser/dom.js'; </ins> import { FastDomNode } from '../../../../../base/browser/fastDomNode.js'; import { AccessibilitySupport } from '../../../../../platform/accessibility/common/accessibility.js'; import { IKeybindingService } from '../../../../../platform/keybinding/common/keybinding.js';


Question: Enable the setting Open the editor Open the find widget Type several letters The editor is focused as soon as there is a match for the find result It is no longer possible to continue typing in the find widget without retriggering the focusing of the find widget

if (!textContent) { return; } <ins> const focusedElement = getActiveWindow().document.activeElement; </ins> const range = new globalThis.Range(); range.setStart(textContent, selectionOffsetStart); range.setEnd(textContent, selectionOffsetEnd); activeDocumentSelection.removeAllRanges(); activeDocumentSelection.addRange(range); <ins> if (isHTMLElement(focusedElement)) { focusedElement.focus(); } </ins> } }


Question:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.93.1 OS Version: Windows 11 Pro Originally from To Reproduce Steps to reproduce the behavior: an empty dart project (can be any language, this is just the one I use of course) the code below breakpoints on both and print calls the breakpoint on the trigger only after the one at (screenshot) the code and make sure the breakpoint stops the program that triggers before Expected behavior For the triggered breakpoint to wait again on restart. Also note that there are two ways to restart a debug session too - a full restart handled by VS Code (which is what happens for Dart above), and a restart that is delegated to the debug adapter (which we use for Flutter to do Hot Restart, so it's faster than a cold restart by VS Code). In both cases, this state should be reset. Screenshots ! <details<summaryRelevant debugging log part </summary</details// CC:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.93.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Interestingly, I cannot reproduce this with JavaScript using an equivalent file: Unfortunately I don't think it uses DAP and I don't know if there's a way to get a log of what's happening there. It's not clear to me how it could be working there given the DAP traffic captured for Dart. Someone familiar with the implementation of Triggered Breakpoints or the JS debugger might be able to explain what's going on.
I can on python:
I am also running into this issue
This is probably because the JS debugger has each debugee as its own, child session, and when restarting JS you will retain the parent session (handled by the DA) but get a new child session that doesn't have the data set.
I am debugging Go. I don't remember seeing it with other languages but I also only rarely run anything other than Go.
yea, it's reproducable with Python too. Fixed in Monday's Insiders.

} }; <ins> for (const breakpoint of this.model.getBreakpoints({ triggeredOnly: true })) { breakpoint.setSessionDidTrigger(session.getId(), false); } </ins> // For debug sessions spawned by test runs, cancel the test run and stop // the session, then start the test run again; tests have no notion of restarts. if (session.correlatedTestRun) {


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.93.1 OS Version: Windows 11 Pro Originally from To Reproduce Steps to reproduce the behavior: an empty dart project (can be any language, this is just the one I use of course) the code below breakpoints on both and print calls the breakpoint on the trigger only after the one at (screenshot) the code and make sure the breakpoint stops the program that triggers before Expected behavior For the triggered breakpoint to wait again on restart. Also note that there are two ways to restart a debug session too - a full restart handled by VS Code (which is what happens for Dart above), and a restart that is delegated to the debug adapter (which we use for Flutter to do Hot Restart, so it's faster than a cold restart by VS Code). In both cases, this state should be reset. Screenshots ! <details<summaryRelevant debugging log part </summary</details// CC:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.93.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Interestingly, I cannot reproduce this with JavaScript using an equivalent file: Unfortunately I don't think it uses DAP and I don't know if there's a way to get a log of what's happening there. It's not clear to me how it could be working there given the DAP traffic captured for Dart. Someone familiar with the implementation of Triggered Breakpoints or the JS debugger might be able to explain what's going on.
I can on python:
I am also running into this issue
This is probably because the JS debugger has each debugee as its own, child session, and when restarting JS you will retain the parent session (handled by the DA) but get a new child session that doesn't have the data set.
I am debugging Go. I don't remember seeing it with other languages but I also only rarely run anything other than Go.
yea, it's reproducable with Python too. Fixed in Monday's Insiders.

readonly pending: boolean; /** Marks that a session did trigger the breakpoint. */ <del> setSessionDidTrigger(sessionId: string): void; </del> <ins> setSessionDidTrigger(sessionId: string, didTrigger?: boolean): void; </ins> /** Gets whether the `triggeredBy` condition has been met in the given sesison ID. */ getSessionDidTrigger(sessionId: string): boolean;


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.93.1 OS Version: Windows 11 Pro Originally from To Reproduce Steps to reproduce the behavior: an empty dart project (can be any language, this is just the one I use of course) the code below breakpoints on both and print calls the breakpoint on the trigger only after the one at (screenshot) the code and make sure the breakpoint stops the program that triggers before Expected behavior For the triggered breakpoint to wait again on restart. Also note that there are two ways to restart a debug session too - a full restart handled by VS Code (which is what happens for Dart above), and a restart that is delegated to the debug adapter (which we use for Flutter to do Hot Restart, so it's faster than a cold restart by VS Code). In both cases, this state should be reset. Screenshots ! <details<summaryRelevant debugging log part </summary</details// CC:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.93.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Interestingly, I cannot reproduce this with JavaScript using an equivalent file: Unfortunately I don't think it uses DAP and I don't know if there's a way to get a log of what's happening there. It's not clear to me how it could be working there given the DAP traffic captured for Dart. Someone familiar with the implementation of Triggered Breakpoints or the JS debugger might be able to explain what's going on.
I can on python:
I am also running into this issue
This is probably because the JS debugger has each debugee as its own, child session, and when restarting JS you will retain the parent session (handled by the DA) but get a new child session that doesn't have the data set.
I am debugging Go. I don't remember seeing it with other languages but I also only rarely run anything other than Go.
yea, it's reproducable with Python too. Fixed in Monday's Insiders.

return `${resources.basenameOrAuthority(this.uri)} ${this.lineNumber}`; } <del> public setSessionDidTrigger(sessionId: string): void { this.sessionsDidTrigger ??= new Set(); this.sessionsDidTrigger.add(sessionId); </del> <ins> public setSessionDidTrigger(sessionId: string, didTrigger = true): void { if (didTrigger) { this.sessionsDidTrigger ??= new Set(); this.sessionsDidTrigger.add(sessionId); } else { this.sessionsDidTrigger?.delete(sessionId); } </ins> } public getSessionDidTrigger(sessionId: string): boolean {


Question:
today's insiders open GHINB and run a cell see errors (many) on the console
broke
We should also add a custom eslint rule for this. It has been broken for a few weeks and it regresses the output focus context keys.

}, 0); }; <ins> const isEditableElement = (element: Element) => { return element.tagName.toLowerCase() === 'input' || element.tagName.toLowerCase() === 'textarea' || 'editContext' in element; }; </ins> // check if an input element is focused within the output element const checkOutputInputFocus = (e: FocusEvent) => { lastFocusedOutput = getOutputContainer(e);


Question:
today's insiders open GHINB and run a cell see errors (many) on the console
broke
We should also add a custom eslint rule for this. It has been broken for a few weeks and it regresses the output focus context keys.

JSON.parse(decodeURIComponent("${encodeURIComponent(JSON.stringify(ctx))}")) )n//# sourceURL=notebookWebviewPreloads.jsn`; } <del> export function isEditableElement(element: Element): boolean { return element.tagName.toLowerCase() === 'input' || element.tagName.toLowerCase() === 'textarea' || 'editContext' in element; } </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.95.0-insider OS Version: Windows 11 Steps to Reproduce: : window to message and use <kbdShift</kbd+<kbdEnter</kbd<kbdShift</kbd+<kbdEnter</kbddoes not work in Source control message text area if option is enabled. It seems that it occurs not only in but also when I edit any file. <hrMaybe related to
I see thank you for filing this issue. I will look into it.
Hi may I ask you what you were expecting to see? I turned the setting on and off and press when I have no commits to make and a notification pops up mentioning that I have no changes to commit. Thank you.
Hi, thank you for checking it out. I expect that a new line will be , the same as with just pressing <kbdEnter</kbd. By the way, the same issue occurs when I edit a file.
Hi thank you for clarifying the question, yes I am able to reproduce this behavior. This happens because we don't send a new line event when we receive the event. I will make a PR to fix this.

viewController.emitKeyDown(standardKeyboardEvent); })); this._register(addDisposableListener(this.domNode.domNode, 'beforeinput', async (e) => { <del> if (e.inputType === 'insertParagraph') { </del> <ins> if (e.inputType === 'insertParagraph' || e.inputType === 'insertLineBreak') { </ins> this._onType(viewController, { text: 'n', replacePrevCharCnt: 0, replaceNextCharCnt: 0, positionDelta: 0 }); } }));