Phenomenon
A subtle but annoying interaction bug exists on macOS across all browsers when using rich text editors (like ProseMirror or Lexical). macOS has a system-level feature that replaces two spaces with a period and a space (. ). When this happens at the boundary of a “Mark” (like Bold or Code), the browser’s textInput or beforeinput replacement logic often uses the attributes of the logical start of the replacement range. If the mark is inclusive: false (meaning it shouldn’t expand to new characters), the auto-inserted period incorrectly “steals” the bold style.
Reproduction Steps
- Use a macOS device with “Add period with double-space” enabled in Keyboard settings.
- In a rich text editor, create a bold word. Ensure the bold mark configuration is non-inclusive on the right.
- Type a single space (it should be plain text).
- Type a second space.
- Watch the period appear.
Observed Behavior
- Mark Expansion: The period becomes bold, extending the bold range unexpectedly.
- Selection Desync: In some internal models, the replacement causes the editor to lose track of whether the caret is inside or outside the mark node, leading to “sticky” formatting for the next sentence.
Impact
- Formatting Pollution: Users have to manually select and un-bold the periods at the end of every sentence.
- Inconsistent Document Model: Programmatic checks that expect punctuation to be outside marks will fail.
Browser Comparison
- macOS / Any Browser: Affected, as it is a system-level replacement event.
- Windows / Chrome: Not affected (different auto-correct engine).
References & Solutions
Mitigation: Event Interception
Modern editors must explicitly handle inputType: "insertReplacementText" to detect the macOS period shortcut and manually apply the “Plain Text” schema to the resulting range.