Restoring form-data on editor panel

[ErisDS]

Did you ever type out a big long post in the Ghost editor, accidentally hit a link, back button or close the tab, and then get it back to find you've lost everything?

Did you ever type out a big long comment/issue on Github, accidentally hit a link, back button or close the tab, and then get it back to find your comment/issue still waiting to be submitted?

I believe that this is a browser behaviour which depends on certain things. Something about the way that CodeMirror works doesn't work with the behaviour. That or there is some fancy thing on github that we should emulate.

At the very least, I'd like someone to investigate why Ghost's editor doesn't exhibit this behaviour, and Github does, and what the requirements are for fixing it.

[JohnONolan]

I think I know the answer to this - it's quite simple... if I'm right - browser preserve content in side a <textarea> coremirror effectively invalidates our content textarea, so the browser can't hook into it.

[ErisDS]

I think it also may have to do with our caching settings...

update: adding res.setHeader("Cache-Control", "private"); to the editor route in admin.js makes it work for the title field.

[ErisDS]

This is another thing that I would love for someone to investigate and let me know what they think is causing it. Does this always happen for CodeMirror? Is there a way around it?

Perhaps we could implement a solution with localstorage?

[ErisDS]

I would really like someone to volunteer to investigate why this is happening and if there is a way to resolve it. @matthojo's #691 is an excellent solution, but not as excellent as making it just work (tm)

[codeincontext]

Immediate thought from me is to hack it up with localstorage. But it would cause other issues if -for example- you were editing something that has changed since you left the tab.

Maybe it would work if you just set a 30 second timeout on it. I think by then you'd notice if you've accidentally gone somewhere

[ErisDS]

@gotdibbs, any conclusions you can draw about this would be much appreciated.

[gotdibbs]

Upon further investigation it appears that showdown works fine by itself, its actually codemirror that seems to be the culprit. My assumption is that since codemirror is hiding the textarea (setting display: none) that the browser is then assuming it doesn't need to remember what's in that textarea.

A couple of things for reference:

• We narrowed it down such that the automagic restore seems to be a feature of only FireFox and Safari.
• Back and Forward navigation of the browser allows a "restore", but we believe this is a distinct behavior from what this issue is concering which is closing a tab and reopening it.

[ErisDS]

Gonna punt this to 0.4 for now.

[rschmukler]

@ErisDS Please consider implementing a simpler solution in 0.3. The worst case of this hitting backspace when you preview (thinking that you're in the editor) , the browser registering it as a back-button press, and losing everything. Even a simple JS check to see if there's content in the text area and popping up saying "If you navigate away, you lose everything" would suffice. If you're open to it, I may even implement it.

I just lost a 2 hour-in-the-making blog post (for the 2nd time) because of this, making me completely unwilling to use the built in editor until something is in place.

[jgillich]

To trigger such an alert, edit the enableEditor function in server/views/editor.js like this:

this.editor.on('change', function () {
    self.renderPreview();
    document.getElementById('entry-markdown').value = self.editor.getValue();
});

This updates the textarea on each change in the editor; however this has one huge downside: It will trigger the alert even if the page has been saved before.

From what I've found out, browsers don't remember the value of textarea fields in general, only the one of input fields. There are a few browser plugins that implement this functionality that wouldn't exist otherwise.

But to be honest, I have no idea how Github does it. Works very well here, even without JavaScript.

Edit: I just noticed that it actually works fine when editing in Firefox:

But it doesn't work when creating a new post, no clue why...

[ErisDS]

For everyone bumping into this - the shortest term solution is ensuring you use the save button at regular intervals, the keyboard shortcut ctrl + s is also available.

However, we are aware that this is a common problem. There are a number of things that can be done to mitigate it. Including warning messages when leaving with unsaved changes, working to ensure we aren't overriding the browser feature which recalls the data (this works wonderfully on GitHub), as well as autosave.

PRs are very welcome for these issues.

[ErisDS]

We now have an alert message for anyone who attempts to leave without saving, which is potentially even more useful than this. Paired with #1413 (auto save) we should be fine, so closing this.