microsoft / microsoft/monaco-editor

[Bug] Find Widget sometimes causes editors to permanently stop responding to inputs of 'a' or 'h'

Open
#5,178 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
46.8k
Forks
4.1k
Avg merge
17h 58m
Merged PRs (30d)
1

Description

Reproducible in vscode.dev or in VS Code Desktop?
  • Not reproducible in vscode.dev or VS Code Desktop
Reproducible in the monaco editor playground?
Monaco Editor Playground Link

I am unable to reproduce this in the playground, only in my local project with the editor installed via npm and webpack. This appears to be a regression, however, as I tried reproducing it with different versions installed, and found that it's not reproduced up to version 0.52.0, and starts being reproduced in version 0.53.0 and later.

Monaco Editor Playground Code
n/a
Reproduction Steps

It's hard to pinpoint the exact steps, as I can only reproduce it in my local project, a Chrome browser extension dev tools panel that I'm developing. It's possible that it's an issue specific to a dev tools panel context. It also doesn't happen every time, but it's fairly reliable to reproduce with these steps, even with no editor features specified and a language of 'plaintext':

  1. Load the page.
  2. Within the page, cause the editor to be created dynamically.
  3. Focus the editor.
  4. Open the Find widget (Ctrl+F).
  5. Click back into the editor and attempt to type into it.
Actual (Problematic) Behavior

Most characters still get typed (or bring up the "Cannot edit in read-only editor" tooltip) as normal, but for some reason, just the letters a and h will stop producing any response from the editor. Only the lowercase characters. The uppercase ones still work as normal. Pasting the characters also works as normal. It's as if there is a keydown event listener on the editor that blocks the event if its key code is KeyA or KeyH with no modifiers.

Before opening the Find widget, these characters work as normal. But once the issue starts, then for as long as the page is loaded, all editors permanently stop responding to those key inputs, whether the Find widget stays open or not. Outside of the editor, and even for the Find widget itself, the keys continue to work as normal.

Also, it seems that if opening the Find widget the first time doesn't cause the issue, it probably won't occur at all, and I have to reload the page to try to reproduce it again.

Expected Behavior

Naturally, the a and h keys should always work as normal for the editor, and not stop working after opening the Find widget, or for any other reason.

Additional Context

A workaround is to add a keydown event listener to each created editor that stops propagation of the event if its key code is KeyA or KeyH with no modifiers, but I can't be sure of the full implications of this or if it might have unintended side effects:

editor.onKeyDown((e) => {
  const isAorH = e.keyCode === monaco.KeyCode.KeyA || e.keyCode === monaco.KeyCode.KeyH;

  if (isAorH && !e.ctrlKey && !e.shiftKey && !e.altKey && !e.metaKey) {
    e.stopPropagation();
  }
});

Another workaround is to downgrade to version 0.52.0 or earlier.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Find widget and editor keyboard-event handling in a dynamically created editor inside the reported Chrome extension dev-tools panel. Compare versions 0.52.0 and 0.53.0 while reproducing the first Find-widget interaction. Done means lowercase a and h continue working in the editor after the widget is opened, without affecting other input behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript, webpack
Domain
frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.