The hardest part of our Chrome extension wasn't AI — it was replacing text safely

Fix English — Mon, 26 Oct 2026 13:14:00 +0000

We built a Chrome extension that fixes the English in selected text and puts the correction back in the same place.

Sounds simple, right?

Select a sentence in Gmail, press a shortcut, get corrected text, replace the selection. The AI call is straightforward.

The hard part is everything that happens afterward.

Gmail might wrap a misspelled word in a temporary span. Jira might rebuild the paragraph while we're waiting for the model. Slack might insert an extra space. Outlook might let us undo a correction, then silently put it back a moment later.

And if we get the replacement wrong, we could delete someone's formatting, break a mention, or insert corrected text next to the original instead of replacing it.

We ran into these problems while building Fix English, a Chrome extension that corrects selected text with minimal changes.

Here's what we learned about safely editing text in Slack, Jira, Confluence, Gmail, GitHub, Teams, Outlook, and other web apps.

1. Plain text fields are easy. Until they're not.

Let's start with a regular input or textarea.

The obvious solution is:

element.value = correctedText;

Unfortunately, that isn't a great way to edit someone else's application.

Framework-controlled inputs might not recognize the update as expected. More importantly, directly assigning .value doesn't preserve the browser's native undo history.

We wanted users to be able to press Ctrl/Cmd+Z after a correction.

Our approach uses the browser's normal editing path whenever possible:

Dispatch a cancelable beforeinput event with inputType: 'insertReplacementText'.
If the application cancels that event, don't force the replacement.
Restore the selection using setSelectionRange().
Try document.execCommand('insertText', false, text).
If that doesn't change the field, fall back to setRangeText() and dispatch an input event.

Our actual implementation also validates the selected text before writing and checks the result afterward.

Yes, execCommand() is deprecated.

But it has one advantage that's difficult to replace: edits made through it can preserve the browser's undo history. Even MDN's documentation acknowledges this use case.

One important detail: execCommand() doesn't consistently fire beforeinput across browsers and configurations. We dispatch it explicitly so applications have an opportunity to handle or cancel the proposed edit.

That isn't a universal permission mechanism â€” synthetic events aren't trusted user input, and applications may ignore them â€” but respecting cancellation is better than blindly overwriting a field.

We use the same general approach for React-controlled text fields. So far, we haven't needed a separate React-specific write mechanism.

The fallback is less ideal for native undo, which is why we prefer insertText.

2. Rich editors don't consider the DOM their source of truth

Now things get interesting.

A regular contenteditable element looks like an editable DOM tree. But modern rich-text editors often maintain their own internal document model.

The DOM is just a rendered representation of that model.

If you directly change its text nodes or innerHTML, the editor might:

Re-render and undo your change.
Lose track of its selection.
Remove formatting or embedded content.
Accept the visual change without updating the document it eventually saves.

We needed to interact with the editor's own editing pipeline rather than treating its DOM as a text file.

One generic strategy, several editor families

We identify common editor families through DOM markers, including:

ProseMirror
Lexical
CKEditor 5
Draft.js
Native contenteditable

Most of the write logic is shared. The detected editor family changes the order in which we try different methods.

The right order depends on the editor type.

CKEditor can restore its internal model over DOM changes it didn't initiate. In our Teams web testing, using its input handling path worked better than forcing execCommand().

Synthetic paste is not the same as pasting

We construct a ClipboardEvent using a DataTransfer object containing the correction.

This doesn't modify the user's real clipboard.

There's an important distinction, though: dispatching a synthetic paste event doesn't make the browser insert text automatically. The editor must actually handle the event.

That's also documented in MDN's paste event reference.

We treat event.defaultPrevented as a signal that the editor may have claimed the event, not proof that the replacement succeeded.

After dispatching, we verify the resulting text.

If the editor handled the event but produced no acceptable change, we don't blindly retry a different insertion method. That could duplicate text or fight the editor's internal state.

A ProseMirror surprise

In Jira and Confluence, inserting HTML through a paste event initially created a new paragraph instead of replacing text inside the existing one.

Adding the editor's own slice metadata to the clipboard data solved it.

Other editors needed different handling.

In CKEditor, line breaks inside a paragraph can map to <br> elements, while blank lines may need paragraph elements.

Gmail introduced another challenge: temporary spelling and grammar spans. A word we're correcting can cross one of those spans. We added narrowly scoped handling for the observed Gmail proofreading markers rather than treating arbitrary formatting as disposable.

Slack occasionally normalizes a replacement by adding a trailing space. Our first verification logic interpreted that as a failed edit.

The lesson: matching the corrected text isn't always enough. You also need to understand how the host editor represents it.

3. DOM Ranges can become stale without warning

This was one of the most frustrating bugs.

Imagine a user selects:

I has a meeting tomorow.

They press our shortcut.

We save the selection, send the text for correction, and receive:

I have a meeting tomorrow.

But while the correction is running, the editor re-renders.

The original DOM nodes may no longer exist.

A saved Range can become detached, collapsed, or otherwise no longer represent the original selection. The dangerous part is that it doesn't necessarily throw an error.

You might insert the corrected sentence without deleting the original.

What we do instead

At capture time, we store the original selected text and its character offsets within the editor.

Before writing, we resolve the selection again.

We try to locate it in this order:

Use the original live Range if it's still connected and still contains the expected text.
Check the original character offsets against the current content.
If the text has moved, search for an exact, unique occurrence of the original selection.
If no unambiguous match exists, stop and show a correction preview.

That third step matters.

Suppose someone adds a sentence before the selected text during the correction. The original offsets are now wrong, even if the selection itself hasn't changed.

A unique text match can let us recover safely.

But if the same selected sentence appears twice, we refuse to guess which one the user intended.

We then reconstruct a fresh Range from the resolved offsets, synchronize the selection with the editor, and verify the expected text again before writing.

For editors that maintain their own selection state, even setting the browser selection isn't always enough. We may need to wait for selection synchronization and confirm it hasn't been overwritten by the framework.

This is more work than saving selection.getRangeAt(0) and calling it a day.

It's also the difference between replacing the intended text and modifying the wrong part of someone's document.

4. Don't replace an entire paragraph to fix one word

Another problem came from the model output itself.

AI models love to clean up formatting, even when you explicitly tell them not to.

They might collapse repeated spaces, normalize non-breaking spaces, remove tabs, or reflow line breaks.

Consider this:

Hello    John,

I  will send the report
    tomorrow.

If the correction only needs to change a misspelled word, we don't want to rebuild that layout.

And in a rich editor, replacing a whole paragraph might also remove a link, a mention, or inline formatting.

Our approach: diff the words, preserve the layout

We tokenize the original text and corrected text, then use a longest-common-subsequence (LCS) diff to identify unchanged words.

Those unchanged words become anchors.

Instead of applying the entire model response, we build a correction plan against the original text.

For example:

Original

I has a meting tomorrow.

Model output

I have a meeting tomorrow.

Our replacement plan

has     â†’ have
meting  â†’ meeting

The surrounding whitespace and punctuation stay where they were.

We apply mapped edits from the highest character offset to the lowest, so an earlier edit doesn't invalidate the offsets of later edits.

We also avoid merging edits across protected separators such as tabs, repeated spaces, non-breaking spaces, and line breaks.

Formatting makes this harder

A changed word might span multiple text nodes.

Sometimes that's harmless, like a Gmail spelling annotation.

Sometimes those nodes represent an actual formatting boundary, link, or embedded object.

We distinguish between those cases instead of assuming every text-node boundary is equivalent.

Our preferred path is to modify only the smallest safe text regions.

The extension also has a broader whole-selection fallback when targeted edits can't be applied. That improves compatibility, but it's a tradeoff: verifying the resulting text alone cannot guarantee every piece of rich formatting survived.

That's one of the areas we're continuing to tighten.

For selections we can't safely resolve or that contain unsupported structures, we show a correction preview instead of guessing.

A preview is an extra step for the user.

Silently damaging their message is much worse.

5. A successful write isn't necessarily a successful edit

We originally thought we could check the DOM immediately after inserting text and call the operation successful.

That turned out to be optimistic.

An editor might update its DOM synchronously, then reconcile its internal model on the next task.

For a moment, the correction appears.

Then the original text comes back.

Our write pipeline therefore distinguishes between three outcomes:

OK: The resulting text matches what we expected, including after a short settling period.
Unchanged: The editor didn't produce an acceptable change.
Different: The editor changed the document in a way we didn't expect.

Those outcomes matter.

If nothing changed and the editor didn't claim the event, trying another write method may be reasonable.

If the editor handled the event, or changed the content differently than expected, blindly trying again is dangerous.

For multi-edit corrections, we also track which individual edits succeeded. If a later edit fails, we attempt to roll back the changes already applied.

Even rollback needs verification.

We don't want to turn a partially successful correction into a corrupted draft.

And if we can't confidently restore the original state, we tell the user to review the editor rather than claiming everything is fine.

6. Undo is harder than the original correction

Native text fields have a useful advantage: execCommand('insertText') can participate in the browser's undo history.

Rich editors are more complicated.

They might maintain their own undo stack, group transactions differently, or re-render from internal state.

So Fix English also provides an Undo button in its confirmation toast.

That sounds straightforward: save the original text, and put it back if the user clicks Undo.

In practice, we needed several rules.

Only undo our own edit

Before restoring anything, we verify that the editor still contains the correction we applied.

If the user has since changed the content, we don't overwrite those changes with an old snapshot.

Ignore the editor's own cleanup

Some editors normalize their DOM after insertion.

We don't want that internal activity to make the Undo button disappear.

Our listener distinguishes trusted user activity from the synthetic events involved in our own operation. It also checks whether an observed change is simply the editor normalizing the same corrected text.

Outlook web gave us a particularly strange bug

We clicked Undo.

The original text came back.

Everything looked correct.

Then, a moment later, the corrected text reappeared.

Outlook's editor had restored its own model snapshot over our Undo operation.

The workaround wasn't particularly elegant.

After restoring, we verify the result again after a short delay. If the editor overwrote our restoration, we attempt to restore the original again and verify after another short delay.

This isn't meant to be an infinite fight with the editor. The retry is bounded, and we verify whether the state still matches what we're trying to restore.

If we can't confidently finish, Undo reports a failure instead of pretending it worked.

The broader lesson was that Undo is another editor transaction, not just a reverse string operation.

And it needs the same validation as the original edit.

7. The right frame matters too

Some web applications place editable content inside iframes.

An earlier version of our extension occasionally required two shortcut presses in Teams and Jira.

The first press didn't reach the frame holding the active selection.

We changed the process:

Inspect the current selection.
Inject the content script into accessible frames when needed.
Ask the frames which one actually contains an editable selection.
Re-read the selection before starting the correction.

The important part is not assuming the top-level document owns the text the user selected.

Of course, Chrome extension permissions still apply. We don't attempt to bypass inaccessible cross-origin frames, protected browser pages, password fields, or read-only content.

And this is a browser extension. It doesn't operate inside native desktop applications.

8. Knowing when not to write is a feature

After working through all these issues, we ended up with a few principles that guide the implementation.

The editor owns its text. We should use its editing mechanisms whenever possible, rather than modifying the DOM directly.

Selections expire. A selection captured before an asynchronous operation must be validated again afterward.

Text equality isn't structural equality. The words might look correct while formatting or editor state has changed.

Retries need evidence. If an editor accepted an event or changed its content unexpectedly, another blind write can make the situation worse.

Undo deserves the same safety checks as insertion. Restoring an old snapshot shouldn't destroy a newer user edit.

A preview is a valid result. Sometimes the safest automatic edit is no automatic edit.

We're still improving compatibility.

Multi-paragraph corrections in Gmail can still stop partway. Confluence sometimes falls back to a preview. Complex formatting remains a challenging area, particularly when an editor doesn't expose a reliable external editing API.

And that's okay. We'd rather make these limitations visible than claim every editor behaves the same way.

Final thought

When we started building Fix English, we expected prompt quality and model latency to be the hardest problems.

Instead, we spent a surprising amount of time understanding browser editing behavior, DOM selections, framework state, clipboard events, whitespace preservation, and undo.

The AI generates the correction.

But the surrounding application decides whether that correction can safely become part of the user's document.

If you're building a grammar tool, translation extension, AI writing assistant, or anything else that replaces text inside third-party web applications, I'd strongly recommend treating text replacement as its own engineering problem.

Because generating the right words is only half the job.

Putting them back without breaking anything is the other half.

Disclosure: We built Fix English, the Chrome extension discussed in this article.

It's free, requires no account, and focuses on minimal grammar and spelling corrections rather than rewriting your message. Select text and press Cmd/Ctrl+Shift+E to fix it in place, with Undo or a correction preview when needed.

When Chrome's built-in on-device model is already available, Private mode is enabled by default and corrections run locally. Otherwise, the extension uses its cloud service. If an active Private mode correction can't run locally, sending that selection to the cloud requires an explicit user action. Fix English doesn't save your text.

I'd love to hear from anyone who's dealt with similar problems in ProseMirror, Lexical, CKEditor, or other rich-text editors. What was the most unexpected editing behavior you ran into?

DEV Community: Fix English