User:DWalden (WMF)/Edit Recovery/Completed sessions

Survey cross-browser compatibility

I performed the most basic capability testing on Opera 101, Edge 108 (both Chromium based) and Safari 16.5.

On Safari and Chromium you can ctrl+z (undo) to return to original article text, but not Firefox.

Do we want to delete recovery data on demand? Cancelling and "discarding" edits does the trick. Clears it from indexedDB.

What if I want to see the difference between my restored edit and current edit? I can use "Show changes" in the wikitext editor.

Exploring data corruption

Is saving wikitext to or restoring it from indexeddb causing any corruption?

https://en.wikipedia.beta.wmflabs.org/wiki/All_Unicode

Editing the above article, adding a space to the end, reloading, then saving/publishing. Checking revision history for no new entry. Adding a space to the end of an article will not count as an edit, but if the wikitext has been corrupted at all by storing or restoring from indexeddb we should see a new revision.

Browsers:

• Firefox 102
• Safari 14.1 and 12.1
• Chromium 115
• Opera 101 (Chromium-based)

Page sections and conflicts

https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit&section=1 https://en.wikipedia.beta.wmflabs.org/w/index.php?title=New_Page_123&action=edit&section=2

Starting a new or editing an existing section (id #n). In another browser, inserting a section before section #n. Reloading section #n in first browser.

We can use "Show changes" to see if there has been an intermediate edit and we can cancel to clear the indexeddb data.

Could we indicate this fact to the user? Could we offer them solutions?

Deleting a section and trying to edit it returns: "Cannot find section" and indexeddb entry left dangling.

The user can re-add the deleted section, but that will clear their indexeddb so they will lose the data for that section.

Does saving a specific section also clear entries for other sections? Yes.

Saving a section also clears an indexeddb entry for the entire page.

Other examples of intermediate edits:

• deleting page
• deleting sections
• moved pages?

Disaster recovery

There is a problem here of experimenter's regress...

Experimenting with using kill to kill the Chromium process.

IndexedDB is stored here for Chromium? ~/.config/chromium/Default/IndexedDB/

and here for Firefox: ~/.mozilla/firefox/<id>.<profile>/storage/default/https+++en.wikipedia.beta.wmflabs.org/idb/

Should we only store data after keyup? What are editors' typing habits?

Ways of killing a process:

sleep 5.5 && kill <chromium/firefox pid>

# Chromium
inotifywait ~/.config/chromium/Default/IndexedDB/https_en.wikipedia.beta.wmflabs.org_0.indexeddb.leveldb/000004.log && kill <pid>

# Firefox
inotifywait ~/.mozilla/firefox/<id>.<profile>/storage/default/https+++en.wikipedia.beta.wmflabs.org/idb/<id>.sqlite && kill <pid>

Either the most recent edit you made was recovered or the one before that. I could see no sign of data corruption (using "Show changes") or where no recovery data was stored or restored (i.e. where it returns to the original wikitext of the article).

I don't know how effective this was as a test. If we wait for the indexeddb file to be written to and then kill the browser (which happens with Chromium), this might be too late. If we wait for the indexeddb file to be opened and then kill the browser (which happens with Firefox), it might be too early. Ideally, we need to kill the process between these two states.

I also repeated the experiments with https://en.wikipedia.beta.wmflabs.org/wiki/All_Unicode to also test possible data corruption.

Repeat with other browsers?

• Tested Chromium and Firefox