jiebi/CodeConvo huggingface dataset:
Code change:
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.

Related discussion:
text: 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;
Code change:
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.

Related discussion:
text: } 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();
Code change:
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.

Related discussion:
text: 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 {
Code change:
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

Related discussion:
text: *  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';
Code change:
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

Related discussion:
text: 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> } }
Code change:
<!-- 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.

Related discussion:
text: } }; <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) {
Code change:
<!-- 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.

Related discussion:
text: 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;
Code change:
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.

Related discussion:
text: }, 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);
Code change:
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.

Related discussion:
text: 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>
Code change:
<!-- 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.

Related discussion:
text: 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 }); } }));