Safari: textarea glyph layout goes stale after edits (caret/wrap desyncs from overlay)

[panphora]

Environment: Safari (desktop + iOS/iPadOS). Not reproducible in Chromium/Firefox.

Symptom: After incremental edits near a wrap boundary, Safari leaves the <textarea> glyph layout stale. Because OverType overlays the invisible textarea on the styled preview, the caret and wrapping visibly desync from the preview (the "hanging cursor", the word stays wrapped).

Repro (overtype.dev homepage, 2nd "WITH TOOLBAR" editor):

1. Click at the end of Use the toolbar or keyboard shortcuts:
2. Type x until the word wraps to the next line.
3. Press Backspace once.
4. The word stays on the next line and the caret hangs. Safari only.

Root cause: This is a Safari text-shaping cache bug, not line-break recalculation. Confirmed with console probes on the live editor:

• Forcing a full re-layout via textarea.value = textarea.value does not fix it.
• Toggling the wrap attribute (line-break invalidation) does not fix it.
• Toggling letter-spacing (glyph-shaping invalidation) does fix it.

So only something that invalidates text shaping clears the stale state.

Fix (implemented locally): a Safari-gated, requestAnimationFrame-coalesced nudge after edits: set letter-spacing: -0.001px !important inline, read offsetHeight to force a synchronous reflow, then remove it. Wired into handleInput and setValue, cancelled in destroy().

Note: the inline value needs !important because OverType's stylesheet pins letter-spacing: normal !important; the raw snippet without !important is a silent no-op.

Reported by a contributor, who also supplied the letter-spacing workaround.

[panphora]

Implemented in v2.4.0: a Safari-only, requestAnimationFrame-coalesced reflow nudge (letter-spacing: -0.001px !important + an offsetHeight read, then revert) on input and setValue clears the stale glyph layout, so the caret and word-wrap stop desyncing from the overlay.

Thanks to Matt Round (@mattround.com) for reporting it and supplying the original workaround.