Feature summary:
Edit Recovery should save editing form data on the visibilitychange event, so that the latest version of the page is saved when the user navigates away.
Use cases:
As a contributor, when I'm typing away trying to get my thoughts into text, I sometimes accidentally close the tab. Because I'm such a fast typist, the default five second debounce time means that I've lost a good ten words of prose.
Benefits:
The edit recovery data will be the most up-to-date possible.
As IndexedDB is async, any save triggered by a tab closing will not finish before the tab shuts down.
I've been wondering about that. Perhaps we should add it to beforeunload as well as visibilitychange, with the former working for window-close, and the latter for things like mobile browsers closing tabs (which I think is sometimes not caught by beforeunload). Using beforeunload breaks the backwards-forwards caching, but that's moot because we're already using it for the unsaved-changes alert.
Change 953744 had a related patch set uploaded (by Samwilson; author: Samwilson):
[mediawiki/core@master] Edit Recovery: save data on beforeunload and visibilitychange
Reading a bit more about this, it's sounding like there's not much we can do to reliably add an additional save before the window is closed — but then we don't need it to be perfect.
This is a good test illustrating the issues: https://gist.github.com/vaughnroyko/0c9547cb0f00af933cc8
Basically, it varies between browsers. Firefox seems to handle it pretty well (although not 100% of the time), but mostly it's up to the performance of the particular machine and what data is being saved.
Ultimately it's probably not too much of an overhead to add both events (which is what I've done in the above patch), and it seems to improve the experience a little bit. Happy to not bother if others think it's not needed though!
Ultimately it's probably not too much of an overhead to add both events (which is what I've done in the above patch), and it seems to improve the experience a little bit. Happy to not bother if others think it's not needed though!
As long as it is atomic, this is probably fine.
Change 953744 merged by jenkins-bot:
[mediawiki/core@master] Edit Recovery: save data on beforeunload and visibilitychange
@Samwilson I cannot get it to clear the indexeddb data when I click Cancel on the edit page, like it did before. Is that because it is triggering one of the events?
It does clear it when you save the edit.
Another potential risk of this change is that every time an editor visits the Source Editor for a page Edit Recovery will save the current content (even if they don't make an edit).
This could lead to a lot more unexpected or unwanted content recovery. For example, if I am only interested in looking at the wikitext of a page I will keep seeing the same content (at least for 30 days), regardless of any intervening edits.
Change 965681 had a related patch set uploaded (by Esanders; author: Esanders):
[mediawiki/core@master] Edit recovery: Don't save until form field is modified
Change 965681 merged by jenkins-bot:
[mediawiki/core@master] Edit recovery: Don't save until form field is modified
Change 967683 had a related patch set uploaded (by Samwilson; author: Samwilson):
[mediawiki/core@master] Edit Recovery: only save when form contents has changed
Change 967683 merged by jenkins-bot:
[mediawiki/core@master] Edit Recovery: only save when form contents has changed
I wonder if this has made Edit Recovery more vulnerable to issues like T351869 and T351821, as Tacsipacsi also pointed out https://gerrit.wikimedia.org/r/c/mediawiki/core/+/967683/3#message-32d447f16e78bb34e30134a5b60b61c2ef67ac13.
We save edit recovery data when we close or switch a tab.
One risk of this change is if you are editing the same page on several different tabs at the same time. For example:
The wikitext from only one tab will be saved in Edit Recovery. But, which tab that will be might be unpredictable to the user and it might not be the most recently edited one.
I don't know how likely users are to do this and what behaviour we consider desirable in these circumstances.
I am going to move this into done as I think it has been here long enough.
Thanks @dom_walden, and those are good questions. I think the whole topic of what to do when simultaneously editing the same page in multiple places is going to come up a bit more — and we can sort it out at least to some extent in some of these tasks:
T351435: EditRecovery could lead to users accidentally overwriting other (or their own) edits
T354392: Don't recover changes to a page already being edited in another tab