MCP Browser Automation: Why Rich-Text Editors Fail Silently

That’s easier than it sounds, because these text boxes leave a handle to themselves right there on the page. For the Lexical kind (the boxes behind LinkedIn, Meta, and Shopify), the code below grabs that handle and hands the box its new text directly — no faking involved:

const editorEl = document.querySelector('[data-lexical-editor="true"]');
const editor = editorEl.__lexicalEditor;
const newState = editor.parseEditorState(lexicalJson);
editor.setEditorState(newState);

ProseMirror (the box behind Notion and Atlassian) works the same way, just through a different handle called pmViewDesc; this snippet reaches it and inserts the text through the editor’s own change system:

const view = editorEl.pmViewDesc.view;
const tr = view.state.tr.insertText(text, view.state.selection.from);
view.dispatch(tr);

Draft.js — an older one that’s officially retired but still lurking in GitHub, Reddit, and some older Facebook screens — hides its handle a little deeper, inside React’s own internal map of the page (a technique called “Fiber walking”), but the idea is identical.

Notice what none of these do: none of them fake an event. The text box changes its own text directly, the page redraws the way it normally would, the box’s own rules stay intact, and — crucially — the pop-up stays open because your cursor never left it, so there’s no focusout to trigger Boundary 1.

And this isn’t some fragile trick. These are the exact same controls the text box’s own features rely on — its plugins, its autosave, its undo and redo. They aren’t written up in the official manual, but they’re rock-solid: the sites themselves have leaned on these same controls in production for years.

The table is a compatibility checklist, not a frequency study. Lexical, ProseMirror, Tiptap, Draft.js, and Slate.js need editor-specific testing, while code editors and plain inputs follow different event paths. In every case, read the saved value back before reporting success.

For a real benchmark, record the editor and browser versions, the exact fill method, the value written, the value read back after save, the failure mode, and the time spent retrying. Run the same protocol on every surface and publish the raw observations. Until then, describe compatibility as tested or untested rather than attaching a success percentage.

The operational rule is simpler: after writing, read the saved content back from the application. If the target uses Lexical, ProseMirror, Tiptap, Draft.js, or Slate.js, test the editor’s own command path instead of assuming synthetic typing worked.

If you want the wider engineering picture — why these failures pile up across a chain of automated steps and how to keep an eye on them — see our n8n vs Make vs Zapier comparison, which looks at how well each tool lets you see what’s actually happening.

If you’re shopping for a browser-automation tool (an MCP server) to let your AI create content, don’t take the marketing at face value — put it through these four tests, which are exactly the cases that tend to break:

1. Can it post to LinkedIn when the AI is told to?
2. Can it write a multi-line comment on a GitHub pull request and actually submit it?
3. Can it fill in a Notion page with text that has formatting, not just plain words?
4. Can it open a JIRA ticket with a real, formatted description rather than bare text?

If any of these quietly fails — it reports “success” but the app shows nothing — you’ve caught one of the three safety features blocking the tool.

Editor frameworks and their public deployment footprint

What the pattern tells us: of the 8 tools above, 6 turn away fake typing on purpose (Lexical, ProseMirror, Tiptap, Draft.js, Slate.js, and Quill in part), and 2 let it through (Monaco, CodeMirror). That split isn’t a coincidence. The 6 that refuse are all publishing boxes — the kind where you write things you’re about to share, so they assume a hostile script might try to slip in content. The 2 that accept are code boxes, built for developers, where the assumption is you’re using your own tools.

Safari MCP is free and open source (under the MIT license), you start it by running npx safari-mcp, and it works with Claude Code, Cursor, VS Code, Windsurf, Claude Desktop, and any other MCP-compatible AI on a Mac.

Every serious browser-automation tool is going to have to crack this sooner or later — these fancy text boxes are simply too common to keep leaving them as a place where things fail in silence. Until then, if you’re staring at “the AI says it worked but nothing got posted,” the three safety features above are the first place to look.

To see where these automations actually earn their keep in a business, read our WhatsApp Business automation guide and the wider business automation framework, which cover how to build these result-checks right into your workflows. And for more on designing AI-driven systems, see our deep-dives on AI agents for business, AI in business overview, and Safari MCP browser automation.

Boundary 2 above describes editors that reject synthetic events by testing event.isTrusted. The natural conclusion — the one I reached myself, and acted on for far too long — is that such a control needs a real OS-level click, and that the fix therefore lives in CGEvent, accessibility AXPress, or some other native-input layer.

That conclusion is wrong for React controls, and it is an expensive wrong turn.

React does not attach your onClick to the DOM node. It keeps handlers in its own internal tree — the Fiber tree — and dispatches them through a synthetic event system of its own. An automation tool that walks to the element’s Fiber node and invokes the stored onClick directly is making a function call, not a DOM event. There is no event object for a guard to inspect, so an isTrusted check never runs at all. The guard is not defeated; it is simply never reached.

Worked example (verified August 25, 2026). Adding a use case to an app in Meta’s Business Settings: every raw synthetic click I dispatched opened the dialog and ticked the checkboxes, but the Save button silently did nothing — the classic Boundary 2 signature. No native click was needed. A Fiber-path click saved the record, confirmed by reloading the page and seeing the use case listed as active.

What this changes about the diagnosis

The ordering that has served me best: Fiber-path click → precise element reference → only then consider native input. On macOS 26 that last step is largely theoretical anyway, since CGEvent synthetic clicks are a no-op under the current input-security model — another reason not to start there.

The broader point for anyone evaluating MCP browser tools: “does it send a trusted event?” is the wrong question. The right one is “does it reach the handler the framework actually registered?” A tool that understands the framework’s event system beats one that tries to look more human to the DOM. The isTrusted wall in Boundary 2 is real, but for React it is usually a wall with a door next to it.

• Lexical editor state — official architecture doc — Meta’s own explanation of how the box stores its text
• Lexical commands API — the official, approved way to talk to the box
• ProseMirror state & transactions — why simply setting .value = never reaches this kind of box
• Tiptap (built on ProseMirror) — editor.commands.setContent — the recommended command for changing its text
• Draft.js EditorState — Facebook’s now-retired text-box tool (still living on inside JIRA)
• InputEvent.isTrusted spec (W3C DOM) — the truth badge that lets a box reject fake typing
• Model Context Protocol (MCP) spec — Anthropic’s open standard for letting AI use tools
• Chrome DevTools Protocol — Input.dispatchKeyEvent — Chrome’s closest equivalent for sending keystrokes
• Safari MCP project — the LinkedIn (Lexical) and Notion (ProseMirror) fill paths described above