fix(track-changes): correct format change description for already-formatted text (SD-2077)

[tupizz]

Summary

Fixes the tracked change comment showing incorrect "removed" descriptions when adding formatting to text that already has different formatting in suggesting mode.

Example: Text has highlight applied. User switches to suggesting mode and bolds it. The tracked change comment said "Format: bold, removed highlight" when it should say "Format: bold". The highlight was never removed.

Root cause

In addMarkStep.js, when a format mark is added in suggesting mode, the track changes system records a before/after snapshot to describe what changed. The display logic diffs these arrays: marks in before but not after show as "removed", marks in after but not before show as "added".

The bug was in the else branch (no existing trackFormat mark on the text): the code dumped all existing non-tracking marks into before, regardless of whether they were related to the change. So when adding bold to highlighted text, highlight ended up in before and bold in after, making it look like highlight was removed and bold was added.

// Before (bug): captures ALL marks as "before" state
before = liveMarks
  .filter((mark) => ![TrackDeleteMarkName, TrackFormatMarkName].includes(mark.type.name))
  .map((mark) => ({ type: mark.type.name, attrs: { ...mark.attrs } }));

Fix

Only capture a mark of the same type as the one being added into before. This correctly handles:

• Pure additions (bold on highlighted text): before = [], after = [bold] → shows "bold"
• Type replacements (changing textStyle color): before = [textStyle{old}], after = [textStyle{new}] → shows "color"
• No false removals: unrelated marks (highlight, italic, etc.) are never included in before

// After (fix): only captures same-type mark being replaced
const existingMarkOfSameType = liveMarks.find(
  (mark) =>
    mark.type.name === step.mark.type.name &&
    ![TrackDeleteMarkName, TrackFormatMarkName].includes(mark.type.name),
);
before = existingMarkOfSameType
  ? [{ type: existingMarkOfSameType.type.name, attrs: { ...existingMarkOfSameType.attrs } }]
  : [];

This matches the pattern already used by removeMarkStep.js, which correctly scopes before to only the specific mark being removed.

Why this approach

The before/after arrays represent the diff, not the full state. They should only contain marks that are actually changing. The removeMarkStep handler already follows this principle (it only puts the removed mark in before). This fix aligns addMarkStep with the same semantic.

Alternatives considered:

• Fixing at the display layer (translateFormatChangesToEnglish): would only mask the symptom. The before/after data would still be wrong, affecting any future consumer of these arrays (e.g., accept/reject, collaboration sync).
• Filtering unrelated marks in before by comparing against after: more complex and fragile. The root issue is that unrelated marks should never enter before in the first place.

Test plan

• Unit test: adding bold to highlighted text → before is empty, after has bold
• Unit test: changing textStyle on text with highlight → before has only textStyle, not highlight
• Behavior test (Chromium/Firefox/WebKit): bold on highlighted text shows "Format: bold", no "removed"
• Behavior test: italic on bold text shows "Format: italic", no "removed bold"
• Behavior test: color change on highlighted text shows "Format: color", no "removed highlight"
• All 736 existing unit test files pass
• All 41 existing comment/track-change behavior tests pass

[linear]

SD-2077 BUG: Tracked Change Displays Incorrect Changes When Applied to Highlighted Text

[caio-pizzol]

@tupizz clean fix, no correctness issues. tests look good. one unused import and a minor cleanup suggestion — left inline comments.

[harbournick]

LGTM

[superdoc-bot]

🎉 This PR is included in superdoc v1.17.0-next.69

The release is available on GitHub release

[superdoc-bot]

🎉 This PR is included in superdoc-cli v0.2.0-next.66

The release is available on GitHub release

[harbournick]

🎉 This PR is included in superdoc v1.17.0

The release is available on GitHub release

[superdoc-bot]

🎉 This PR is included in superdoc-cli v0.2.0

The release is available on GitHub release