> Why some Chrome editors hide your keystrokes (and how TextSwitcher 1.2 handles it)

Plain inputs in a browser behave like native text fields: tools on macOS can ask what was typed and where the cursor is. Modern web apps often use something else — a contenteditable element managed by a JavaScript editor framework.

> What goes wrong

In Chromium-based browsers, some contenteditable editors don’t emit the usual text events or report the surrounding text through macOS Accessibility. From the outside, a keyboard utility sees keys being pressed but cannot reliably read back the word that was produced. Earlier TextSwitcher versions could miss characters in such fields, for example in Asana comment boxes.

> What changed in 1.2.0

• TextSwitcher reconstructs missing characters from physical keystrokes when a Chromium contenteditable editor does not provide normal text events.
• Space now reliably completes the current word and triggers correction in these editors.
• Safety checks for secure fields, active selections and unsupported input methods remain in place.

> If a field still misbehaves

Editors differ, and some apply their own autocorrect or formatting on space. If corrections fail in a specific web app, check the troubleshooting page and send the app name, browser version and TextSwitcher version — it is the fastest way to get that editor covered.