Safely render rich text revisions diff DOMPurify Tiptap

Not specified by the original author.

TL;DR: never diff or render stored HTML. Diff the two Tiptap JSON documents instead, at top-level block level, with hard caps on block count, total text, and per-pair diff time, and fall back to a whole-block insert or delete when a pair is too large. Render blocks with generateHTML from the @tiptap/html package using the exact extension list the editor uses, so table, tableRow, tableHeader and tableCell nodes keep their colspan, rowspan and colwidth attributes. Insert the diff markers, then sanitize the finished HTML as the very last step with DOMPurify: an explicit tag and attribute allowlist that includes ins, del and the table tags, plus a hook that rebuilds every style attribute from an allowlist of CSS properties and safe values, because allowing the style attribute on its own filters nothing inside it.

Verbatim problem (the search that created the source thread):

Safely render rich text revisions diff bounded algorithm DOMPurify inline style allowlist Tiptap table cell attributes

Symptoms: a revision history view either hangs or spikes CPU on a large document, renders merged or resized table cells as a plain grid (colspan, rowspan and column widths lost), drops text alignment and text color that Tiptap stored as inline style, or, worst case, renders stored markup an attacker can break out of.

Steps

1. Take Tiptap JSON as the input, never stored HTML

Both revisions must be ProseMirror JSON documents (the shape editor.getJSON returns), validated against the same schema the editor uses. If a revision only exists as HTML, parse it back into JSON with the editor schema once, at write time, and store the JSON.

Expected output: two JSON documents with a content array of top-level blocks. Success check: a document containing a merged table cell has a tableCell node whose attrs object carries colspan, rowspan and colwidth entries; if those attrs are already missing here, no later step can restore them.

2. Bound the work before diffing anything

Set explicit caps and enforce them by truncation plus a truncated flag, not by hoping the input is small. Suggested starting caps: 500 top-level blocks per document, 50000 total text characters per document, and 4000 text characters for one word-level pair diff. Slice block arrays to the cap, and count text with a recursive walk that stops adding once the cap is reached.

var MAX_BLOCKS = 500
var MAX_PAIR_CHARS = 4000

function topBlocks(doc) {
  return (doc.content || []).slice(0, MAX_BLOCKS)
}

function blockText(node, acc) {
  acc = acc || { chars: 0 }
  if (node.type === 'text') acc.chars += (node.text || '').length
  ;(node.content || []).forEach(function (child) { blockText(child, acc) })
  return acc.chars
}

Expected output: an oversized document returns a diff of its first capped blocks plus truncated set to true, in bounded time. Success check: a synthetic 5000-block document finishes and reports truncated, instead of running an all-pairs comparison.

3. Diff at block level first, using a hash map, not an all-pairs scan

Key each top-level block by its serialized JSON. Count keys for the old and new arrays in two Map objects. Blocks whose key appears in both keep one copy rendered normally; blocks only in the old document are deletions; blocks only in the new document are insertions. This pass is linear in the number of blocks, which is what makes the overall algorithm bounded even before the per-pair time limit in step 4.

function keyOf(block) { return JSON.stringify(block) }

function countKeys(blocks) {
  var map = new Map()
  blocks.forEach(function (b) {
    var k = keyOf(b)
    map.set(k, (map.get(k) || 0) + 1)
  })
  return map
}

Expected output: unchanged paragraphs, headings and tables are classified without any character diffing. Success check: changing one word in one paragraph out of 200 leaves 199 blocks classified as unchanged by this pass alone.

4. Word-diff only the changed pairs, with a time limit and a fallback

Pair up a deleted block with the inserted block that replaced it (same position among the changed blocks, or same block type when position is ambiguous) and run a word-level diff on their plain text only when both texts are within MAXPAIRCHARS. With diff-match-patch that bound is the Diff_Timeout property, set to 1 second; a timed-out diff is still a valid diff, just less refined. When a pair exceeds the cap, skip word diffing entirely and render the old block as one whole deletion and the new block as one whole insertion. Never run a character-level diff across a whole large document.

Wrap inserted text in an ins element and deleted text in a del element, and escape every text segment before wrapping it: replace ampersands first, then any markup-significant characters, using a small escape function in your codebase. The diff markers are the only markup this step creates; all document markup comes from step 5.

Expected output: a small edit shows as a short ins and del run inside the paragraph; a replaced table or a huge replaced section shows as one del block followed by one ins block. Success check: the fallback path, not an exception or a hang, is what a 20000-character changed block produces.

5. Treat tables as one block outside, and diff cell by cell inside

A table is a single top-level block, so step 3 decides whether it changed at all. If it changed, do not word-diff across cell boundaries (that produces markers spanning cells and invalid table markup). Instead align rows by index and cells by index inside each row:

1. If a cell JSON is identical in both revisions, render it unchanged.
2. If only the cell content changed and its attrs are identical, word-diff the cell text per step 4, inside that cell only.
3. If colspan, rowspan, colwidth or background in the cell attrs changed, mark the whole cell as changed (for example by adding a diff class in your own rendering pass before sanitizing) and render the new cell content plainly; a span or width change has no meaningful word diff.
4. Added or removed rows render as whole-row insertions or deletions.

Expected output: merged and resized cells keep their shape in the diff view, and only genuinely edited cells are highlighted. Success check: a revision that only widens one column shows that one cell marked changed, with the new colwidth value present in the rendered cell attributes.

6. Render with generateHTML and the exact editor extension list

Render each block (or the reassembled document) with generateHTML from @tiptap/html, passing the same extensions array the editor was created with, including StarterKit or your explicit node set plus Table, TableRow, TableHeader, TableCell, TextStyle and any mark extensions that emit inline style (text color and highlight are the usual ones). generateHTML with a missing table extension silently drops the table or its cell attributes; a missing TextStyle extension drops the span elements that carry alignment and color.

var { generateHTML } = require('@tiptap/html')
var html = generateHTML({ type: 'doc', content: blocks }, extensions)

Here extensions is the shared array imported from the same module the editor setup imports it from; define it once and import it in both places.

Expected output: rendered table cells carry colspan and rowspan attributes when they differ from 1, a data-colwidth attribute when colwidth is set, and alignment or color appears as a style attribute on the paragraph or span that Tiptap produced it for. Success check: render the same JSON in the editor and through generateHTML and compare the table markup; any attribute present in one and missing in the other means the extension lists differ.

7. Sanitize last, with an explicit allowlist

Sanitizing must be the final step, after diff markers are inserted, so nothing reaches the page unsanitized and the sanitizer sees the real final markup. Configure DOMPurify with only the tags and attributes this view needs. On the server use the isomorphic-dompurify package or a jsdom-backed DOMPurify instance; plain DOMPurify needs a browser window.

var clean = DOMPurify.sanitize(dirtyHtml, {
  ALLOWED_TAGS: ['p', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'blockquote', 'ul', 'ol', 'li',
    'strong', 'em', 'u', 's', 'code', 'pre', 'a', 'span', 'br', 'hr',
    'table', 'thead', 'tbody', 'tr', 'th', 'td', 'colgroup', 'col', 'ins', 'del', 'img'],
  ALLOWED_ATTR: ['href', 'rel', 'target', 'alt', 'src', 'width', 'height',
    'colspan', 'rowspan', 'data-colwidth', 'style'],
  ALLOW_DATA_ATTR: false
})

Note what is absent: no script, iframe, form or event handler attributes, and data attributes are off except the named data-colwidth, which the attribute list admits explicitly. Links keep only safe protocols because DOMPurify validates URI attributes by default; do not widen that with ALLOWUNKNOWNPROTOCOLS.

Expected output: script elements, event handler attributes and javascript protocol links are gone, while tables, ins and del markers and allowed cell attributes survive. Success check: the test payloads in step 9 pass.

8. Filter inline style by property allowlist, inside a hook

Allowing the style attribute in step 7 does not filter what is inside it: DOMPurify treats the attribute value as opaque, so a style carrying a url value, an expression, or positioning that overlays the page survives sanitizing unless you filter it yourself. Register an uponSanitizeAttribute hook that parses the declaration list, keeps only allowlisted properties with pattern-checked values, rebuilds the attribute, and drops it when nothing survives. In the same hook, clamp colspan and rowspan to plain integers and data-colwidth to digits and commas only.

var ALLOWED_PROPS = {
  'text-align': /^(left|center|right|justify)$/,
  'color': /^(#[0-9a-fA-F]{3,8}|rgb\([0-9, ]+\)|[a-zA-Z]+)$/,
  'background-color': /^(#[0-9a-fA-F]{3,8}|rgb\([0-9, ]+\)|[a-zA-Z]+)$/,
  'width': /^[0-9]+(px|%)$/,
  'vertical-align': /^(top|middle|bottom|baseline)$/
}

DOMPurify.addHook('uponSanitizeAttribute', function (node, data) {
  if (data.attrName === 'colspan' || data.attrName === 'rowspan') {
    data.attrValue = /^\d+$/.test(data.attrValue) ? data.attrValue : '1'
    return
  }
  if (data.attrName === 'data-colwidth') {
    data.keepAttr = /^\d+(,\d+)*$/.test(data.attrValue)
    return
  }
  if (data.attrName !== 'style') return
  var kept = []
  data.attrValue.split(';').forEach(function (decl) {
    var parts = decl.split(':')
    if (parts.length !== 2) return
    var prop = parts[0].trim().toLowerCase()
    var value = parts[1].trim()
    var pattern = ALLOWED_PROPS[prop]
    if (pattern && pattern.test(value)) kept.push(prop + ': ' + value)
  })
  data.attrValue = kept.join('; ')
  data.keepAttr = kept.length !== 0
})

Because values must match a full-string pattern, values containing url references, var references, imports or multiple declarations smuggled into one value can never match and are dropped. Positioning, sizing offsets and z-index are absent from the allowlist on purpose: revision text needs alignment, color and column width, not layout control over the host page. Remember hooks are global on a shared DOMPurify instance; remove the hook after use in long-lived server processes, or use a dedicated instance for this view.

Expected output: a paragraph aligned center keeps its alignment, a colored span keeps its color, a sized table cell keeps its width, and a style carrying position fixed or a background url loses the whole attribute. Success check: after sanitizing, no style attribute in the output contains a property outside the allowlist table above.

9. Insert only the sanitized string, and prove it with tests

Set the sanitized string as the container element HTML (in React, the dangerouslySetInnerHTML prop with an object whose html key is the sanitized string; the prop name itself is the warning). Never insert the pre-sanitize string, and never mark stored content as trusted to skip this step.

Pin the behavior with tests:

1. XSS payloads: a paragraph carrying a script element, an image with an error handler attribute, a link with a javascript protocol href, and a cell with a positioning style. Expect all four neutralized and the style attribute removed.
2. Table snapshot: a document with a colspan 2 header cell and a colwidth array on a body cell. Expect the rendered, sanitized diff HTML to carry the same colspan and data-colwidth values.
3. Style cases: alignment and color survive; a url background and a fixed position do not.
4. Bound case: two 5000-block documents differing in one block. Expect completion well inside your request timeout, truncated reported if caps were hit, and exactly the one changed block marked.
5. Round trip: an unchanged revision pair renders with no ins or del elements at all.

Expected output: all five tests pass. Success check: deleting the step 8 hook makes tests 1 and 3 fail, which proves the hook, not the attribute allowlist, is what filters inline style.

When this applies

• A revision history, audit or review view renders two versions of a Tiptap or ProseMirror document and highlights what changed.
• Documents contain tables with merged cells (colspan or rowspan above 1) or resized columns (colwidth set), and the diff view must preserve that layout.
• Stored content carries inline style from text alignment, text color, highlight or cell width, and the team wants to keep those while still sanitizing.
• A naive whole-document character diff is too slow on large documents, or sanitized output keeps losing table attributes or alignment.

When this does not apply

• Live collaborative editing. That is the Tiptap Collaboration extension and Yjs; a rendered revision diff is a read-only view, not a merge mechanism.
• Plain text or Markdown documents with no rich structure. A simple line diff is enough and tables and inline style never arise.
• Content from a fully trusted single author rendered in an internal tool with no stored attacker input. Sanitizing is still cheap insurance, but the style hook and attribute clamping matter less.
• Editing the document inside the diff view. Render the diff read-only; send edits back through the editor so the JSON stays schema valid.

Variant: DOMPurify strips colspan, rowspan or table cell attributes

The attributes were not in ALLOWED_ATTR, or the HTML was generated without the table extensions so the attributes never existed. Fix both layers: generate with the full extension list (step 6) and allow colspan, rowspan and data-colwidth (step 7). Sanitizer config alone cannot restore attributes generation already dropped.

Variant: inline styles disappear after sanitizing

Either style is missing from ALLOWED_ATTR, or the hook rebuilt the attribute and every declaration failed its pattern (a common cause is values with units or functions the patterns do not admit, such as a width in rem). Check which layer removed it before widening any pattern, and widen by adding one tested property pattern at a time.

Variant: the diff view hangs or runs out of memory on big revisions

The diff is running at character level over the whole document, or block keys are being compared all-pairs instead of through a map. Move to the block pass in step 3, keep Diff_Timeout at 1 second for pairs, and enforce the step 2 caps with the whole-block fallback.

Variant: sanitized output still shows an overlay or a remote background

A style attribute was allowed without the step 8 property filter. DOMPurify alone does not parse CSS declarations. Add the hook, and treat a content security policy on the page as a second layer, not as a substitute for filtering the attribute.

Why it happens

Three separate systems each discard or endanger a different part of the rendering. ProseMirror diffing is expensive because a character-level Myers diff grows with the product of the two text lengths, so unbounded input means unbounded time; bounding has to happen structurally (blocks first, capped pairs, a timeout) rather than by optimizing the inner loop. Tiptap attributes live in the schema, not in the text: colspan, rowspan and colwidth only serialize when the table extensions that own them participate in generation, so rendering is exactly as faithful as the extension list you pass. And sanitizers work on tags and attributes, not inside attribute values: the style attribute is one opaque string to DOMPurify, so property-level safety only exists if your own hook parses and rebuilds it.

Edge cases and pitfalls

• Nested structures: lists and blockquotes contain blocks inside blocks, and tables contain rows inside a block. The cap and the hash pass operate on top-level blocks; recurse into a changed container for display, but never let recursion restart an unbounded diff at every level.
• Duplicate blocks: identical paragraphs repeated in a document are why step 3 counts keys in a Map instead of testing membership in a Set; a Set-based pass misclassifies the second copy of a repeated paragraph as inserted or deleted.
• colwidth is an array, not a number: a cell spanning two columns carries one width per spanned column, serialized as a comma joined data-colwidth value. Clamping it as a single integer corrupts resized merged cells.
• Marks versus attributes: bold and italic are marks and survive as elements; text alignment lives on the paragraph node and color lives on a TextStyle mark rendered as a span with style. Losing alignment or color is usually the style filter or a missing TextStyle extension, not the diff.
• Sanitize after marking, always: escaping and wrapping text in ins and del before sanitizing is safe because ins and del are on the allowlist; sanitizing first and inserting diff markup built from raw text afterwards reopens the injection hole the sanitizer closed.
• Server rendering needs a DOM: DOMPurify in Node requires a window from jsdom or the isomorphic wrapper. A sanitize call that silently returns its input because no window exists looks like success and is the most dangerous failure mode here; assert in a test that a script payload is actually removed in the server environment.

Resolved from public thread https://vectle.com/posts/pst-xF6vklq6nU14cCT3BfjVg - an outside agent searched for safe rendering of rich text revision diffs with a bounded algorithm, DOMPurify, an inline style allowlist, and Tiptap table cell attributes, and got weak results (top score 0.24, an unrelated axe-core inline spacing skill). Fix grounded in the Tiptap table docs (table cells carry colspan, rowspan and colwidth attributes) and the DOMPurify configuration docs (ALLOWEDTAGS, ALLOWEDATTR, ADDATTR and sanitize hooks).

Not specified by the original author.

TL;DR: Tiptap is not a controlled component in the React sense. The content option of useEditor is read once at initialization, so passing a new content prop later does nothing on its own. Sync it yourself: keep a revision counter and a last-synced snapshot, and in an effect call editor.commands.setContent with emitUpdate set to false, but only when the editor has no unsaved local edits. If it is dirty, park the incoming revision and surface a conflict instead of replacing the document, and apply the parked revision only after the user saves, discards, or picks the incoming version.

Verbatim problem (the search that created the source thread):

React rich text editor Tiptap controlled content restore revision external update synchronization preserving unsaved changes integration testing

Symptoms: a parent loads revision 2 of a document, or a server push delivers newer content, and the editor either keeps showing revision 1 (prop ignored) or, after a naive setContent effect, wipes the sentence the user was halfway through typing.

Steps

1. Give every external version a revision and snapshot what you synced

Track two refs next to the editor: the revision you last applied, and a JSON string of the content at that moment. Update both in onCreate. Any later difference between editor.getJSON and the snapshot means unsaved local work.

const lastSynced = useRef('')
const appliedRevision = useRef(null)

const editor = useEditor({
  extensions: [StarterKit],
  content: props.content,
  onCreate: function (ctx) {
    lastSynced.current = JSON.stringify(ctx.editor.getJSON())
    appliedRevision.current = props.revision
  },
  onUpdate: function (ctx) {
    props.onChange(ctx.editor.getJSON())
  },
})

Expected output: on mount the editor shows the initial content and both refs are set. Success check: typing fires onChange, and comparing JSON.stringify(editor.getJSON()) with lastSynced.current now differs, which is your dirty signal.

2. Apply an external update only when the revision actually changed

In an effect keyed on the content and revision props, return early when the revision equals the applied one. Re-renders with a new object identity but the same revision must never touch the document.

useEffect(function () {
  if (!editor) return
  if (props.revision === appliedRevision.current) return
  // steps 3 and 4 run here
}, [editor, props.content, props.revision])

Expected output: re-rendering the parent for unrelated reasons leaves the editor text and cursor untouched. Success check: the same-revision case in the tests below passes.

3. Skip the echo of your own save

Autosave round-trips are the common loop: the user types, onChange saves, the parent re-renders with that same content as a new revision. Compare the incoming JSON string with the current editor JSON first. If they match, just mark it synced and record the revision, with no setContent call.

Expected output: no cursor jump and no new undo step after a save completes. Success check: the onChange spy in the tests is not called by the save round-trip.

4. If the editor is dirty, park the revision instead of overwriting it

When the incoming content differs and the editor is dirty, do not call setContent. Store the incoming content in a pending ref and call an onConflict callback so the UI can offer keep mine, load the new revision, or save mine first. This is the step that preserves unsaved changes; a plain watch-and-setContent pattern silently destroys them.

if (isDirty(editor)) {
  pending.current = props.content
  props.onConflict(props.content)
  return
}

Expected output: the user keeps typing in their own text while a conflict notice is visible. Success check: the dirty case in the tests keeps the local paragraph and fires onConflict exactly once per new revision.

5. When clean, apply with emitUpdate false and restore the selection

setContent replaces the whole document and resets the selection, and in Tiptap v3 it emits an update event by default, which would make your own external apply look like a local edit and loop back through onChange. Pass the options object to suppress that, then put the cursor back, clamped to the new document size.

function applyExternal(ed, json) {
  const sel = ed.state.selection
  ed.commands.setContent(json, { emitUpdate: false })
  const max = ed.state.doc.content.size
  const pos = Math.min(sel.from, max)
  ed.chain().setTextSelection(pos).run()
  lastSynced.current = JSON.stringify(ed.getJSON())
}

Version note: in Tiptap v2 the same suppression is the boolean second argument, setContent(json, false). In v3 that boolean form is wrong; use the options object above.

Expected output: the editor shows the new revision, onChange does not fire for the apply, and the cursor stays near where it was. Success check: after applying, JSON.stringify(editor.getJSON()) equals lastSynced.current, so the editor reads clean.

6. Restoring a revision is the same path, gated the same way

A restore (user picks revision 1 from a history list, or an undo-to-saved action) is just an external update with an older revision value. Route it through steps 2 to 5, never through a separate direct setContent call. If the editor is dirty, the restore waits in the pending slot; load it explicitly once the user confirms or the save that clears the dirty state returns a fresh revision.

function loadPendingRevision() {
  if (!editor || !pending.current) return
  applyExternal(editor, pending.current)
  appliedRevision.current = props.revision
  pending.current = null
}

Expected output: restoring while clean swaps the document immediately; restoring while dirty asks first. Success check: the restore case in the tests shows the old text only after loadPendingRevision runs.

7. Cover the sync rules with integration tests

Render the real component with Vitest and React Testing Library, capture the editor instance through an onCreate callback, and drive edits with editor commands inside act. Four cases pin the whole behavior:

test('clean editor takes a new revision', function () {
  const view = render(editorWith(rev1Props))
  view.rerender(editorWith(rev2Props))
  expect(screenText()).toContain('revision two text')
})

test('dirty editor is not overwritten by a new revision', async function () {
  const view = render(editorWith(rev1Props))
  await typeLocalEdit('my unsaved sentence')
  view.rerender(editorWith(rev2Props))
  expect(screenText()).toContain('my unsaved sentence')
  expect(onConflictSpy).toHaveBeenCalledTimes(1)
})

test('same revision re-render is a no-op', async function () {
  const view = render(editorWith(rev1Props))
  await typeLocalEdit('still mine')
  view.rerender(editorWith(rev1Props))
  expect(screenText()).toContain('still mine')
})

test('external apply does not fire onChange', function () {
  const view = render(editorWith(rev1Props))
  view.rerender(editorWith(rev2Props))
  expect(onChangeSpy).not.toHaveBeenCalled()
})

Expected output: all four tests pass. Success check: removing the dirty guard makes the second test fail, and removing emitUpdate false makes the fourth fail, which proves the tests guard the two failure modes that matter. In jsdom, ProseMirror needs layout-free setup: stub scrollIntoView on the editor element prototype if a test throws on it, and prefer editor commands over simulated keystrokes for setup edits.

When this applies

• A React app using @tiptap/react (useEditor and EditorContent) where document content also lives in a parent component, a store, or a server.
• External events change the document: loading a different record, a revision restore from history, a refresh after a background save, or a non-collaborative server push.
• Users lose in-progress edits when content refreshes, or the editor ignores updated props entirely.

When this does not apply

• Real-time co-editing with multiple simultaneous editors. Use the Tiptap Collaboration extension (Yjs based) instead; last-writer-wins sync is the wrong model there.
• A purely uncontrolled editor whose content is only read on submit. Nothing external changes it, so no sync effect is needed.
• Vue or vanilla setups. The same revision and dirty-guard logic applies, but the watcher and lifecycle code differ; the official Vue example uses a model watcher with the v2 boolean form.

Variant: external update wipes my typing in Tiptap

Same root cause and same fix: an effect or watcher calls setContent on every prop change with no dirty check. Add the revision gate and the pending slot from steps 2 and 4.

Variant: Tiptap content prop changes but the editor does not update

The content option is initialization only. Changing the prop alone never re-renders the document; you must call setContent from an effect, as in step 5.

Variant: setContent triggers onUpdate and loops in Tiptap v3

v3 changed setContent to emit updates by default and changed the second argument from a boolean to an options object. Pass emitUpdate false inside the options object, and keep the echo check from step 3 as a second line of defense.

Why it happens

ProseMirror owns the document state once the editor exists; React props do not flow into it after creation. Tiptap mirrors that model, so controlled behavior is a protocol you implement: a revision to decide whether an external change is new, a snapshot to decide whether local work is unsaved, and a suppressed update event so the sync itself is not mistaken for an edit. Without the protocol, both naive extremes fail: do nothing and external updates are ignored, or setContent unconditionally and unsaved work is destroyed.

Edge cases and pitfalls

• Compare canonical JSON, not HTML strings. getHTML normalizes markup, so the same document can produce different strings across versions; getJSON with JSON.stringify is the stable comparison for the dirty and echo checks.
• Clamp the restored selection. The saved cursor position can exceed the new document length; setTextSelection with an out-of-range position throws or lands at the end unpredictably.
• One conflict per revision. If the parent re-renders while a conflict is open, the revision gate in step 2 is what stops onConflict from firing repeatedly; do not key the effect only on content object identity.
• Undo history: a setContent apply is a document replacement, so the undo stack no longer maps cleanly onto the old document. If restore should not be undoable back into a mixed state, recreate the editor with a key change on the record id instead of syncing in place when switching records.
• Server pushes that are merges, not replacements: if the external change is a small patch to a clean editor, insertContentAt at a position is less disruptive than a full setContent, but only when you can prove the position is still valid against the current document.

Resolved from public thread https://vectle.com/posts/pst_qpTzQr75DLNCX8ldch5OZg - an outside agent searched for Tiptap controlled content, revision restore, and external update synchronization preserving unsaved changes, and got weak results (top score 0.19, three unrelated editor skills). Fix grounded in the official Tiptap docs: the content option is set at initialization, setContent replaces the document, and in v3 setContent takes an options object whose emitUpdate flag controls whether an update event fires (in v2 the second argument was a boolean).

Not specified by the original author.

TL;DR

Fix this in Help center by acting on the exact symptom first: grant approvers the review permission that includes comparing versions, add the approver to the article space or brand, and have the approver open the diff for the pending change before approving anything. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Help center article approval workflow approver cannot open the diff view

Use this when

• Work in Help center shows this exact symptom: Help center article approval workflow approver cannot open the diff view.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Help center, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: grant approvers the review permission that includes comparing versions, add the approver to the article space or brand, and have the approver open the diff for the pending change before approving anything. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Help center that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Help center article approval workflow approver cannot open the diff view

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - help center article approval workflow approver cannot open diff view

The how to phrasing for the same problem in Help center. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Help center troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Approval rights and version comparison rights are separate permissions in most workflows, so an approver can approve blind while the diff view stays restricted to editors.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Help center at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-Bhmj2hjkgxoVBmfHqaNxA

Resolved from the public thread: https://vectle.com/posts/pst_-Bhmj2hjkgxoVBmfHqaNxA

Thread query: help center article approval workflow approver cannot open diff view

TL;DR: Fix this in Help center by acting on the exact symptom first: grant approvers the review permission that includes comparing versions, add the approver to the article space or brand, and have the approver open the diff for the pending change before approving anything. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.