Page MenuHomePhabricator

Add auto-save to the reply widget
Closed, ResolvedPublic

Description

Description

The contents of contributors' unpublished comments should be saved automatically if their browser crashes.

In Version 1.0, a contributor's unpublished comment will not be retained if they close the browser tab in which said comment was being drafted.

Open questions

  • How should it be communicated to contributors they have drafts that have been saved?

When the browser of someone who has drafted a reply crashes, upon re-opening said browser, the page they were drafting their reply on will re-load and on that page, the reply input where they were drafting their comment should be visible along with their unpublished comment.

  • What happens if the parent comment is deleted or moved? Will the reply be discarded, or will it be resurfaced elsewhere?

We assume the likelihood of the two scenarios (browser crashing and the comment someone is drafting a response to being deleted) occurring sequentially is low enough for us to omit designing for in our initial approach. #todo: @ppelberg file task

  • Is it expected that the user will only be drafting one comment at any given time?

For right now, yes, considering it is only possible to draft one comment at a time using the new Replying tool.

Done

  • The following is implemented for the Reply tool's source and visual modes: When the browser of someone who has drafted a reply crashes, upon re-opening said browser, the page they were drafting their reply on will re-load and on that page, the reply input where they were drafting their comment should be visible along with their unpublished comment.

References

Related tickets to review/understand

Event Timeline

Esanders renamed this task from Build auto-save to Add auto-save to the reply widget.Dec 10 2019, 2:53 PM

What happens if the parent comment is deleted or moved? Will the reply be discarded? Or is it expected that the user will only be drafting one comment at any given time?

What happens if the parent comment is deleted or moved? Will the reply be discarded? Or is it expected that the user will only be drafting one comment at any given time?

Good question, @Jc86035. I don't think we have an answer for this question yet. To make sure it gets addressed, I'm adding this question to the "Open questions" section of the task description.

In the meantime, what would you expect to happen if the comment to which you've drafted a reply gets deleted before you've had the chance to publish said comment?

Update: 10-Dec

Approach to auto-save:
The task description now reflects the below./

For v1.0 of replying, we are planning to take a "disaster recovery" approach (read: sessions storage) to auto-save.

This means if a contributor's browser crashes, the content of their reply will remain "intact" if and when the browser restores the contributors tabs.

This does not mean a contributor's unpublished comment will be retained if they close the browser tab in which said comment was being drafted.

In the future, we will explore a more robust approach to auto-save. #todo @ppelberg create this ticket

In the future, we will explore a more robust approach to auto-save. #todo @ppelberg create this ticket

Aforementioned "ticket": T241404: Implement a way to retain draft comments

Notes: 7-April
Notes from conversations @Esanders and I had just now...

Open questions

  • How should it be communicated to contributors they have drafts that have been saved?

When the browser of someone who has drafted a reply crashes, upon re-opening said browser, the page they were drafting their reply on will re-load and on that page, the reply input where they were drafting their comment should be visible along with their unpublished comment.

  • What happens if the parent comment is deleted or moved? Will the reply be discarded, or will it be resurfaced elsewhere?

We assume the likelihood of the two scenarios (browser crashing and the comment someone is drafting a response to being deleted) occurring sequentially is low enough for us to omit designing for in our initial approach. @ppelberg FILE TASK

  • Is it expected that the user will only be drafting one comment at any given time?

For right now, yes, considering it is only possible to draft one comment at a time using the new Replying tool.

The above is now represented in the task description.

Change 587992 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] Implement auto-save for ReplyWidgetPlain

https://gerrit.wikimedia.org/r/587992

Updates from conversation with @Esanders:

  • https://gerrit.wikimedia.org/r/587992 implements session storage auto-save (read: disaster recovery) in the source text input mode
  • Another patch is needed to implement the same in the visual text input mode; the patch for this will be attached to this task.

Change 587992 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Implement auto-save for ReplyWidgetPlain

https://gerrit.wikimedia.org/r/587992

Updating the task description's "Done" section to make explicit mention of auto-save needing to be implemented for the Reply tool's source and visual mode.

ModeStatus
source✅done [1]
visualin progress

  1. @Esanders if this is not correct, please comment as much.

Change 593273 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] Add autosave support to visual mode

https://gerrit.wikimedia.org/r/593273

Change 593273 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Add autosave support to visual mode

https://gerrit.wikimedia.org/r/593273

@Esanders/@ppelberg: I checked the auto-save functionality for both visual and source mode of reply widget. It is retaining the draft comment on both modes when I reload the talk page. However, if I close the tab and then re-open, it does not. The browser does tell the user that the changes might not be saved, but still wanted to check if this case/scenario was also supposed to retain the draft comment.

If you re-open the same tab (ctrl+shift+t) it should keep your edit. It should also warn you when you are closing the tab if you have unsaved changes.

If you re-open the same tab (ctrl+shift+t) it should keep your edit.

It actually doesn't keep it. But that's probably acceptable.

(If we wanted to change that, then I think it would require doing T218663 first)