DEV Community

Cover image for LinkedIn Quietly Migrated From ProseMirror to Quill — and Broke Every Browser Automation Tool That Touched the Composer
אחיה כהן
אחיה כהן

Posted on

LinkedIn Quietly Migrated From ProseMirror to Quill — and Broke Every Browser Automation Tool That Touched the Composer

#javascript #mcp #ai #automation

I shipped a fix to my MCP server last week for LinkedIn's ProseMirror composer. It worked. Two days later, every LinkedIn post automation broke.

This is the post-mortem of what changed, how I figured it out, and why "automate the platform" stories almost always end this way.

The crash

The symptom was specific. My MCP server's safari_fill tool — which dutifully filled ProseMirror by walking React Fiber and calling editor.commands.setContent(html) — was now crashing the helper daemon and dismissing the composer dialog the instant it touched the contenteditable.

Same composer URL. Same DOM tree at first glance. Same selectors. Different editor underneath.

The DOM tells the truth

I dropped into the browser console and ran the usual probe:

const el = document.querySelector('[contenteditable="true"]');
el.editor // -> undefined
el.closest('.ProseMirror') // -> null
el.closest('.ql-editor') // -> <div class="ql-editor">
Enter fullscreen mode Exit fullscreen mode

There it was. .ql-editor is the canonical Quill class name. LinkedIn had swapped the post composer from ProseMirror to Quill at some point in early 2026 with no announcement I can find.

Why it was crashing

Quill, like ProseMirror, doesn't let you "just" stuff text into the contenteditable. Both editors hold an internal model — Quill calls it a Delta — and the DOM is downstream of that model.

If you bypass the model and write to the DOM directly, two things happen:

  1. The model and DOM disagree.
  2. The next user-driven event (a keystroke, a save) triggers a re-render that throws because the diff is incoherent.

That's what was killing the composer. My fill was writing to innerText, the Delta state thought the editor was still empty, the React tree tried to reconcile, and the dialog evaporated. The Swift daemon caught the cascading exception and crashed itself for good measure.

The fix: drive Quill the way it expects to be driven

Quill exposes a programmatic API. You just need a reference to the instance. The lookup order I landed on:

  1. Walk up to find an ancestor with class .ql-container.
  2. Try .__quill — Quill 2.x attaches the instance there directly.
  3. Fall back to React Fiber: walk up the fiber chain looking for memoizedProps.quill or stateNode.quill (LinkedIn wraps Quill in a React component that holds the instance in props).
  4. If still nothing, fall back to a real CGEvent Cmd+V paste — Quill respects clipboard events with isTrusted: true.

Once you have the instance, the actual fill is one line:

quill.setContents([{ insert: text + '\n' }], 'api');
Enter fullscreen mode Exit fullscreen mode

The 'api' source flag is the part that matters. It tells Quill "this came from your own API, update your model and the DOM together." The text commits, the Delta stays consistent, and the React parent doesn't try to re-conciliate against a corrupted model.

What this taught me about platform automation

Two lessons, both old, both worth re-learning:

Editors aren't a stable interface. ProseMirror and Quill have different APIs, different state models, and different rules for "what counts as a real edit." Targeting one of them only works until the platform decides it doesn't anymore. LinkedIn made this swap with zero changelog. The only way I knew was that my code broke.

The DOM is the lowest common denominator. The editor model is the actual one. Every automation tool that synthesizes events on the contenteditable is operating one layer below the truth. Sometimes that works (because the editor reconciles). Sometimes it doesn't (because the editor crashes or silently discards the input). The robust path is always to find the editor instance and call its API.

There's a third lesson, which is more uncomfortable: I couldn't fully verify my fix on LinkedIn, because LinkedIn's modal-opening behavior in headless contexts is independently broken right now. The composer button accepts clicks, the dialog DOM materializes, but it never visually opens. So the Quill detection is in place — and verified on test pages — but the LinkedIn-specific live path is still gated on a separate modal issue I haven't cracked.

This is the texture of platform automation. Two unrelated bugs, same week, same target. Each one looks like the other. You ship a fix for one and the other one masquerades as a regression.

The takeaway

If you're building anything that types into a third-party rich text editor — Slack, LinkedIn, Discord, Medium, Notion — the editor identity is part of your contract with the platform, and the platform doesn't owe you stability there. Detect the editor type at runtime. Have a fallback for the unknown case (real clipboard events, ideally). Log what you found, so when it changes you find out from your own telemetry instead of from a Slack message at 11pm.

And read the contenteditable's class list before you touch it. ProseMirror and Quill have different class signatures and the DOM will tell you what you're dealing with — if you ask.

The fix shipped in safari-mcp@2.10.2. Source on GitHub.

Top comments (0)