The removal of the 'Discard' button from comments in the editing state
complicated the UX of the 'Cancel' button a bit.
Previously:
- Discard deleted the draft completely.
- Cancel cancelled whatever edits were made, and reverted to the prior
draft state. Cancel was also hidden on new drafts.
Currently:
- Cancel cancels whatever edits were made, and reverts to whatever edit
was last stored.
This behavior is problematic, for a few reasons:
- Due to some vestigial code, the actual value of the comment's message
(not just the buffer value '_messageText') was updated any time the
draft comment was edited. This was done to prevent multiple drafts
from being created on the same thread -- that issue was made obsolete
by the removal of buttons from individual comments, and their
consolidation to the thread level.
- If a user cancels a draft, then restarts it (having their text
repopulated from localstorage), then cancels it again, the draft is
rendered as a saved draft comment with the localstorage value, despite
having never been saved at all.
So, with this change:
- Cancel cancels whatever edits were made.
- If a user tries to add a draft in the same place...
- ...and the draft has been saved on the server, the textarea is
prepopulated with the value from the comment received from the
server.
- ...and the draft has NOT been saved on the server, the textarea is
rehydrated from localstorage.
This UX makes sense because...
- Case 1 occurs when a user clicks "Edit" on an existing draft comment -
thus expecting to edit the content shown in the UI.
- Case 2 occurs when a user cancels a draft that they started
constructing, but did not save -- thus there is no suggestion of any
prepopulated value by the UI, _and_ the case in which a draft was
erroneously cancelled during editing can be solved.
Bug: Issue 7709
Change-Id: Iacf9a91fbb0226aba3a518f56edd61f28c15a8ef
998e4cf5b7