Undo-ing sometimes deletes the entire contents of a file

[hanaral]

What Happened

I was just editing a HTML document, undid something, realised I could no longer open the file in my browser from the sidebar, reopened the app to see if it would fix it and turns out the text is all gone. I didn't have any recent backups, which is my fault - but this is pretty bad behaviour if it's constantly autosaving. I've also realised that undoing every so often causes all the text in a file to disappear, but unoing again or redoing seems to fix that.

Expected Behavior

Undoing or redoing should not randomly delete all your work. There should also be copies saved periodically since it's autosaving everything.

Steps to Reproduce

1. Edit a text document and repeatedly undo/redo
2. Keep making changes until erronious behaviour

Platform Information

elementary OS 6 Daily

[jeremypw]

This is worrying (!) If you notice any pattern in which operation is undone before the error, or the timing of operations please post here. I'll see whether I can reproduce as I am using Code a lot more recently ...

[jeremypw]

Please could you confirm whether you have the "Save files when changed" setting "on"? Was the file being edited originally empty? Was the file being edited "new" or had it been saved into normal storage? I presume you were undoing using <Ctrl>z?

Most of the undo/redo logic is handled by the Gtk.Widget in fact, not Code. All text changes should be undoable, the only exception I have found so far is (re)loading the content of a document from a file and this gives rise to a warning dialog that the current contents will be lost.

[hanaral]

I've gotten it quite a lot in the past since it's been my main text editor since I switched to elementary OS.

1. I though you couldn't turn off it's ability to save every change - so I've never tried to disable it.
2. The file was one I had been working on from my external hard drive for over a week, so it wasn't new. In my previous school year I was using my flash drive a lot - maybe it has to do with gio and file state saving?
3. Yes, I was using <Ctrl>z and <Ctrl><Shift>z to constantly try CSS classes (probably isn't linked to it being CSS) I also don't tend to use filechooser dialogs for individual files, I just open the file directory from Files and pick the document from the sidebar.

[jeremypw]

Thanks - I'll try to reproduce using the same conditions. You can change the way Code saves using the "Preferences" option on the application menu (the cog-wheel on the right of the headerbar).

[jeremypw]

I have not experienced this so far while using a flash drive. If this happens to you again try pressing <Ctrl><Shift>o (or the "Restore" button on the headerbar. This should reload the original content of the file as it was when the session started.

It is possible that if typing fast you accidentally hit e.g. <Ctrl>A then Enter or some other key combination that deletes the entire contents of the file. However, this should always be undoable with <Ctrl>z

I am not sure if there is a maximum depth for the undo stack, but I have tested up to 300 levels of undo for adding new blank lines after deleting the contents and still retrieved the contents OK.

[jeremypw]

One thing I noticed is that Ctrl>z does not work if the document becomes unfocused (e.g. focus is in the search bar). So if you do a Search/Replace you have to click on the document before you undo with Ctrl>z

[hanaral]

@jeremypw I managed to reproduce it! I can sometimes do it by making changes to the HTML document, waiting for the hard drive it's on to stop making writing sounds, and then hitting refresh on Ephemeral (there seems to be a time window)

https://user-images.githubusercontent.com/58219504/112459931-476d9580-8d56-11eb-9bd4-9a8d3e61b5d9.mp4

The screen capture is me undo-ing, undo-ing and then redo-ing twice to 'jump over' the state where it's empty. Maybe it's because the undo state that's being saved to cache messes up when it's saving and also being opened externally at once?

Something like this:

1. Makes changes - previous state saved
2. Makes changes again, but openes app before it's complete - previous state unable to be saved
3. Un-does changes made - previous state wasn't able to be saved so file is empty

Somehting else I notice when it happens (when the previous state becomes empty) is that the document jumps to the beginning when you focus the window again.

[jeremypw]

Yes, if you are operating on a file with another application at the same time as with Code that is a whole new ball game! I'll try to reproduce.

[jeremypw]

I haven't found any unexpected behaviour messing about with an HTML document and Ephemeral. Note I have an SSD so saving is very fast.

[jeremypw]

While working on #1309 it was noted that if the text of the buffer is reset to new content (because of external changes) then there is an intermediate state where the old content is deleted before the new content is set. So two <Ctrl>Z presses are needed to restore the old content. The contents of the file are not deleted only the contents of the view, at least until the next save is performed. To prevent this in #1309 undo is simply disabled when loading new content from an external change. However, this is only done if there are conflicting changes to the document otherwise a confirmatory dialog appears. Editing a document with two apps simultaneously is not recommended.