Summary
The exported Editor component loses DOM focus after the first keystroke when used standalone. Only one character can be typed; subsequent keystrokes are discarded until the user clicks back into the editor.
LiveProvider + LiveEditor is unaffected, so this only bites consumers using the standalone Editor export.
Version
react-live@4.1.8 (reproduced against the published package, not a local build).
Reproduction
import { Editor } from "react-live";
<Editor code="abc" language="javascript" onChange={() => {}} />;
Click at the end of the text and type XYZ.
Expected: abcXYZ
Actual: abcX, and document.activeElement is <body>
Automated reproduction
Driving the above page with Playwright:
| case |
typed |
result |
document.activeElement |
<Editor> standalone |
XYZ |
abcX |
BODY |
<LiveProvider> + <LiveEditor> |
XYZ |
abcXYZ |
PRE |
Same outcome with 30ms and 250ms between keystrokes, and still BODY after a 1.5s pause.
A human tester saw a slightly different variant — two characters landed, then typing became possible again after a pause — so the exact cut-off may be timing dependent, but the first keystroke reliably drops focus.
Notes from debugging
- The
<pre> element is not replaced: it is the same node before and after (sameNode: true, isConnected: true).
- A real
blur event fires on it.
- Calling
.focus() on the same element afterwards restores normal typing, so the component is otherwise healthy.
use-editable restores focus in a useLayoutEffect, but only when it has a recorded position (if (e.position) { a.focus(); ... }).
- The working
LiveProvider path produces an extra re-render when its async transpile resolves, which appears to be what re-runs that layout effect. Standalone Editor has no such second render.
This suggests the standalone case depends on a re-render it does not reliably get, rather than the blur itself being intentional.
Related
Summary
The exported
Editorcomponent loses DOM focus after the first keystroke when used standalone. Only one character can be typed; subsequent keystrokes are discarded until the user clicks back into the editor.LiveProvider+LiveEditoris unaffected, so this only bites consumers using the standaloneEditorexport.Version
react-live@4.1.8(reproduced against the published package, not a local build).Reproduction
Click at the end of the text and type
XYZ.Expected:
abcXYZActual:
abcX, anddocument.activeElementis<body>Automated reproduction
Driving the above page with Playwright:
document.activeElement<Editor>standaloneXYZabcXBODY<LiveProvider>+<LiveEditor>XYZabcXYZPRESame outcome with 30ms and 250ms between keystrokes, and still
BODYafter a 1.5s pause.A human tester saw a slightly different variant — two characters landed, then typing became possible again after a pause — so the exact cut-off may be timing dependent, but the first keystroke reliably drops focus.
Notes from debugging
<pre>element is not replaced: it is the same node before and after (sameNode: true,isConnected: true).blurevent fires on it..focus()on the same element afterwards restores normal typing, so the component is otherwise healthy.use-editablerestores focus in auseLayoutEffect, but only when it has a recorded position (if (e.position) { a.focus(); ... }).LiveProviderpath produces an extra re-render when its async transpile resolves, which appears to be what re-runs that layout effect. StandaloneEditorhas no such second render.This suggests the standalone case depends on a re-render it does not reliably get, rather than the blur itself being intentional.
Related