Writing in Notion and Zendesk Without Losing Text

There is a category of websites where writing feels dangerous. Not because the software is bad, but because the place you typed is not the place the browser thinks you typed.

Support ticket systems, knowledge bases, note-taking apps and collaborative editors all share the same trait: the writing surface is not a form field. Everything about recovery changes as a result.

A textarea versus a rich text surface

A textarea is a form control. It has a value, that value belongs to the document, the browser can read it, the browser can remember it and the browser can put it back. Everything in the form recovery world depends on that.

A rich text editor is a different arrangement. Underneath is a contenteditable region, which is not a form control at all. The text inside is part of the page's own markup, and the application keeps a separate document model that it treats as the truth.

The visible text and the stored value have been separated. That single difference causes every problem that follows.

What each product does with your writing

Notion

Pages you have created live on their servers and sync as you type, so an existing page is reasonably safe. The gap is text typed into a page that was never created, or a draft you started and did not save. Chrome has no record of it, and Notion has no record of it either.

Zendesk and similar ticketing systems

The agent reply box is a contenteditable region inside an application that re-renders as you type. This is the classic case where a long reply is at risk, because nothing persists until you press submit.

Salesforce and other enterprise platforms

Large single page applications with fields generated at runtime. Here the identifier problem appears alongside the editor problem, so both have to be handled.

Google Docs and similar editors

These are considerably better behaved than they used to be, because the document genuinely lives on a server and autosaves continuously. This is the model worth copying.

Why browser form filling cannot help

Chrome's autofill looks for form controls it recognises. A contenteditable region is not one, so it is invisible to the whole system. There is no setting that changes this, because it reflects how the markup is written rather than a policy the browser is applying.

This is the single biggest reason people report that form history tools work on ordinary forms but do nothing in the tools where they write the most.

How to protect your writing on these sites

1. Use a tool that understands contenteditable. It needs to read the text from the region, watch it as you type and put it back by writing into the region and dispatching an input event.
2. Accept plain text on restore. Any tool that promises to bring back your formatting is either storing a great deal more data, including the contents of the document, or guessing. Guessing produces worse output than plain text.
3. Save drafts inside the application as well. Most of these products have their own draft feature. Use it. Two independent copies are better than one, and the server-side copy is the one that survives a wiped machine.
4. Draft the longest work somewhere else. Write the substantial pieces in a plain text editor and paste them in. It is unglamorous and it works on every site including ones no tool supports.

Form ReDraft detects contenteditable regions automatically, including the class names commonly used by ProseMirror and Quill, and restores plain text into them with the events those editors listen for.

When a restore does not stick

There is one honest limitation worth stating plainly. An editor whose document model is authoritative will re-render the surface from that model and discard whatever was inserted into it.

The mechanics are not a failure of the restore. The text is written, the events are dispatched, the editor receives them and updates its model. But an editor that syncs to a server or that virtualises its content may rebuild the surface afterwards from a version of the document that predates your insertion.

How to tell which you are dealing with: restore the text, then type a character and delete it. If the editor rebuilds from its model, your restored text disappears at that moment rather than persisting.

Editors built on Monaco, which power some developer dashboards, are a separate case again. They keep their content in a model with its own API, and writing into the visible surface produces inconsistent results. Form ReDraft does not support them rather than pretending to.

FAQ

Why does Chrome not restore text in Notion?

Because a rich text surface is a contenteditable region, not a form field. Chrome form filling has no concept of one, so there is nothing for it to remember.

Does Notion keep its own drafts?

For pages you have already created, usually yes, because the document lives on their server. Text typed into a new page that was never created may not be, which is where the gap appears.

Will formatting be restored?

No. Form ReDraft stores plain text and restores plain text. Recreating headings, bold text and lists by guessing usually produces something worse than plain text.

Why does restored text sometimes disappear from an editor?

The editor treats its own document model as authoritative and re-renders the surface from it, discarding what was inserted. The events were dispatched correctly; the editor simply wins.

Related Articles