EditContext: dead key not considered

[aiday-mar]

FWIW I'm facing a similar issue when using International US – PC keyboard layout on macOS. A particularity of this keyboard is that e.g. the ' key is a "dead key", meaning pressing it produces nothing, but it affects the next key I press (e.g. '+e produces é, '+<space> produces '). Anytime I use a "dead key", e.g. if I want to delete inside of a string (d+i+'+), it glitches and adds a 'char at the position of the cursor. Turning offexperimentalEditContextEnabled` does fix the behavior, the IME suggestion does not apply to me (AFAICT).

Originally posted by @aduh95 in #251518

[aiday-mar]

Hi @aduh95 thanks for commenting this on the other issue. Can I please ask you some questions to help me investigate this further?

• So to clarify are you pressing the key combination?

d + i + '

What is the expected output of such a combination using the keyboard you are using?

• can I ask you if you see this happening on the website: https://microsoftedge.github.io/Demos/edit-context/ ? This website shows a demo of the EditContext API and is a simplified version of the code that powers the VS Code input.
• Do you see this happening on the website: https://insiders.vscode.dev/ on your up-to-date chrome browser where the editor.editContext setting is enabled?

[aduh95]

• So to clarify are you pressing the key combination?

d + i + '

What is the expected output of such a combination using the keyboard you are using?

Expected behavior (well, VIM behavior): Nothing, it waits for the next keypress.

Actual behavior (VSCode with experimentalEditContextEnabled): Nothing, it waits for next keypress.

The difference in behavior only shows once I hit the next key (<space>):

Editor	Input	Output after d+i+'+<space>
VIM	this is a 'string'	this is a ''
VSC	this is a 'string'	''string'

• can I ask you if you see this happening on the website: https://microsoftedge.github.io/Demos/edit-context/ ? This website shows a demo of the EditContext API and is a simplified version of the code that powers the VS Code input.

Pressing ' does print out a ', however pressing the next key does replace ' with the expected char (e.g. if I press '+e, it first prints ' then replace it with é).

• Do you see this happening on the website: https://insiders.vscode.dev/ on your up-to-date chrome browser where the editor.editContext setting is enabled?

Yes it's the same behavior – although it underlines the temporary ', making it clear it understands it's a dead key.

[aiday-mar]

Thanks for the clarification. I have been investigating this issue and will write my findings here.

First of all why does this not happen when VIM is enabled?

Consider the video below. You can see that when VIM is disabled, the combination d+i+' is correctly inserted as expected. This is because when we receive the textupdate event, we update the editor synchronously thereafter. In this way when the _updateEditContext method is called, the EditContext is correctly updated from the text model state to:

EditContext {
   text :  "di'this is a 'string'"
   selectionStart: 3
   selectionEnd: 3
}

At this point, the EditContext and the TextModel are synchronized and hold the same state. So on the second text update event:

TextUpdateEvent {
   text: "'"
   updateRangeStart: 2
   updateRangeEnd: 3
   selectionStart: 3
   selectionEnd: 3
}

The correct typeInput event is sent:

TypeInput {
   text: "'"
   replacePrevCharCnt: 1
   replaceNextCharCnt: 0
   positionDelta: 0
}

This breaks down when extensions overwrite the Type and ReplacePreviousChar and CompositionType commands because on text-update event reception, the editor is updated asynchronously and the EditContext sends an event which does not correctly reflect the state within. Suppose VIM is enabled, then the sequence of events is as follows:

Since VIM does not insert text on typing di in the normal mode, when we type the quote, the EditContext state is the following initially:

{
text :  "this is a 'string'"
selectionStart :  0
selectionEnd :  0
}

Then we type a quote and it becomes

{
text :  "'this is a 'string'"
selectionStart :  1
selectionEnd :  1
}

Then the method _updateEditContext is called and the editContext state is reset to:

{
text :  "this is a 'string'"
selectionStart :  0
selectionEnd :  0
}

Then we press the space bar and the EditContext is incorrectly updated to:

{
text :  "'his is a 'string'"
selectionStart :  1
selectionEnd :  1
}

with the event:

TextUpdateEvent {
text: "'"
updateRangeStart: 0
updateRangeEnd: 1
selectionStart: 1
selectionStart: 1
}

Here you can see that the first T in the EditContext state has been replaced by a quote. Since the cursor position has not changed from where it was initially, the typeInput is incorrectly calculated as:

{
text: "'"
replacePrevCharCnt: 0
replaceNextCharCnt: 1
positionDelta: 0
}

I think it would be expected that on typing the space bar the EditContext text update event should instead be:

TextUpdateEvent {
text: "'"
updateRangeStart: 0
updateRangeEnd: 0
selectionStart: 1
selectionStart: 1
}

So that the typeInput would be calculated as:

{
text: "'"
replacePrevCharCnt: 0
replaceNextCharCnt: 0
positionDelta: 0
}

In the following I will discuss why this happens and ways to circumvent this.

Screen.Recording.2025-06-23.at.15.46.59.mov

Screen.Recording.2025-06-23.at.15.57.23.mov

[aiday-mar]

Why does this happen?

It is currently unclear why this happens, but it could be argued that this happens because during a composition the EditContext state should not be updated, otherwise it can break the following events sent by the EditContext. I will file an issue to the chromium team and discuss this.

But why do we update the EditContext on typing?

This happens because extensions which overwrite the type command and the like, may not directly insert the text as the editor does by default. When you type j in the normal mode of VIM, the cursor moves down once, j is not actually inserted and the EditContext needs to reflect this, so it is updated to reflect the actual editor state.

So what are the solutions?

1. Make the commands execution always synchronous

This would be the most rigorous solution as it would guarantee we would never encounter issues with asynchronicity, and our input should always be correct. Not sure if this is possible to do.

2. Avoid using the EditContext when in composition mode

This defeats the purpose of the EditContext

3. Ask chromium to address the text update event

It could be argued that the behavior is something that chromium could improve. I have filed an issue here which serves as a discussion thread: https://issues.chromium.org/issues/427187160. I will wait for the input from the developers.

4. Do not update the edit context on composition

This item would be to not update the edit context on composition so that the events sent are correct (with respect to their knowledge of the state). This could imply that extensions that override the composition command, so not VIM, could break.

If we do this we would have:

editContext.ontextupdate((e) => {
   const typeInput = calculateTypeInput(currentPrimarySelection, e)
   sendInput(typeInput)
   if (!isComposing) {
      this.updateEditContext()
   }
})

But because the edit context no longer correctly reflects the editor state, to calculate the typeInput we will have to use a new variable previousEditContextSelection which represents the hypothetical EditContext selection (which is not currently reflected in the editor and which would be our primary selection if the operation was synchronous) in order to calculate the future typeInput:

editContext.ontextupdate((e) => {
   const typeInput = calculateTypeInput(previousEditContextSelection, e)
   sendInput(typeInput)
   if (!isComposing) {
      this.updateEditContext()
   } else {
      this.updatePreviousEditContextSelection(e)
   }
})

And updateEditContext should also call updatePreviousEditContextSelection when the editor view is rendered as follows:

private updateEditContext() {
    if (this.isComposing) {
         this.updatePreviousEditContextSelection()
         return
   }
   // update edit context state
   this.updatePreviousEditContextSelection()
}

This implementation is currently leading to some other issues. Namely, since the edit context is not update during composition, when the composition is correctly inserted, and the selection is changed (generally to be at the end of the composition), this is not reflected in the EditContext and the following EditContext typing events are not correct. When you type for example センセイ the selection start will initially be 0 and the selection end will be 4 from the initial text-update event. After inserting the text, the new bounds should be 4 and 4, but this is not reflected in the EditContext so the following typeInput events will be incorrect.

This implementation can be seen here : #252185. This implementation updates the Edit Context differently when we are in composition mode and when we are not. When in composition mode it only updates the selection bounds if the text is the same. When not in the composition mode, it updates everything regardless. This could mean that extensions which overwrite the CompositionType command may break because the EditContext is not updated correctly on their execution.

[aiday-mar]

I believe I have found a fix for this issue here: #252221. I will monitor if there are any other further regressions from this PR in the coming days on insiders.