When you "Quote" a comment, then cancel, the comment disappears from the UI.

Broadly, the issue here is that the "Cancel" button on the edit interface for an inline comment sometimes means "Just Exit Edit Mode", sometimes means "Save The Current State for Undo, Revert to Previous State, Then Exit Edit Mode", and sometimes means "Delete".

(A) The "Cancel" button should mean "Delete" if:

1. the comment has never had "Save" clicked before; and
2. the text is the same as the original/default text; and
3. the suggestion is disabled, or the suggestion is the same as the original/default suggestion.

(B) The "Cancel" button should mean "Just Exit Edit Mode" if:

1. the comment has had "Save" clicked at least once; and
2. the text is the same as the original state; and
3. the suggestion is disabled, or the suggestion is the same as the original state.

(C) The "Cancel" button should mean "Save Undo, Revert, Exit" in all other cases, which are:

1. the text differs from the original/default text; or
2. the suggestion is enabled and differs from the original/default text.

Note that in cases (B) and (C), merely changing the "has suggestion" state shouldn't "count" as an edit. If you click "Edit", change the suggestion state only, then click "Cancel", you should get "Just Edit Exit Mode", with no "Undo'.

This behavior is currently buggy. In particular:

• Rules (A.1) and (B.1) don't know if the use has ever clicked "Save".
• Rule (A.2) is implemented as "the text is empty". This matters when quoting a comment.
• Rule (A.3) is implemented as "the suggestion is empty".
• Some subset of rules don't know the default suggestion text.
• Neither the client nor server are really authoritative here and they implement slightly different rules.

I think the fixes here are:

• When a comment is created, a "comment has never been saved" flag should be set. This flag should be cleared when the user clicks "Save". (Doing it this way, instead of a "saved" flag, gives all existing inlines the right state.)
• Inline comments in all phases should be aware of the default suggestion text.
• Make the client authoritative about whether an action is a "cancel" or a "delete".
• Correct the client rules to align with the above.

This should also allow correction this issue, from T13534:

Inline comments with suggestions don't "know" that they're empty when the suggestion is the same as the context text.

• Create an inline. Suggest edit. Don't change anything. Save. You get a blank inline with no suggestion and no content, when this inline would normally delete itself.

This should likely follow similar lines:

• Make the client fully authoritative about whether an operation is a "Save" or "Delete".
• A "Save" is a "Delete" if:
  • the comment text is empty; and
  • the "has suggestion" state is disabled or the state is the same as the default state.

Currently, the inline code partially conflates four separate content states:

1. The initial content state, i.e. the state the comment had when it was created.
2. The "saved" content state, i.e. the last state which the user clicked "Save" on.
3. The loaded content state, i.e. the state the content had when the page was loaded.
4. The current content state.

I got fairly deep into implementing everything above, but I think my approach (which added various new attributes to track additional state) isn't very good, and the most natural representation of the state is just better separation of these checkpoints.

The "Cancel" button should mean "Delete" if...

This isn't quite right. Since the "Cancel" state of an inline that hasn't been saved yet is always to delete it, we really have two different decisions:

• What's the cancelled state? "Deleted" if never saved before, previous state if ever saved.
• Can the action be undone? Mostly follows the above logic.