Test: Edit Context API Adoption

[aiday-mar]

Refs: #207700

• macOS @rebornix (windows if time)
• linux @rzhao271
• windows @Tyriar (macos if time)

Complexity: 5

Authors: @aiday-mar @hediet

Create Issue

Create Issue

---

This iterations we have merged our work on the adoption of the EditContext API in VS Code. To give context, the EditContext is an optional property on an HTML element that decouples keyboard inputs from the HTML element. In this manner all keyboard events are sent through the EditContext and no longer directly mutate the corresponding DOM elements. This decoupling has allowed us to simplify the code that powers the core editing experience, and has fixed numerous IME bugs. If interested, you may find more information concerning the EditContext API here and here.

With this EditContext work, essentially you should not see any difference in your editing experience in VS Code. Verifying this is the core goal of this TPI. There are several specific points that require testing: Simple Editing, Composition, Accessibility. Follow the following steps:

Preparation

• Enable the setting editor.experimentalEditContextEnabled, reload the window

Simple Editing

• Open different inputs in VS Code that accept text and are backed by the EditContext API: the editor (main part to test), the SCM view input, the extensions input etc. To verify if an input is backed with the EditContext, you may go into the dev tools and verify that the input element is nested within a div with classname view-lines (meaning the input is nested within the ViewLines class). Verify:
  • You can type/update text correctly in the input
  • You can use your keyboard shortcuts correctly
  • There are no focus issues
  • There are no UI issues such as flickering
• Search for some corner cases that could break the core editing experience. Previously for example it has been found that the Edit Context did not support line wrap correctly and it broke VS Code Neovim's typing shortcuts.

Composition

• Choose a language that makes the Input Method Editor appear for composition purposes (for example Japanese or Arabic or Emoji).
• Setup your machine to type text in this language. You may have a look at the following Wiki page which describes how to setup IME for Japanese/Chinese/Korean on various operating systems. The EditContext has already been tested partially with these languages, and it would be good to test with a wide variety of languages.
• Open different inputs in VS Code that accept text and are backed by the EditContext API: the editor (main part to test), the SCM view input, the extensions input etc. To verify if an input is backed with the EditContext, you may go into the dev tools and verify that the input element is nested within a div with classname view-lines (meaning the input is nested within the ViewLines class).
• Type in that input with your chosen language, interact with the IME and generally verify that:
  • Text is inserted/updated correctly
  • The IME window is positioned correctly (generally below your cursor)
  • There are no UI issues such as flickering of the text
• Search for some corner cases that could break the core editing experience. Previously for example it has been found that when you'd cycle through IME suggestions in Japanese with Google IME, this would incorrectly update the text in the editor.

Accessibility

• Setup a screen reader depending on your operating system:
  • MacOS: One screen reader you can use is VoiceOver. You can find the user guide here. VoiceOver should be inbuilt into MacOS and just needs to be activated.
  • Windows: One screen reader you can use is NVDA. You can find the download link here and a user guide here.
  • Linux: One screen reader you can use is Orca. You can find the downloads here. You may have to create an account as per here. There is a user guide here.
• Toggle the Accessibility mode within VS Code using the command editor.action.toggleScreenReaderAccessibilityMode
• For different inputs that accept text insertions, verify that the screen reader experience with the setting enabled is the same as with the setting disabled. In particular:
  • Type text and verify the screen reader correctly announces text added/updated
  • You are able to navigate within the input and hear the correct accessibility text/cues
  • You can correctly use the screen reader shortcuts both with the setting enabled and disabled
• Search for some corner cases that could break the core editing experience. Previously it has been found for example that the Narrator screen reader does not read the current active line as you navigate from line to line.

Known bugs:

• When using the french keyboard, when you long-press E, this adds an accented E incorrectly at the beginning of the line issue
• When you open the settings panel, then the keyboard shortcuts view and you type into the keyboard shortcuts input, no text is inserted. In fact it is inserted into the settings input. The corresponding issue is here. This also happens sometimes when moving from the inline chat into the panel chat input. In fact generally it would seem that the EditContext does not handle focus correctly sometimes! If you type and do not see an input, and notice text is inserted elsewhere, then this could be an EditContext bug. Please read below for a way to verify this.

Both issues above stem from upstream chromium issues that should be resolved next iteration when we upgrade to electron 32. Some of the bugs you find could be related to chromium bugs for which we don't have a fix in yet since we are on electron 30. To verify if a bug is a chromium bug you can open vscode.dev on your up-to-date chrome browser. If it no longer reproduces it is likely a chromium bug. If you encounter this on VS Code on the Desktop, you can reload the window, and the focus should be restored correctly.

[rebornix]

It works pretty good in overall and some of the issues we ran into before are gone, great work!

The two main issues I ran into are

• The positioning of IME widget seems a bit more flaky than before IME editor position is non-deterministic when triggered from outside the viewport #229577. I don't always reproduce, but sometimes while typing in text editor, it can be positioned randomly.
• For Chinese, we don't want the ASCII characters we use to compose words to be included in the undo/redo stack. This is a regression from the previous approach. For IMEs using radical composer (like Korean) it might make sense though.

[Tyriar]

I'm doing some testing on my macbook today focusing on Korean/Japanese, will do more testing on Windows tomorrow. So this TPI will remain open for an extra day.