ctrl+right arrow command clears all cursors

[yncat]

Issue Type: Bug

I don't think such a basic feature has a bug... But I'm currently unable to select a word for each line using the multi cursor. Steps to reproduce:

(1) Open an empty document. (2) Enter numbers 1 to 10 on each line as an example. (3) Press ctrl+a for selecting all, then press alt+shift+i to place cursors. (4) Press home to move cursors to the top of each line. (5) Press ctrl+right arrow.

Expected: Cursors select 1 to 10. Happening: All secondary cursors disappear.

Again, if this were a bug, it should have been already reported. I think it's something to do with my computer. Any settings which might affect the behavior?

VS Code version: Code 1.63.2 (899d46d82c4c95423fb7e10e68eba52050e30ba3, 2021-12-15T09:40:02.816Z) OS version: Windows_NT x64 10.0.19042 Restricted Mode: No

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i5-8200Y CPU @ 1.30GHz (4 x 1608)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled| |Load (avg)|undefined| |Memory (System)|7.91GB (3.18GB free)| |Process Argv|--crash-reporter-id 4b0d454d-e170-4f2f-aeb0-64f39bbdf48e| |Screen Reader|yes| |VM|0%|

Extensions (27)

Extension|Author (truncated)|Version ---|---|--- vscode-intelephense-client|bme|1.8.0 doxdocgen|csc|1.3.2 vscode-markdownlint|Dav|0.45.0 vscode-eslint|dba|2.2.2 prettier-vscode|esb|9.0.0 language-hsp3|hon|1.0.4 better-cpp-syntax|jef|1.15.10 vscode-language-pack-ja|MS-|1.63.3 python|ms-|2021.12.1559732655 vscode-pylance|ms-|2021.12.2 jupyter|ms-|2021.11.1001550889 jupyter-keymap|ms-|1.0.0 jupyter-renderers|ms-|1.0.4 remote-containers|ms-|0.209.6 remote-ssh|ms-|0.70.0 remote-ssh-edit|ms-|0.70.0 remote-wsl|ms-|0.63.13 vscode-remote-extensionpack|ms-|0.21.0 cmake-tools|ms-|1.9.2 cpptools|ms-|1.7.1 cpptools-extension-pack|ms-|1.1.0 vscode-typescript-next|ms-|4.6.20220101 java|red|1.2.0 cmake|twx|0.0.17 clang-format|xav|1.9.0 markdown-all-in-one|yzh|3.4.0 vscode-proto3|zxh|0.5.5 (1 theme extensions excluded)

A/B Experiments

``` vsliv368:30146709 vsreu685:30147344 python383:30185418 vspor879:30202332 vspor708:30202333 vspor363:30204092 pythontb:30283811 pythonvspyt551cf:30345471 pythonptprofiler:30281270 vshan820:30294714 vstes263:30335439 pythondataviewer:30285071 vscod805cf:30301675 pythonvspyt200:30340761 binariesv615:30325510 bridge0708:30335490 bridge0723:30353136 vsaa593cf:30376535 pythonvs932:30410667 vscop804:30404766 vs360:30404995 vsrem710:30416614 vscexrecpromp3t1:30407762 ```

[ArturoDent]

I can't reproduce this on W11, it works as expected. Did you try with all extensions disabled?

And what is Ctrl+rightArrow bound to? Open the Keyboard Shortcuts editor and click the keyboard icon to the right and type Ctrl+rightArrow.

Or run the command Developer: Toggle Keyboard Shortcuts Troubleshooting and report the result.

[yncat]

@ArturoDent Thank you for your comment.

The --disable-extensions option does not seem to change the behavior here.

ctrl+rightArrow's binding is like this: cursorWordEndRight, Control+RightArrow, DefaulttextInputFocus && !accessibilityModeEnabled

Accessibility mode is enabled here since I'm a screen reader user. Could it be causing the difference?

[alexdima]

@yncat Yes, the word navigation commands (ctrl+right, ctrl+left, ctrl+shift+right, etc.) are not bound in the editor when accessibility mode is enabled. IIRC the problem was that VS Code's word navigation would not be 100% equal to what screen readers would expect. This would confuse screen readers and which would then pronounce only parts of a word, or skip certain symbols, etc. The solution we came up with was to unbind our word navigation commands, let ctrl+right fall through to the browser's (Chromium's) implementation and then we would figure out where it decided to move the cursor and then move our cursor there. However, this approach only works for a single cursor because native <textarea>s do not support multiple cursors. You can read more about the discussions in https://github.com/microsoft/vscode/issues/90578.

If you'd like for the editor's word navigation commands to be bound even when accessibility mode is enabled, you can add the following rules to your keybindings.json file (F1 > Preferences: Open Keyboard Shortcuts JSON):

{ "key": "ctrl+right",       "command": "cursorWordEndRight",       "when": "textInputFocus" },
{ "key": "ctrl+shift+right", "command": "cursorWordEndRightSelect", "when": "textInputFocus" },
{ "key": "ctrl+left",        "command": "cursorWordLeft",           "when": "textInputFocus" },
{ "key": "ctrl+shift+left",  "command": "cursorWordLeftSelect",     "when": "textInputFocus" },

Please let us know if that works.

cc @isidorn

[yncat]

@isidorn

Hi.

I've tested with the ctrl+left/right bound to the vscode command, and it now works as expected.

As described above, NVDA speaks incorrect locations when moving cursor. But it's not a big problem at least for me. Even with the chromium implementation, what NVDA reports after jumping between words are not always reliable, and I already have alternatives to correctly position myself. I have braille as well.

I think that the default keybindings (unbind when accessibility mode is enabled) should stay at the moment since the vscode commands might confuse starter users due to the reason above, and it's not easy to cross the chromium DOM and custom implementation borderline for settling the behavior.

My own problem has been resolved, although it's still not possible to use secondary cursors + word selection with default settings under accessibility mode. I'm 100% OK to close this one as my personal question, but not sure if I should do so since the issue still exists logically. Please feel free to keep or close this thread based on your team's policy.

I'm no longer able to work without vscode. I always appreciate the continuous accessibility support!

[isidorn]

@yncat thanks for providing this feedback, and we are glad you are happily using VS Code.

As for the default behaviour I would prefer to leave it as it is, even though it might not work best for you. The reason is that for most users it is confusing if the correct word does not get read out. For more details this issues has quite some passionate discussions :) https://github.com/microsoft/vscode/issues/90578

For now I suggest that we leave this issue open to see if more users feel the same way @yncat does and then maybe we can consider to change something. And if nothing comes up we can close it.

[Yi-Z0]

For a long time, I have encountered a similar problem. In the multiple selection mode, pressing Shift + arrow will lead to the loss of all cursors, which will not be encountered in IDEA and sublime text. The reproduction method similar to the above is to change Ctrl + arrow to shift + arrow

(1) Open an empty document. (2) Enter numbers 1 to 10 on each line as an example. (3) Press ctrl+a for selecting all, then press alt+shift+i to place cursors. (4) Press home to move cursors to the top of each line. (5) Press ctrl+right arrow shift+ right arrow.

Expected: Cursors select first character. Happening: All secondary cursors disappear.

I tried to use --disable-extensions, and the results seemed consistent.

The loss of cursor is the biggest obstacle to my migration from sublime to vscode.

[isidorn]

@YouYII this sounds unrelated to the original issue imho

[Yi-Z0]

@YouYII this sounds unrelated to the original issue imho

Please forgive me, there is not much correlation, but the results are similar. I have done a lot of research, but it seems that no one has encountered the same situation as me

[alexdima]

@YouYII Please create a new issue

[isidorn]

Closing this issue as we have not received additional user feedback regarding the original issue. Thus no action items here. Thank you