suggestion menu should not automatically select the first suggestion

[alexch]

VS Code version: Code 1.30.2 (61122f8, 2019-01-07T22:48:31.260Z)
OS version: Darwin x64 17.7.0

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz (4 x 1800)
GPU Status	2d_canvas: unavailable_software checker_imaging: disabled_off flash_3d: unavailable_software flash_stage3d: unavailable_software flash_stage3d_baseline: unavailable_software gpu_compositing: unavailable_software multiple_raster_threads: unavailable_off native_gpu_memory_buffers: unavailable_software rasterization: unavailable_software video_decode: unavailable_software video_encode: unavailable_software webgl: unavailable_off webgl2: unavailable_off
Load (avg)	2, 3, 3
Memory (System)	4.00GB (0.04GB free)
Process Argv	.
Screen Reader	no
VM	0%

Extensions (3)

Extension	Author (truncated)	Version
vscode-eslint	dba	1.8.0
dotenv	mik	1.0.1
vsliveshare	ms-	0.3.1151

Steps to Reproduce:

1. open a JS file
2. type cy.get( at a rate sufficient for the suggestion menu to appear
3. notice that crypto.getRandomValues( appears instead

Does this issue occur when all extensions are disabled?: Yes

---

In JavaScript, when I type cy.get( and then look at the screen I should see cy.get(. Instead I (sometimes!) see crypto.getRandomValues( instead.

This is an #a11y issue; the suggestion menu should not select or fill anything until/unless I press ↓ while it's up. Any setting that takes control away from the user and types extra characters that they did not intend is a bad default setting, and the fact that this behavior is timing-dependent is even more maddening.

I note that similar bugs have been reported before and not fixed. Please reconsider. I teach programming classes and in every class so far, the majority of students find this behavior astonishing and frustrating; power users who prefer it should be competent enough to change a setting to their preference, but (I repeat) the default behavior of a text editor should be to faithfully enter the keys that were typed.

A common answer to this problem is to disable the acceptSuggestionOnCommitCharacter and/or acceptSuggestionOnEnter settings, but this bug is really about the default values of those settings being wrong for most users.

Also, the editor.acceptSuggestionOnCommitCharacter setting sounds like it's intended to type the selected suggestion and a dot when I press ↓., which is actually desirable behavior; the advice to disable editor.acceptSuggestionOnCommitCharacter is more of a workaround than a solution since it disables .-to-accept in all cases, not just this overly-aggressive autocomplete scenario.

Is this issue sufficient to track both the fact that this setting is wrong by default, and that you might need a new setting e.g. "automaticallySelectFirstSuggestion" (which should also be false by default)?

Related issues:

• Every time I type next( VS Code will replace it with INSPECT_MAX_BYTES( #41641
• Pressing . selects the first option in the context menu even before it's opened #66868
• [Accessibility]A11y_VSCode_Editor_Keyboard: On tab keypress, the first item of suggestion automatically gets selected. #52444
• https://twitter.com/joshwcomeau/status/1035947291813720064
• https://stackoverflow.com/questions/51199397/vscode-editor-accepting-suggestions-on-typing-parenthesis
• https://www.reddit.com/r/vscode/comments/7acy1y/disable_period_autocompleting_intellisense/

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Implement Intellisense Suggestion Mode (#33725)

[jrieken]

the suggestion menu should not select or fill anything until/unless I press ↓ while it's up.

I disagree with that. Selecting the best match is good and forcing people to down arrow slows down everything.

[alexch]

@jrieken You are free to disagree, but please respect my experience and observations. The current behavior is observably, empirically confusing and flow-breaking for a majority of my students, as well as many bug-reporters and SO-question-askers. If you want to speed things back up (and risk the insertion of bogus code which you might then need to break your train of thought to correct), then you should be free to toggle the aggressive autoselection back on.

By default, a suggestion should be just that: a suggestion, not a decision.

[mjbvz]

It sounds like the root problem is that commit characters are sometimes unreliable for js. Typing the same sequence of characters should theoretically always result in the same text being inserted. Disabling commit characters makes the behavior more repeatable.

When typing cy., if you type . before suggestions are shown, we do only insert cy. instead of crypto.. Not sure if there's anything we can do about this since we don't want suggestions to block typing

[alexch]

Not sure if there's anything we can do about this since we don't want suggestions to block typing

I was with you up to this point. Suggestions dont block typing; instantly selecting the first suggestion does -- or at least it sets it up so the next "commit character" inserts characters that the typist does not intend. My proposed solution is to bring up the suggestion menu exactly as it is now, but to **not** select any item in the menu until the user actively presses the down arrow key (or moves the mouse cursor over it). This is how most GUI menus work, including menu bar menus and right-click popup context menus.

It sounds like the root problem is that commit characters are sometimes unreliable for js.

I think the commit characters are probably reliable once the suggestion popup appears, but the timing of that popup is variable (based on individual typing rate and various other sources of lag), which makes typing unreliable.

[jrieken]

/duplicate of #33725

[vscodebot]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!