Feature summary:
EditRecovery would listen to other tabs (e.g. via BroadcastChannel) and suppress recovery and popups if the same page is already being edited in another tab.
Use case(s):
I want to open multiple tabs editing the same page without popups so I can compare and contrast wikitext in different states without frustration.
Do we also want to suppress saving a user's edits as well?
Can we always assume the first tab a user opens is the one they are editing? What if they open a tab first for reference and a second tab to edit?
What if I am editing a page, leave the tab open, forget about it, and start editing the same page in a different tab? I might be annoyed that Edit Recovery is not working and not know why. I guess we could inform users of this fact.
In the case of restoring multiple tabs after a disaster (e.g. browser crash), can we predict the order in which the tabs will be restored? Will it be in the order the user opened them originally?
There's the "Discard changes" button -- shouldn't that be enough to fit this use-case?
As I explained in T347867#9436743 my frustration was mainly about comparing different revisions, so if as Sam said in T347867#9440187 it no longer saves changes to old revisions, the frustration will be significantly reduced. But even better if, instead of restoring an edit without asking, it asked me if I wanted it restored first (at least for a page already being edited).
Moreover, "Discard changes" being the only way to see the original state means you can't ever look at the current published source and keep your unpublished edit at the same time (without active circumvention like going incognito). This strikes me as a fatal flaw.
I can think of a few ways to go about it:
#1 does seem to be the case already, in that "Discard changes" doesn't actually delete the data unless the form receives an input event, but then the button label is deceptive. Either it should actually do what it says, or the label be changed to something more descriptive (e.g. "View current source"). I prefer the relabeling because that at least cancels the aforementioned flaw—the ability to manually delete data can be relegated to the special page (T353996).
#3 is arguably most user-friendly but might be too complex to implement and maintain. I like #2 as it allows prompt before overwriting if the user opted to "View current source" and proceeded to make changes to it.
"Discard changes" doesn't actually delete the data unless the form receives an input event, but then the button label is deceptive. Either it should actually do what it says, or the label be changed to something more descriptive (e.g. "View current source")
That's a good point. Personally I'd prefer it actually delete the data. Having to navigate to the Special page seems like a lot when just want something to "go away".
I think it might also be good to look to at current behaviour of edit recovery in VE and DiscussionTools. Neither of those have a "discard" function, yet I haven't heard of any complaints. How do they handle the scenario of editing the same page over multiple tabs?
Neither of those have a "discard" function, yet I haven't heard of any complaints.
DiscussionTools does. I've at least seen complaints about how DT jumps to the draft no matter what (even if you're viewing a diff, even if the URL contains a hash), which I've found annoying too. Granted, not quite the same, but a difference is that you can still view the rest of the content with VE or DT whereas action=edit is about the only way to view the page source that's accessible from the regular interface.
How do they handle the scenario of editing the same page over multiple tabs?
My understanding is that they go with #1, i.e. whichever was edited last. I guess that's the KISS option so you persuade me.
But it would definitely be a humane thing to do to have at least an unintrusive notification every time a draft for the same page you're editing is saved (overwritten) or deleted in another tab, so that you'll at least know it when you accidentally lose a ton of work by discarding changes and then proceeding to edit. The beforeunload reminder is now of less value because you can be under the impression that the work is saved and safe.
DiscussionTools uses localStorage but is only ever concerned with adding comments and not editing existing ones so I guess that makes things easier. VisualEditor uses session storage I think, so doesn't have to worry as much about multiple simultaneous windows (I think you have to 'duplicate tab' in order to end up sharing session storage).
Personally I'm more keen to keep it simple at least for now, and stick with how it's working now, but revisit this once we've rolled out to a couple of pilot wikis (hopefully in a couple of weeks' time).
Agree that we should keep it simple for now. I wonder how often contributors are editing in multiple tabs, in VE, vs other editors... Once we have it rolled out and get feedback, we can revisit.