I noticed that currently if we type a comment/reply and click "cancel" and then open the reply box again, it retains the typed comment, which is pretty neat IMO. Also, if you now start drafting a reply to another comment and do the same thing, it will retain the content of both replies, that is cool too. Although not sure if it's intentional.
But, when I post a reply it clears the other content/other draft replies, is there a way we can retain those even after posting a reply, since it's not really refreshing the whole page (or atleast visually) I expected it to retain those comments as well.
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T233443 [Epic] Reply Tool | |||
Resolved | ppelberg | T235923 Replies v1.0: release replying to specific comments | |||
Resolved | • iamjessklein | T236921 Replies v1.0: conduct usability testing | |||
Resolved | Ryasmeen | T239961 QA Replying v1.0 on prototype server | |||
Resolved | ppelberg | T239966 [Pre-deployment testing] Retaining draft comments/replies |
Event Timeline
Given the page can be reloaded we would need to implement LocalStorage/SessionStorage based auto-save to support that.
Great spot, @Ryasmeen.
I think it's reasonable to expect drafted comments to remain "intact" even after a comment has been posted.
To Ed's point [1], the functionality you are describing [2] will come once auto-save is implemented (see: T240257).
In the meantime, before auto-saving is implemented, we are going to add in a feedback message that warns contributors their drafted comment will be discarded when they:
- Click "Cancel": T240271
- Attempt to navigate away from the page (e.g. via the browser's back button, closing the tab, etc.): T240259
- "...is there a way we can retain those even after posting a reply...?"
WE will revisit this ticket once V2.0 is deployed and we revisit implementing T240257
I noticed that currently if we type a comment/reply and click "cancel" and then open the reply box again, it retains the typed comment
This was not intended behaviour and was fixed. We should close out this ticket as there should be a separate one for auto-save.