TL;DR

I couldn't post to LinkedIn from my MCP server. Not "sometimes fails" — never works. I assumed one bug. I was wrong. I found three, stacked, and each one looked like success to every automation tool I tried. Here is the anatomy of why your agent's "I posted it!" lies to you when a rich-text editor sits inside a dialog.

The symptom

I ship Safari MCP — an MCP server that drives the Safari you are already logged into. 80 tools. safari_fill is the most-used one. For three months it worked everywhere — Gmail, GitHub, Ahrefs, Google Docs, Shopify admin.

Then I tried posting to LinkedIn from an agent.

> agent: safari_fill({text: "Shipping v2.9.0 — modal detection in snapshot!"})
< result: "Filled. 67 chars."

Except the LinkedIn composer was empty. And closed. And I had a cursor in my address bar.

Three hours later I had a list. Three separate boundaries, each silently sabotaging the one before it.

Boundary 1: focusout dismisses the dialog

LinkedIn's composer is a <div role="dialog">. Specifically, its share composer listens for focusout on any descendant and closes the modal — the UX intent is "clicked outside → close."

My fill path did this at the end:

// Old: "polite" contenteditable fill (pseudo-code)
setEditableContent(editableEl, text);
editableEl.dispatchEvent(new Event('input', { bubbles: true }));
editableEl.blur();  // ← here's the assassin

The blur() call was there for a reason — some React frameworks only commit state on blur. Perfectly reasonable on a standalone textarea. Inside a dialog? The focusout listener takes the blur, concludes the user clicked away, and runs the dismiss animation.

My fill worked. For ~40ms. Then the dialog DOM disappeared and the text with it.

Fix: Remove the blur(). React commits state from input alone on any modern contenteditable. If a site truly requires blur to persist, it is broken for keyboard users anyway.

But removing blur was not enough. The next run showed the text finally landing, the Post button enabling — and then the button click did nothing. Why?

Boundary 2: ProseMirror's isTrusted:false paste rejection

LinkedIn's composer was ProseMirror when I started debugging. (They have since migrated to Lexical. We will get there.) ProseMirror has a paste handler. That handler is strict:

// ProseMirror source, paraphrased
handlePaste(view, event) {
  if (!event.isTrusted) {
    // Synthetic paste events don't reflect real user intent.
    // Reject them — the editor state must only change from real input.
    return false;
  }
  ...
}

This is a security decision, not a UX one. event.isTrusted is only true when the browser itself dispatches the event — a real keystroke, a real paste, a real click. JavaScript new Event() or dispatchEvent() produces isTrusted:false every time.

My fill was dispatching new ClipboardEvent('paste', { clipboardData: ... }). The editor reached its paste handler, saw isTrusted:false, and bailed. The execCommand('insertText') fallback went the same way.

The character-by-character beforeinput dispatch? Also isTrusted:false. Also rejected.

Fix that worked (and broke in Boundary 3): Route through a real OS paste. I already had a _nativeTypeViaClipboard path — uses AppleScript to set the system clipboard, then dispatches a real Cmd+V via macOS CGEvent. The browser sees it as a real user paste. isTrusted is true. Editor accepts it.

Boundary 3: CGEvent Cmd+V steals focus, triggers Boundary 1

Remember Boundary 1 was "focusout dismisses the dialog?" Well —

The CGEvent Cmd+V path delivers the keystroke to the frontmost window. To be the frontmost window, Safari has to be active. When I programmatically activate Safari via NSApplication activateIgnoringOtherApps, the previous window loses focus for a tiny window. Chrome's "focus stealing" behavior is a documented pet peeve of every automation tool; Safari is no different.

So the sequence was:

1. CGEvent fires Cmd+V
2. Safari gets activated (taking focus briefly)
3. The composer editor sees focusout during the ~10ms activation window
4. Dialog dismisses
5. Paste lands — but on the feed underneath the now-closed dialog

Cool.

First fix attempt: Use a background-activation variant that does not foreground Safari. This worked but required the user's Safari to already be the active app (fragile — the point of MCP is the user is doing other work).

Second fix attempt — the one that stuck: Bypass the OS keyboard entirely. Drive the editor through its own internal API.

The actual fix: editor-native API access

LinkedIn's composer (as of 2026-04) is Lexical, not ProseMirror. Lexical is Meta's replacement — also used in Shopify admin, some Meta apps, newer Notion surfaces.

Lexical exposes the editor instance on its DOM root element:

const editorEl = document.querySelector('[data-lexical-editor="true"]');
const editor = editorEl.__lexicalEditor;  // the actual LexicalEditor instance

// Build a minimal root → paragraph → text document
const newState = editor.parseEditorState(JSON.stringify({
  root: {
    children: [{
      children: [{ detail: 0, format: 0, mode: 'normal', text: value, type: 'text', version: 1 }],
      direction: 'ltr', format: '', indent: 0, type: 'paragraph', version: 1
    }],
    direction: 'ltr', format: '', indent: 0, type: 'root', version: 1
  }
}));
editor.setEditorState(newState);

Zero synthetic events. Zero focus shift. Zero clipboard. The editor updates its own state directly. Lexical's internal invariants hold. React re-renders the contenteditable tree through its normal diff path. The Post button observes the state change and enables itself.

For ProseMirror (which LinkedIn used to use), the equivalent is:

const pmView = editorEl.pmViewDesc?.view;  // ProseMirror's EditorView
const tr = pmView.state.tr.insertText(value, pmView.state.selection.from);
pmView.dispatch(tr);

Same principle: do not pretend to be a user. Be a caller.

The cascade of falsified "success"

Here is what is unsettling: every stage of every failed attempt returned success to my agent.

• Setting the editable element's content → value set, DOM mutation event fires, "success"
• dispatchEvent(new ClipboardEvent('paste')) → handler called, preventDefault returned, "looks like paste fired, success"
• _nativeTypeViaClipboard → Cmd+V fired, clipboard had the content, "success"

The only honest verification is: did the editor state update? Not the DOM. Not the visible text. Not the event log. The editor's own source of truth.

For Lexical: editor.getEditorState().toJSON(). Compare to what you expected. Now you know.

This is why your agent's "I posted it" lies. Every layer of the automation stack reports local success. None of them verified the editor's internal state matched the intent.

Generalizations

1. Blur is radioactive in dialogs. Audit every automation tool's fill path. If it calls .blur(), it will close some modal somewhere.

2. isTrusted:false is a one-way door. Real-world rich-text editors audit it. Your synthetic paste/input/keydown will not cross. Either use a native OS path (Cmd+V via CGEvent/winuser) or drive the editor API directly.

3. Native OS paste moves focus. Which is fine — unless the target is inside a dialog that listens for focus loss. In that case, drive the editor API directly.

4. Editor API access is undocumented but stable. __lexicalEditor, pmViewDesc.view, Draft.js's internal store — these are all in production for years because the editors are themselves stable. They are not public but they are not moving.

5. Trust nothing downstream of the editor. The rendered DOM, text content, visible interface — any of these can be right while the editor's internal state is wrong. Verify editor state, not DOM state.

What this means if you use or build MCP servers

Most MCP browser tools today use page.type() or element.fill() — thin wrappers over DOM events. They will work for 80% of forms and silently fail for rich editors inside dialogs (which is roughly: every post/comment/share UI on every major social site, Notion, Google Docs, JIRA, Salesforce rich notes, Shopify description fields).

If you are evaluating browser-automation MCP servers for agent workflows that involve content creation, test this specifically:

• Can it post to LinkedIn?
• Can it type a multi-line comment on GitHub?
• Can it fill a Notion page with formatted text?

If any of those fail silently (returns "success" but the target app shows nothing), the tool has one of these three bugs.

Safari MCP v2.9.4 ships the Lexical-native path. If you are on macOS and want to try it:

npx safari-mcp

MIT, 80 tools, github.com/achiya-automation/safari-mcp.

Is there a fourth boundary I missed? Drop a comment — I will buy the bug report with a merch sticker if it forces a v2.9.5.