MCP Browser Automation: Why Rich-Text Editors Fail Silently

When an AI tries to type into the fancy text boxes on LinkedIn, Notion, Google Docs, or JIRA, it often fails without anyone noticing — the log says it worked and the screenshot even shows the words, but nothing is actually saved. The automation tools this happens to include Playwright, Puppeteer, Chrome DevTools, and Browserbase, all of which are part of MCP (Model Context Protocol), the standard AI assistants use to control a browser. Three separate safety features cause it: the text box closes the moment focus leaves it (focusout dismissing dialogs), the box ignores fake typing (isTrusted:false rejection in editor paste handlers), and even a genuine copy-paste can knock focus away and close the box (OS-level paste re-triggering focusout). To make it work you either use each text box’s own built-in commands, or press Cmd+V for real at the operating-system level — not a faked event (dispatchEvent).

When you tell one of these tools to fill in or type text, it doesn’t really press keys — it manufactures the little signals a browser fires when you type, known as synthetic DOM events (in plain terms, fake typing). For an ordinary text field or a simple form, that’s perfectly fine and it just works. But for the richer text boxes that sit inside pop-up windows — LinkedIn’s post composer, Notion’s page editor, JIRA’s comment box, Google Docs — it fails quietly, in a way that’s almost impossible to spot from the outside.

“After deploying 50+ WhatsApp bots for Israeli small businesses, the pattern is clear: the bots that succeed handle 80% of repetitive inquiries automatically and seamlessly hand off the remaining 20% to a human.” — Achiya Cohen, Achiya Automation

The same split shows up when an AI drives a browser: about 80% of the boxes on a page take fake typing just fine, but the other 20% — the fancy text boxes, the pop-up windows, the editable areas that aren’t plain form fields — need a completely different approach.

So here’s what you see. The AI says it worked. The log says “Filled”. The words even flash on the screen for a second. Then the pop-up closes, the text is gone, and you’re left wondering why your AI can’t seem to post anything.

The rest of this article walks through exactly how that failure happens — and why fixing it means understanding three separate safety features that most automation tools simply don’t plan for.

“MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a USB-C port for AI applications.” — Anthropic, Introducing the Model Context Protocol

The three boundaries

“Lexical is an extensible JavaScript web text-editor framework. It’s designed for reliability, accessibility, and performance.” — Meta, Lexical project documentation

Boundary 1: focusout dismisses the dialog

Text boxes that live inside pop-up windows — LinkedIn’s post box, Shopify’s product-description editor, Notion’s inline editor — watch for the moment your cursor leaves the box. In browser terms that moment is the focusout event. They watch for it for a good reason: if you click somewhere else on the page, they assume you’re done and politely close the pop-up.

Here’s the trap. Many automation tools finish typing by deliberately clicking away from the box — a step called element.blur() — so the page will notice the text and save it. But clicking away is exactly what fires focusout. The pop-up thinks you left, so it closes, and the text you just entered vanishes right along with it.

Plenty of teams have burned hours on the mystery of “my text shows up for a second and then disappears.” The fix is simply to not click away: React (the code running the page) already notices the new text from the typing events by themselves, so the extra click-away step isn’t needed.

Boundary 2: isTrusted:false rejection in editor paste handlers

“The isTrusted read-only property of the Event interface is a Boolean value that is true when the event was generated by the user agent (including via user actions and programmatic methods such as HTMLElement.focus()), and false when the event was dispatched via EventTarget.dispatchEvent().” — MDN Web Docs, Event.isTrusted

In plain terms, event.isTrusted is a truth badge the browser pins to every event. It reads true only when the browser itself set the event off — a real key press, a real paste, a real click. Anything a script cooks up gets stamped isTrusted:false, and there’s no way for the script to forge a true.

The fancy text boxes read that badge on purpose and turn away anything that isn’t genuine. Notion’s paste handler, LinkedIn’s clipboard code, JIRA’s typing code (built on ProseMirror, Lexical, and Draft.js) all refuse fake events on purpose. It isn’t a bug — it’s what stops a sneaky script from swapping out the text in a box you’re about to sign or publish.

None of the usual fake-typing tricks carry a genuine badge — not a fake paste (ClipboardEvent('paste')), not a fake keystroke (InputEvent('beforeinput')), not the old-school execCommand('insertText') command. So the tool’s attempt just bounces off the text box, yet it still reports success. Why? Because the act of firing the event (dispatchEvent) finishes cleanly on its own — the tool never hears that the text box quietly ignored it.

Boundary 3: Native OS paste triggers Boundary 1

The usual way around Boundary 2 is to stop faking anything and have the computer itself do a real paste — for example, put the text on the clipboard and then have the operating system genuinely press Cmd+V (via AppleScript on a Mac, or the Windows equivalent), exactly as if you’d tapped the keys.

And it does work — the browser sees a real paste, the truth badge (isTrusted) reads true, and the text box happily accepts the content. But there’s a catch. To send that keystroke to the right window, the tool first has to pull the target browser to the front of the screen. The instant it does, whatever app was in front loses focus — and losing focus is the very focusout event from Boundary 1. So we’ve come full circle.

The paste does go through, just into the wrong place: by the time it lands, the pop-up has already snapped shut.

Why this matters for AI agents

When an AI is set loose to create content in a browser — post to LinkedIn, reply on a GitHub pull request, write up a Notion page, open a JIRA ticket — it runs into all three of these safety features over and over. And the frustrating part is that failure looks exactly like success: the tool says “filled”, the text flashes on screen, and the AI moves on to the next step. The only place the truth shows up is in what the app actually saved — which is the one thing the user cares about, and it’s empty. This is the same trap we cover in our broader AI agents for business guide: a system that says “done” without checking whether it really happened can’t be trusted in the real world.

This is especially damaging when a chain of steps runs on its own, because nothing ever raises a hand to say something went wrong. Every later step just carries on as if the post went up. The AI reports that it finished. And the person only finds out hours later — usually when a customer asks about the LinkedIn announcement that was never actually published.

The real fix: editor-native API access

Every one of the three safety features above kicks in because the tool is pretending to be a person. So the real answer is the obvious one: stop pretending. Instead of faking keystrokes, reach the text box directly and ask it to change its own text using the controls it already has built in.

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.

Editor framework comparison — what works, what fails

Different websites build their text boxes with different underlying tools, and each tool behaves differently when an AI tries to type into it. The table below lines them up side by side: which big sites use each one, whether it accepts fake typing, whether it leaves a handle you can grab, and the cleanest way to fill it. If you only remember one column, make it the third — “Synthetic events accepted?” tells you at a glance whether fake typing will silently fail.

Look at the tally: of the 9 text-box tools above, 5 (56%) quietly refuse fake typing — Lexical, ProseMirror, Tiptap, Draft.js, and Slate.js — while only 2 (22%), Monaco and CodeMirror, reliably let it through. That 56% is the whole problem in a nutshell: most of the text boxes an AI runs into today simply can’t be filled by faking keystrokes, and worse, the AI is never told when the write silently flopped.

Production benchmark: failure rates across 50+ deployments

To put real numbers on this, we tracked it in the field: 50+ live AI workflows over 18 months (October 2024–April 2026), running on macOS 14.5 and 15.2 and driving Safari 17.6 and 18.2, against the exact text-box versions listed below. The table shows how often fake typing silently failed on each kind of box. Every row is based on 200 real fill attempts recorded during actual production runs, so these aren’t lab estimates:

Here’s what those numbers add up to:

• On the 8 real content text boxes (everything except the plain form field we used as a baseline), fake typing worked only 8.4% of the time on average — meaning it silently failed 91.6% of the time.
• The 2 code-editing boxes (the Monaco family plus CodeMirror) worked 92.5% of the time — a failure rate of just 7.5%, roughly ten times better.
• Fake typing also adds a tiny delay, and how much varies: from 14ms (plain textarea) at the fastest to 64ms (Google Docs) at the slowest — a 4.6× difference between the two.
• In the first 3 months of running these AIs, the typical silent failure ate up 47 minutes per incident of someone’s time to track down (some took as little as 6 minutes, some as long as 180).
• Each failure also costs money — the AI tokens, the retry, and the developer’s time to review (counted at $30/hour) — and that ranges from $0.01 (textarea) to $0.31 (Google Docs), a 31× difference between cheapest and priciest.
• Add it all up across those 8 text boxes, the 50-deployment group, and the full 18 months, and these unnoticed failures burned roughly $2,400 in wasted computing and 126 hours of debugging. Spread over a year and per deployment, that’s $32 and 1.7 hours lost to this one kind of bug alone.

The one figure to act on is that gap: 91.6% silent failures on content text boxes versus only 7.5% on code boxes. Put simply, if the box you’re targeting is built on Lexical, ProseMirror, Tiptap, Draft.js, or Slate.js, expect fake typing to work less than 10% of the time unless you go through the box’s own commands instead.

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.

What to verify when evaluating MCP browser tools

“Adding direct quotations increased citation likelihood by 43%, the highest of six tested content strategies.” — Aggarwal et al., GEO Princeton arXiv:2311.09735

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.

Where this fails in practice: documented framework behavior

None of this is guesswork — you can read it right in each text box tool’s own source code, where it openly refuses fake typing. The table below pairs up where each tool is used in the wild (the well-known apps that have said so publicly) with the refusal behavior spelled out in that tool’s own code repository.

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.

Why the rejection is intentional (not a bug)

Each of these tools explains the reasoning right in its own code:

• Lexical: that __lexicalEditor handle is there on purpose — so the box’s own features and the page’s normal update cycle can make changes the box trusts. Let fake outside events in, and they’d skip the checks the box runs and quietly break its undo/redo history. See Lexical editor state architecture.
• ProseMirror: the only legitimate way to change the text is through the box’s own bundled change operations (it calls them transactions) — see prosemirror-state guide on transactions. Fake typing skips the safety checks that keep the content from getting mangled.
• Draft.js (now retired): it keeps its text in a locked container that can only be swapped out through React’s own update machinery — there’s simply no back door for a fake event. It was officially retired in 2022 (Meta blog post), which leaves it running in old-mode on holdouts like JIRA that never moved off it.

What the empirical literature says about this class of failure

This isn’t a quirk of one browser, either — the isTrusted truth badge is written into the official web rulebooks: the W3C UIEvents spec and, again, the WHATWG DOM standard. Both say the same thing: you’re allowed to fire a fake event, but it carries a “not genuine” badge (isTrusted:false) that a text box is free to reject.

And it’s a well-worn headache for people building AIs. The Anthropic MCP design discussion and the browser-use issue tracker both have running threads about this exact problem — search any browser-automation project for “silent failure” plus “rich text” and you’ll see it come up again and again.

A practical detection checklist

Since none of these text boxes ever report an error (firing the event finishes cleanly even when the box ignored it), you can’t sit back and wait for a warning — you have to go check the result yourself. Here are four ways to do that, from simplest to most thorough:

1. Go back and look at the page — reopen the post’s own URL and confirm the text is actually there. This catches Boundary 1 (the pop-up closed before saving) and Boundary 3 (the paste landed in the wrong place).
2. Ask the platform directly — after posting, use the site’s API (the official way one program asks another for information) to check that the post really exists on LinkedIn, Notion, or JIRA. This is the one check that reliably catches all three safety features.
3. Watch the box for a change, and give up after 30 seconds — keep an eye on the text box (technically, watch the page’s structure, the DOM, for updates); if nothing that looks like a save shows up within 30 seconds, count it as failed. This reliably catches Boundary 2.
4. Have a second account look — for posts that really matter (scheduled announcements, messages to customers), get a different account to confirm the content is visible. It’s the most trustworthy check, but it takes extra time.

The thread running through all of them: never trust the “success” message on its own. The very fact that firing the event finishes cleanly is exactly why this kind of failure slips past most logging and monitoring.

Safari MCP and the Lexical path

Safari MCP does exactly that for the Lexical boxes as of version 2.9.4 — it fills them the honest way, through the box’s own commands. As far as I know it’s the only such tool that can handle LinkedIn’s post box from start to finish with no help from you, and the same release adds the Notion-style (ProseMirror) path too.

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.

Sources & References

Each of the three safety features above comes straight from the security design that these tools spell out in their own documentation:

• 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