Pasting from the clipboard into an editor no longer works, instead causing the cursor to jump to seemingly random places

[Neurrone]

Type: Bug

I'm noticing this behaviour in a Python file. When pressing ctrl+v to paste from the clipboard, my cursor instead jumps to a random position, and no text is pasted.

Working on a minimal reproduceable test case.

VS Code version: Code - Insiders 1.96.0-insider (9086857, 2024-11-22T09:56:24.579Z)
OS version: Windows_NT x64 10.0.22631
Modes:
Remote OS version: Linux x64 5.15.167.4-microsoft-standard-WSL2

System Info

Item	Value
CPUs	AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics (16 x 3294)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: enabled_on direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off
Load (avg)	undefined
Memory (System)	62.72GB (47.13GB free)
Process Argv	--folder-uri=vscode-remote://wsl+ubuntu/home/dickson/source/leetcode-2024 --remote=wsl+ubuntu
Screen Reader	yes
VM	40%

Item	Value
Remote	WSL: ubuntu
OS	Linux x64 5.15.167.4-microsoft-standard-WSL2
CPUs	AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics (16 x 0)
Memory (System)	30.72GB (29.07GB free)
VM	0%

Extensions (17)

Extension	Author (truncated)	Version
astro-vscode	ast	2.15.4
vscode-eslint	dba	3.0.10
dendron	den	0.124.0
dendron-paste-image	den	1.1.1
prettier-vscode	esb	11.0.0
debugpy	ms-	2024.12.0
python	ms-	2024.20.0
vscode-pylance	ms-	2024.11.3
rust-analyzer	rus	0.4.2193
remote-containers	ms-	0.391.0
remote-ssh	ms-	0.115.1
remote-ssh-edit	ms-	0.87.0
remote-wsl	ms-	0.88.5
vscode-remote-extensionpack	ms-	0.26.0
remote-explorer	ms-	0.4.3
remote-server	ms-	1.5.2
nvda-indent-nav-accessibility	Ton	1.0.0

[Neurrone]

This is not limited to pasting. Ctrl+a or using the "select all" from palet also doesn't select the entire file.

Something seems to have screwed up really badly in the latest insider release.

[Neurrone]

Latest version is bad, 1.96.0.20241122 user installer

Version: 1.96.0-insider (user setup)
Commit: 90868576241dd25c6c5da64adadc0a09de91a9fe
Date: 2024-11-22T09:56:24.579Z
Electron: 32.2.5
ElectronBuildId: 10579404
Chromium: 128.0.6613.186
Node.js: 20.18.0
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.22631

Last good version that doesn't have this bug is the one before that, 1.96.0.20241121 user installer

Version: 1.96.0-insider (user setup)
Commit: 69acde7458f428f0e6869de8915c9dd995cdda1a
Date: 2024-11-21T05:04:38.064Z
Electron: 32.2.5
ElectronBuildId: 10579404
Chromium: 128.0.6613.186
Node.js: 20.18.0
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.22631

[jwiede]

This impact both Linux and Mac as well, and is a real showstopper issue. Seeing both the select-all behavior (which seems to break at the first pt where intellicode has an issue with the src), and the paste behavior (where jumping appears tied to similar "fixed" src points).

As for the paste behavior, if you subsequently paste at the jumped-to location, the paste op works. Unfortunately, the jump isn't "relative" so you cannot compensate for it and thereby paste to where you want. Instead, the jump-to points appear associated with something in the src, and appear fixed, so between one and the next, any attempts to paste between jump to the immediately prior pt. Difficult to explain, can try to produce a screencast if needed (will reply and post here if asked).

No clue if any help, but 234240 & 234244 both seem around proper timeframe and area, but also could 100% be red herrings.

BTW, Neurrone, can you or someone please provide user installers for that "Last Known Good" (LKG) for Linux and Mac as well? Or provide a link to the instructions how we can locate them for ourselves? I've never had luck finding installers for prior releases of insiders.

[Neurrone]

I wish there was an easier way of finding old releases. I went to the VS Code website and after downloading the latest insiders build, used the downloads manager in the browser to look at the file's link. Use that to reverse-engineer the link to a previous version.

Remember that even after you manage to revert to a previous version, it will automatically update you to the current bad version. So you'll have to disable automatic updates as well.

[gwiede]

Yes, it's especially vexing when you need to try and verify when a problem occurred -- I saw this the day it released, but couldn't step back, so wasn't confident reporting until I'd done a bunch of extension removal, etc. which took me days. Had I been able to step back to the prior day's release, I would have had enough data to report this on the 22nd.

Inability to roll back to earlier insiders releases really is limiting users' ability to debug issues. This "only ever forward" mindset is explicitly contrary to basic debugging/triage first principles.

[gwiede]

To get back to the topic, I've seen the jump-instead-of-paste misbehavior occur for C/C++, Arduino(.INO), Markdown(.MD), Rust,
TOML, Lua, you name it. I've yet to find a filetype that doesn't exhibit the behavior. They all exhibit the same "fixed jump-points" misbehavior too, where no matter where you start from between two jump points, it always jumps to the "immediately prior jump-point".

[aiday-mar]

Hi thank you for filing this issue, this seems to be related to the combination of the edit context and the screen reader mode being enabled. I will turn off the edit context by default on Insiders, investigate all the issues and turn it back on later. I am very sorry this caused issues for you and will fix the issue.

[gwiede]

Just to update, yes, turning off the screen reader optimization does eliminate the odd jump-instead-of-paste behavior here. Doesn't really present a viable mitigation for accessibility reasons, but it does stop the behavior. I'll test whether disabling the default edit context works here, if you can provide a means of doing so?

Lacking any user instructions for disabling default edit context, is there any ETA when we can expect to see this in an insider's update? As it stands, vscode has become nigh-useless for coding here due to this issue, because muscle-memory regarding cut&paste use means it is basically hard-wired into how I edit.

[tamuratak]

Version: 1.96.0-insider
Commit: 2dd0bca
Date: 2024-11-26T05:03:52.908Z
Electron: 32.2.5
ElectronBuildId: 10579404
Chromium: 128.0.6613.186
Node.js: 20.18.0
V8: 12.8.374.38-electron.0
OS: Darwin arm64 22.6.0

ProductName: macOS
ProductVersion: 13.7.1
BuildVersion: 22H221

I can reproduce a similar issue on macOS.

• Enable Voice Over. Set "editor.wordWrap": "on". Set "editor.experimentalEditContextEnabled": true. Set "editor.accessibilitySupport": "on".
• Type very long lines.
• When clicking at the end of a wrapped long line, the cursor moves to a random line.

jumpcursor.mov

[aiday-mar]

Hi @gwiede thank you for the message. The setting name to disable the edit context is: "editor.experimentalEditContextEnabled"
The edit context has been anyway turned off by default recently so this should no longer happen until it is turned on by default again

Hi @tamuratak thank you for filing this issue, it is very valuable and I will investigate it. I filed an issue here #234737

One thing I may implement is to enable the edit context by default only when the screen reader mode is disabled. This will allow me to turn it on for non screen reader users and investigate other bugs in the meantime.

[aiday-mar]

My investigation has revealed the pasting issue happens for the following reason:

• When EditContext is enabled, for each view, a hidden div node and a hidden text-area node is created
• The purpose of the hidden text area is to receive focus so that text can be pasted inside of it. A dom node with EditContext set on it, can not receive an execCommandI('paste') event
• So before doing the pasting, we focus the hidden text area and then trigger the paste
• This sends a selection change event on the document, which we listen on. We listen to this event because we need to change the cursor position when the selection changes with a tertiary party like NVDA. This listener is only set when accessibility mode is turned on (hence why this bug does not happen without accessibility mode).
• We change the editor selection because there was a selection change event
  • There are in fact two selection change events, one happens when we focus the hidden text area, and the other happens when we focus back on the hidden div which has the edit context
• The paste logic is written in such a way so that if the cursor selection changes during pasting, the paste operation is cancelled, which is what happens.

There are several possibilities for how to fix this:

• Bypass the usage of the text-area dom node so that no selection change event is sent. From my understanding we will soon be exploring a new pasting API which could help us fix this issue, cc @mjbvz
• Use a combination of booleans, in order to ignore the selection change events and not react upon them. This is a finicky and non-rigorous solution, because we can't be sure exactly how many events will be emitted, and so sometimes maybe pasting will work, sometimes not
  • We could complement the above by analyzing the selection change event with greater detail to decide whether to ignore it. ie: is the src or target element the hidden text area?
• We could remove the logic that cancels a paste operation on selection change (unknown consequences thus far)

I will think of other potential solutions

[aiday-mar]

Hi everyone, I have found a fix for this with the PR #234846. I will test the edit context some more with the accessibility mode and after fixing all the issues, I will enable the edit context once again. Can I ask the users in this thread to let me know if you see any other issues with the edit context when the accessibility mode is turned on? Thank you.