[Bug] Typing over a right-to-left selection requires two keypresses on the textarea input path (Safari)

[hampuskensing]

Reproducible in vscode.dev or in VS Code Desktop?

• Not reproducible in vscode.dev or VS Code Desktop

Reproducible in the monaco editor playground?

• Not reproducible in the monaco editor playground

Monaco Editor Playground Link

https://microsoft.github.io/monaco-editor/playground.html?source=v0.55.1#XQAAAAICAQAAAAAAAABBqQkHQ5NjdMjwa-jY7SIQ9S7DNlzs5W-mwj0fe1ZCDRFc9ws9XQE0SJE1jc2VKxhaLFIw9vEWSxW3ysco-iJCSRK8nIoiS4wMbjFnXNl4LX5igx6X8QIcEllX0iI5qgqdEVxhFi3SE4vdq32FXGUPguYpi5DzECfR2tBaku29uszXsgCU5ChsI1iZmVYiC7TXr5t9zpYGw8J0341ekxQXsd6ciJwusQXyWt1gQ1AERoo50BnooqTzYhvOLKD3czhnGJdXpyI7GhRizGFFF-tbak_DJx6j8oev_7lP4AA

Monaco Editor Playground Code

monaco.editor.create(document.getElementById("container"), {
  value: "const U = 19.05;",
  language: "typescript",
  editContext: false, // Safari's path; omit this and use Safari instead
});

Reproduction Steps

Reproduces in any Chromium browser, which should make it easy to debug:

1. Open the playground
2. Click to place the caret at the very end of the line (right of ;).
3. Press Shift+Left once — ; is selected, backwards.
4. Press a once.

Then repeat with a right-to-left mouse drag, and with several characters
selected; the behavior is the same in all cases.

In Safari, do the same with default options (no editContext override).

Actual (Problematic) Behavior

Nothing happens. The selection remains and no text is inserted. Pressing a
a second time replaces the selection.

Expected Behavior

; is replaced, giving const U = 19.05a.

Additional Context

This affects Safari with default editor options, because Safari has no
EditContext support and therefore uses the legacy textarea input path
(editContextSupported: typeof globalThis.EditContext === 'function' is false).
The bug is not Safari-specific in nature: forcing the same path in Chromium with
editContext: false reproduces it there too, which suggests the problem is in
the textarea input pipeline rather than in WebKit.

Setting accessibilitySupport: "off" works around it completely. That switches
getScreenReaderContent() from SimplePagedScreenReaderStrategy to the macOS
branch that mirrors the selected text into the textarea and selects it
(new TextAreaState(text, 0, text.length, selection, 0) in
textAreaEditContext.ts), so the native replacement happens without any state
diffing. That points at the paged screen-reader content path as the source of
the problem, but it is not an acceptable general fix since it disables screen
reader support.

[scenerecap]

Reproduced on the playground link with v0.55.1 (2026-08-21, Chromium 151, 1280×720, editContext: false):

1. Open the playground URL from this issue.
2. Click Run to render the Monaco instance in the Preview pane.
3. Click past the end of const U = 19.05; to position the cursor after the semicolon.
4. Press Shift+Left — ; is selected backward.
5. Press a once → nothing happens; the selection stays and no text is inserted.
6. Press a again → the selection is replaced, giving const U = 19.05a.

Also reproduces with editContext: false omitted when using Safari, since Safari falls back to the textarea path by default.

Recording with timestamps: https://scenerecap.com/s/j6rfrakksh