When you are viewing a document with engine X, and comments originally made with engine Y are present, this should be indicated ("This comment was made while looking at this change as a Q document."). They should probably also be moved to the top/bottom of the file, at least by default, since "Jupyter line number 9 = raw source line number 9" is an exceptionally bad and confusing guess at how to map line numbers.

• In previews, suggestions aren't highlighted properly (likely just missing CSS).

• j, etc., can incorrectly select blocks inside a diff inside a suggestion.

I made a change to drop unchanged context from suggestion views, but I don't particularly like it. It changed this:

• 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.

The inline comment context menu does not apply the correct cursor ("pointer").

I still have a lot of inline style attributes to clean up and then I'm sure there will be a long tail of weird edge cases, but this is getting pretty close:

• This isn't necessarily terribly useful in practice, but a UI hint about whether or not we've actually saved a draft would make debugging slightly easier.

• The inline comment context menu does not apply the correct cursor ("pointer").

• The line-triggered reticle should be updated to use the hover-reticle cell style.

• In Jupyter notebooks (and, theoretically, other rich content) we find an inner <td /> before finding the content <td />, preventing context menus from working.

• In Firefox, multi-line selections don't generate a context menu properly.
• Clicking the "New Inline Comment" action disables the oncopy behavior onmousedown but doesn't take the action until onclick. This creates a flash of selected content which spans both sides of the change and looks odd.
• Context selection doesn't activate in unified mode, maybe because data-copy stuff is being used to identify content cells.

• When you create an inline, do nothing, then click "Cancel", inlines briefly count themselves in the paths panel.

I have a patch which allows you to edit published inlines. It "works", but it causes a ton of weird side effects when you perform an edit.

Inline stuff:

Probably kicking this, but:

See PHI1703. The document engine the original comment was made on should be persisted, so email can do something better than dumping unrelated lines of text into the body.

The preview section underneath the comment area doesn't mark "editing" inlines in any special way.

Not exactly related, but:

In D21225, I made the "attach_inlines" parameter to differential.createcomment a no-op. This originated in D7019 and was a "Facebook Feature" at the time with no use case or rationale.

• Audit is missing the "attach, drop-voided, upgrade-to-draft-text" code that Differential has when submitting "isEditing" comments.
• Audit is missing the entire submit-editing workflow in general.

In Chrome (Version 64.0.3282.140 (Official Build) (64-bit)) the inline comment buttons have a hot-spot for tooltips to party

• When you load the page and there are multiple inlines which we're pushing into an edit state, we focus and select them in sequence (and the overall order is basically random). The focus + select behavior should be disabled for this edit pathway.

• When we force saves of inlines, we probably (?) save the last saved state, not the draft state.

• When you click a line, type text, get a draft, reload the page, and cancel the inline: we cancel into an empty state.

• When you click a line, type text, then go to the list view: the revision draft state has not re-synchronized based on an empty inline comment with only a draft, because saving a draft doesn't trigger a re-sync.

• In the preview, editing inline comments don't reflect draft states correctly.

• The preview section underneath the comment area doesn't mark "editing" inlines in any special way.
• The "view" links in the preview don't jump to editing comments correctly.
• The "delete" links in the preview don't put editing comments into the right state (delete is normally impossible for an editing comment).

As of D21188, inlines have these remaining weird behaviors:

In the DOM, inline comments are currently structured as a "comment row", followed by zero or more related rows (which may contain the editor UI or the undo UI).

OKAY SO

In Chrome (Version 64.0.3282.140 (Official Build) (64-bit)) the inline comment buttons have a hot-spot for tooltips to party

This seems to have calmed down.