A way to restore a lost content (autosave to local storage?)

[Reinmar]

I've just lost 20 minutes of work because I mistakenly clicked "Close issue" and GHRTE didn't save the comment (which GH normally does). Since it overrides how the form works, the "go back" browser option didn't help either.

Besides fixing the "Close issue" button, I'd love to see some way of restoring lost content. Some sort of autosave to the local storage and ways to get the content back from it would be an amazing improvement, also over what GH offers by default. The problem here is that normally you can install browser addons which save you from losing your content but with GHRTE it's gone. Therefore, GHRTE should offer something for that.

[Reinmar]

BTW... let's test whether it gets submitted this time :D

[Reinmar]

OK, so it worked this time. Which means that it might have been... everything. 

That shifts the focus towards – there should be a way to restore your content if something crashed. We're experiencing issues too frequently to ignore this. There was the issue I had, then #135, the editor is crashing on emojis, etc. Being able to get your content back would help.

[fredck]

I'm wondering if the issue that pushed you to open this issue is not related to LastPass, as described here: #135 (comment).

Anyway, we can think about some solution for content loss prevention. One idea could be constantly updating the localstorage copy of the contents on changes. Currently we do it when leaving/refreshing the page only.

@Reinmar, there is one important information though... did the form post happened and the content wasn't saved? I mean, the issue was just closed without your new comment?

[fredck]

the editor is crashing on emojis

@Reinmar, would you mind having an issue for this one?

[fredck]

Part 1 - Current Implementation

Let me give a bit of details on the current implementation:

• Data from the editor is set to the GH textarea "on submit".
  • There is no reliable way to catch the submit of the form, because of the way it's implemented in GH.
  • The only feasible way, is intercepting button.click(). We do so for all buttons type "submit" inside the form (this includes "Comment" and "Close and comment", for example).
• When you navigate away or refresh the page, we use localStorage to save the current editor data (and mode (rte/markdown)).
  • We do exactly what GH does, in fact. It's a reliable way.
  • We clean localStorage on submit, because we assume the data is saved and, especially, we don't want the data to re-loaded (e.g. in the New Issue page).

The above works relatively well and we didn't have had many issues. But still something has been reported, although we have no idea why it got broken.

One possibility is that CKEditor itself broke and the program got stuck. The funny fact is that maybe the user was still able to type after the error occurred so they not even noticed that (I have seen this in the past)... until maybe posting the form and losing everything. It would be great if CKEditor would "reliably break", making it easier to debug issues.

[fredck]

Part 2 - Live HTML Data Processor

The idea is simplifying things a lot -> update the GH textarea on every change. In this way, we don't care about "on submit sync" or having to handle the various submit buttons. I would love to go with this.

Buuuut, the reason why things have been done differently is because I figured that calling getData() for every single change could be a performance overkill (please correct me if I'm wrong).

To tackle the performance problem, I had a "great" idea... let's introduce editor.data.view, which will stay in sync with the model, just like editor.editing.view. We could then have a dom element attached to data.view and make it in a way that getData() would be a simple call to element.innerHTML. I even named it "Live HTML Data Processor". It sounded brilliant in my mind.

Now, after a day working on that, I "almost" made it work... and I figured that this is impossible to be done 😭 

That's because features have been developed under the assumption that the "data downcasting" will have to handle just "inserts" but not "removals" and "attribute changes". This can be clearly seen in the list plugin code, for example.

Summing up, the "Live HTML Data Processor" idea (and almost implementation) died 😢

[fredck]

Up next - I need suggestions

Right now, I have two possible ways:

1. Sync the GH textarea on every change by calling getData().
2. Save "raw model data" in local storage on every change. This could be optimized so just changes are updated in the raw data. (How would you do that, btw?).

As for 1, I don't like it, but this seems to be anyway the way people are doing "auto-save" out there.

As for 2, it is not totally safe still because we would keep the current system in place anyway ("on submit sync" and "submit buttons handling"). But it would decrease the potential loss of data.

Suggestions?

[fredck]

the editor is crashing on emojis

@Reinmar, would you mind having an issue for this one?

Oh, found it: #118

[Comandeer]

The issue can happen also in other situations, see #152 (comment)

[fredck]

2. Save "raw model data" in local storage on every change. This could be optimized so just changes are updated in the raw data. (How would you do that, btw?).

I've just concluded the first phase of development for this. I'm introducing the LiveModelData plugin that adds editor.model.data. It's a "live" property that is updated on every change to the editor. It returns a string with the XML representation of the main root in the model. Ofc it can be set using the same data format that it produces.

I'll be using it to update LocalStorage on every change. To be sure about performance, I wanted a simple comparison with the plain editor.getData(). It was jaw-dropping:

The above are the times of I got with Firefox when slowly typing in the middle of a larger content, 3x what we see here.

The code is a bit risky, but the above shows that it's worth moving ahead with it. So now I know which direction to take. A solution should be coming soon.

[stefaniefgray]

This issue is still happening

I accidentally clicked on my own profile page while previewing an issue I was in the process of creating, and just lost 30 minutes of work :/

Text has completely disappeared, back button did not restore. Have used Github since 2014. This is disappointing.