Skip to content

fix(editor): paste markdown tables that contain blank cells - #1484

Merged
feruzm merged 2 commits into
developfrom
bugfix/paste-empty-table-cell
Aug 13, 2026
Merged

fix(editor): paste markdown tables that contain blank cells#1484
feruzm merged 2 commits into
developfrom
bugfix/paste-empty-table-cell

Conversation

@feruzm

@feruzm feruzm commented Aug 13, 2026

Copy link
Copy Markdown
Member

Pasting a markdown table that contains any blank cell inserts nothing at all. The table does not appear, and no error reaches the user.

Reported from a real case: a 29-row table with blank cells in one column simply would not paste into the publish editor.

Cause

A blank cell renders as <td></td>. The ProseMirror tableCell schema requires at least one block child, so it rejects the document:

RangeError: Invalid content for node tableCell: <>

insertContent throws, and the throw aborts the entire paste. That is why one blank cell anywhere loses the whole table rather than leaving a gap in it.

Minimal reproduction, all through the real clipboard path:

markdown result on develop
| A | B | / | 1 | 2 | pastes, 2 rows
| A | B | / | 1 | | throws, nothing inserted

Fix

parse-all-extensions-to-doc already solves exactly this for blockquotes, which fail the same schema check for the same reason:

// Ensure empty blockquotes have at least one paragraph to satisfy ProseMirror schema.

Table cells needed the same treatment. An empty <td> or <th> gets one empty paragraph, so the cell renders blank and the document validates.

Verification against the reported case

A real 29-row table containing 16 blank cells, pasted through simpleMarkdownToHTML then parseAllExtensionsToDoc then insertContent:

              develop        with this change
paste         THREW          SUCCEEDED
rows          0              29
blank cells   -              16 (rendered as empty cells)
stored body   -              a table, all content intact

Testing

  • New empty-table-cell-paste.spec.ts: blank cell leading, trailing, in the middle, a fully blank row, a blank header cell, several blank rows, the unaffected all-filled case, and a direct assertion that a blank cell becomes <td><p></p></td> rather than being dropped.
  • Full suite green: 2687 tests / 279 files. Typecheck clean, no new lint.

Note

This supersedes #1482, which was closed. That PR diagnosed the same report as a Turndown serialization problem, which turned out not to exist: the existing custom table rule already preserves tables through the editor losslessly. The actual failure is upstream of serialization, at paste time, and this is a much smaller change.

Pasting a markdown table with any blank cell inserted nothing at all. The
table did not appear, and no error surfaced to the user.

A blank cell renders as <td></td>. The ProseMirror tableCell schema
requires at least one block child, so it rejects the document with
"Invalid content for node tableCell: <>" and insertContent throws. The
throw aborts the whole paste, which is why a single blank cell anywhere
loses the entire table rather than leaving a gap in it.

parse-all-extensions-to-doc already does exactly this for blockquotes,
which fail the same schema check for the same reason. Table cells needed
the same treatment: give an empty cell one empty paragraph.

Verified against a real 29-row table with 16 blank cells. On develop the
paste throws and nothing is inserted; with this change all 29 rows land,
the blank cells render as empty cells, and the surrounding content is
unchanged. Regression specs cover blank cells leading, trailing, in the
middle, a fully blank row, a blank header cell and several blank rows,
plus the unaffected all-filled case.
@coderabbitai

coderabbitai Bot commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

@feruzm, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 57 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: d0c34f5d-cf0d-4103-8e9e-f037bdc7c0af

📥 Commits

Reviewing files that changed from the base of the PR and between f08fee4 and 73525ff.

📒 Files selected for processing (2)
  • apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts
  • apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented Aug 13, 2026

Copy link
Copy Markdown

PR Summary by Qodo

Fix paste for markdown tables with blank cells in the TipTap editor

🐞 Bug fix 🧪 Tests 🕐 20-40 Minutes

Grey Divider

AI Description

• Prevent paste failures when markdown tables contain empty header/body cells.
• Normalize empty / to contain an empty paragraph to satisfy ProseMirror.
• Add regression specs covering multiple blank-cell/table layouts and non-blank tables.
Diagram

graph TD
  A[/"Clipboard markdown"/] --> B["simpleMarkdownToHTML"] --> C["parseAllExtensionsToDoc"] --> D["TipTap insertContent"] --> E{"ProseMirror schema valid?"} --> F["Table inserted"]
  C --> G["Fill empty cells with <p></p>"]

  subgraph Legend
    direction LR
    _in[/"Input"/] ~~~ _fn["Function"] ~~~ _dec{"Decision"}
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Relax the tableCell schema to allow empty content
  • ➕ Avoids DOM mutation; schema directly permits empty cells
  • ➖ Broader behavioral change; may impact other table operations/commands
  • ➖ Harder to constrain to paste-only behavior
2. Catch insertContent paste errors and retry with a fallback transform
  • ➕ Prevents total paste loss even if other schema issues exist
  • ➖ May mask real parsing issues; harder to reason about what was inserted
  • ➖ More complex control flow; risks partial/inconsistent insertion
3. Fix at the markdown->HTML renderer (emit inside empty cells)
  • ➕ Keeps parsed HTML closer to ProseMirror expectations earlier in the pipeline
  • ➖ Couples renderer output to ProseMirror/table requirements
  • ➖ May not cover non-markdown HTML paste paths that still produce

Recommendation: The chosen approach (normalize in parseAllExtensionsToDoc) is the best tradeoff: it is paste-focused, mirrors the existing empty-blockquote handling, and fixes both markdown-derived and raw-HTML empty cells without widening the ProseMirror schema surface area.

Files changed (2) +95 / -0

Bug fix (1) +12 / -0
parse-all-extensions-to-doc.tsNormalize empty table cells to satisfy ProseMirror schema +12/-0

Normalize empty table cells to satisfy ProseMirror schema

• Adds a post-processing pass over parsed HTML to detect empty <td>/<th> elements. When a cell has no child elements and no non-whitespace text, it appends an empty <p> so tableCell/tableHeader nodes validate and paste no longer aborts.

apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts

Tests (1) +83 / -0
empty-table-cell-paste.spec.tsAdd regression specs for pasting tables with blank cells +83/-0

Add regression specs for pasting tables with blank cells

• Introduces Vitest coverage that exercises the real clipboard-like path (markdown -> HTML -> parseAllExtensionsToDoc -> insertContent) across multiple blank-cell positions and scenarios. Verifies tables still paste when fully filled and asserts empty cells become <td><p></p></td>.

apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented Aug 13, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

Grey Divider


Remediation recommended

1. rowCount lacks return annotation ✓ Resolved 📘 Rule violation ⚙ Maintainability
Description
The new TypeScript test introduces rowCount without an explicit return type, contrary to the
requirement that newly added functions have explicit annotations. The it.each callback also leaves
both parameters unannotated, risking implicit any if contextual typing is unavailable.
Code

apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[34]

+const rowCount = (html: string) => (html.match(/<tr/g) || []).length;
Relevance

●●● Strong

Repo often accepts tightening TypeScript typings in new specs to avoid implicit/any types.

PR-#865
PR-#919

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The changed test defines rowCount as an arrow function with only a parameter annotation and
defines the it.each callback with unannotated _label and markdown parameters. These are newly
added functional code paths covered by the explicit TypeScript annotation rule.

Rule 2668119: Disallow implicit and any types in new TypeScript code
apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[34-34]
apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[56-56]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new test file contains a helper with an inferred return type and a parameterized-test callback with unannotated parameters.
## Issue Context
The TypeScript compliance rule requires explicit annotations for new function parameters and return types and disallows implicit `any`.
## Fix Focus Areas
- apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[34-34]
- apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[56-56]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. rowCount lacks return annotation ✓ Resolved 📘 Rule violation ⚙ Maintainability
Description
The new TypeScript test introduces rowCount without an explicit return type, contrary to the
requirement that newly added functions have explicit annotations. The it.each callback also leaves
both parameters unannotated, risking implicit any if contextual typing is unavailable.
Code

apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[34]

+const rowCount = (html: string) => (html.match(/<tr/g) || []).length;
Relevance

●●● Strong

Repo often accepts tightening TypeScript typings in new specs to avoid implicit/any types.

PR-#865
PR-#919

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The changed test defines rowCount as an arrow function with only a parameter annotation and
defines the it.each callback with unannotated _label and markdown parameters. These are newly
added functional code paths covered by the explicit TypeScript annotation rule.

Rule 2668119: Disallow implicit and any types in new TypeScript code
apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[34-34]
apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[56-56]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new test file contains a helper with an inferred return type and a parameterized-test callback with unannotated parameters.
## Issue Context
The TypeScript compliance rule requires explicit annotations for new function parameters and return types and disallows implicit `any`.
## Fix Focus Areas
- apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[34-34]
- apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[56-56]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

3. Inline-only cells remain invalid 🐞 Bug ≡ Correctness
Description
The normalization only fills cells with no element children, so inline-only content such as ``
bypasses the guard even though it may lack the block child required by the ProseMirror tableCell
schema. Externally generated HTML (not just the plain markdown blank-cell case) can therefore remain
invalid or be normalized inconsistently during insertion.
Code

apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts[R183-186]

+  (Array.from(tree.querySelectorAll("td, th")) as HTMLElement[]).forEach((cell) => {
+    if (!cell.firstElementChild && !cell.textContent?.trim()) {
+      cell.appendChild(document.createElement("p"));
+    }
Relevance

● Weak

Similar inline-child schema-hardening in same file was previously rejected (blockquote
firstElementChild widening).

PR-#1150

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The new condition !cell.firstElementChild && !cell.textContent?.trim() only appends a paragraph
when the cell has zero element children. A cell containing an empty inline element (e.g. ``) has an
element child, so it is skipped by this guard even though it still lacks the block content the
ProseMirror tableCell schema requires. This normalization runs immediately before insertContent in
the same paste path this PR is fixing, so a cell shaped this way could reproduce the same class of
failure the PR intends to eliminate.

apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts[183-186]
apps/web/src/features/tiptap-editor/plugins/clipboard/clipboard-plugin-text-strategy.ts[20-24]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new table-cell normalization in `parseAllExtensionsToDoc` only inserts a paragraph when a cell has no element children at all (`!cell.firstElementChild`). Cells that contain an inline-only child (e.g. an empty `<strong>`, `<em>`, or `<span>`) bypass this guard even though they may still lack the block-level content required by the ProseMirror `tableCell` schema, potentially reproducing the same 'Invalid content for node tableCell' failure this PR is meant to fix.
## Issue Context
This normalization runs on HTML right before `editor.chain().insertContent(...)` in the paste path (see `clipboard-plugin-text-strategy.ts`), so any cell shape it fails to repair can still throw and abort the whole paste, same as the original bug.
## Fix Focus Areas
- apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts[183-187]
- apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[78-82]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


4. Inline-only cells remain invalid 🐞 Bug ≡ Correctness
Description
The normalization only fills cells with no element children, so inline-only content such as ``
bypasses the guard even though it may lack the block child required by the ProseMirror tableCell
schema. Externally generated HTML (not just the plain markdown blank-cell case) can therefore remain
invalid or be normalized inconsistently during insertion.
Code

apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts[R183-186]

+  (Array.from(tree.querySelectorAll("td, th")) as HTMLElement[]).forEach((cell) => {
+    if (!cell.firstElementChild && !cell.textContent?.trim()) {
+      cell.appendChild(document.createElement("p"));
+    }
Relevance

● Weak

Similar inline-child schema-hardening in same file was previously rejected (blockquote
firstElementChild widening).

PR-#1150

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The new condition !cell.firstElementChild && !cell.textContent?.trim() only appends a paragraph
when the cell has zero element children. A cell containing an empty inline element (e.g. ``) has an
element child, so it is skipped by this guard even though it still lacks the block content the
ProseMirror tableCell schema requires. This normalization runs immediately before insertContent in
the same paste path this PR is fixing, so a cell shaped this way could reproduce the same class of
failure the PR intends to eliminate.

apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts[183-186]
apps/web/src/features/tiptap-editor/plugins/clipboard/clipboard-plugin-text-strategy.ts[20-24]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new table-cell normalization in `parseAllExtensionsToDoc` only inserts a paragraph when a cell has no element children at all (`!cell.firstElementChild`). Cells that contain an inline-only child (e.g. an empty `<strong>`, `<em>`, or `<span>`) bypass this guard even though they may still lack the block-level content required by the ProseMirror `tableCell` schema, potentially reproducing the same 'Invalid content for node tableCell' failure this PR is meant to fix.
## Issue Context
This normalization runs on HTML right before `editor.chain().insertContent(...)` in the paste path (see `clipboard-plugin-text-strategy.ts`), so any cell shape it fails to repair can still throw and abort the whole paste, same as the original bug.
## Fix Focus Areas
- apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts[183-187]
- apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[78-82]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Tip of the day
💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

@qodo-code-review

qodo-code-review Bot commented Aug 13, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

Grey Divider


Remediation recommended

1. rowCount lacks return annotation ✓ Resolved 📘 Rule violation ⚙ Maintainability
Description
The new TypeScript test introduces rowCount without an explicit return type, contrary to the
requirement that newly added functions have explicit annotations. The it.each callback also leaves
both parameters unannotated, risking implicit any if contextual typing is unavailable.
Code

apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[34]

+const rowCount = (html: string) => (html.match(/<tr/g) || []).length;
Relevance

●●● Strong

Repo often accepts tightening TypeScript typings in new specs to avoid implicit/any types.

PR-#865
PR-#919

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The changed test defines rowCount as an arrow function with only a parameter annotation and
defines the it.each callback with unannotated _label and markdown parameters. These are newly
added functional code paths covered by the explicit TypeScript annotation rule.

Rule 2668119: Disallow implicit and any types in new TypeScript code
apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[34-34]
apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[56-56]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new test file contains a helper with an inferred return type and a parameterized-test callback with unannotated parameters.

## Issue Context
The TypeScript compliance rule requires explicit annotations for new function parameters and return types and disallows implicit `any`.

## Fix Focus Areas
- apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[34-34]
- apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[56-56]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

2. Inline-only cells remain invalid 🐞 Bug ≡ Correctness
Description
The normalization only fills cells with no element children, so inline-only content such as
<td><strong></strong></td> bypasses the guard even though it may lack the block child required by
the ProseMirror tableCell schema. Externally generated HTML (not just the plain markdown
blank-cell case) can therefore remain invalid or be normalized inconsistently during insertion.
Code

apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts[R183-186]

+  (Array.from(tree.querySelectorAll("td, th")) as HTMLElement[]).forEach((cell) => {
+    if (!cell.firstElementChild && !cell.textContent?.trim()) {
+      cell.appendChild(document.createElement("p"));
+    }
Relevance

● Weak

Similar inline-child schema-hardening in same file was previously rejected (blockquote
firstElementChild widening).

PR-#1150

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The new condition !cell.firstElementChild && !cell.textContent?.trim() only appends a paragraph
when the cell has zero element children. A cell containing an empty inline element (e.g.
<td><strong></strong></td>) has an element child, so it is skipped by this guard even though it
still lacks the block content the ProseMirror tableCell schema requires. This normalization runs
immediately before insertContent in the same paste path this PR is fixing, so a cell shaped this
way could reproduce the same class of failure the PR intends to eliminate.

apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts[183-186]
apps/web/src/features/tiptap-editor/plugins/clipboard/clipboard-plugin-text-strategy.ts[20-24]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new table-cell normalization in `parseAllExtensionsToDoc` only inserts a paragraph when a cell has no element children at all (`!cell.firstElementChild`). Cells that contain an inline-only child (e.g. an empty `<strong>`, `<em>`, or `<span>`) bypass this guard even though they may still lack the block-level content required by the ProseMirror `tableCell` schema, potentially reproducing the same 'Invalid content for node tableCell' failure this PR is meant to fix.

## Issue Context
This normalization runs on HTML right before `editor.chain().insertContent(...)` in the paste path (see `clipboard-plugin-text-strategy.ts`), so any cell shape it fails to repair can still throw and abort the whole paste, same as the original bug.

## Fix Focus Areas
- apps/web/src/features/tiptap-editor/functions/parse-all-extensions-to-doc.ts[183-187]
- apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts[78-82]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Context
✅ Compliance rules (platform): 82 rules
✅ Skills: 6 invoked
  add-feature
  add-query
  add-sdk-mutation
  add-test
  code-review
  debug
Review mode: 🚀 Fast: This is a localized, low-risk parser fix with focused regression tests and no security, API, schema-migration, or cross-cutting impact.

Grey Divider

Tip of the day
💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment thread apps/web/src/specs/features/tiptap-editor/empty-table-cell-paste.spec.ts Outdated
Review follow-up. The blank-cell guard also matches cells holding only
whitespace or &nbsp;, which the browser already renders as one
paragraph. Appending left that invisible text in place alongside the new
empty paragraph, so such a cell rendered as two paragraphs and roughly
doubled in height. Only a genuinely empty cell was correct.

Measured before this commit: a cell containing just &nbsp; produced
<td>&nbsp;<p></p></td> and two paragraphs in the editor, against one on
develop. Same for a spaces-only cell.

Since the guard has already established the content is invisible, clear
it and insert a single empty paragraph. All three blank shapes now
normalise to <td><p></p></td> and render as one paragraph.

Adds coverage for &nbsp;, plain spaces, a tab and mixed invisible
content, an editor-level assertion that such a cell renders as exactly
one paragraph, and a case confirming cells with real content are
untouched. Also annotates the spec helper and the it.each parameters per
review.
@feruzm

feruzm commented Aug 13, 2026

Copy link
Copy Markdown
Member Author

Confirmed and fixed in 73525ff. Reproduced exactly as described.

String.prototype.trim() strips U+00A0, so the guard classified <td>&nbsp;</td> as blank while the browser was already rendering it as one paragraph. Appending left both:

cell content develop before this commit now
truly empty throws on insert <td><p></p></td>, 1 paragraph 1 paragraph
&nbsp; only 1 paragraph <td>&nbsp;<p></p></td>, 2 paragraphs 1 paragraph
spaces only 1 paragraph 2 paragraphs 1 paragraph

Clearing the cell before inserting the paragraph, as suggested, since the guard has already established the content is invisible. Added coverage for &nbsp;, plain spaces, a tab and mixed invisible content, an editor-level assertion that such a cell renders as exactly one paragraph, and a case confirming cells with real content are left alone.

One related note, deliberately not changed here. The blockquote guard directly above uses the same predicate and the same append, so <blockquote>&nbsp;</blockquote> has the same doubling on develop today. It is pre-existing rather than introduced by this PR, and changing blockquote rendering deserves its own verification, so I have left it. Happy to follow up separately if wanted.

@feruzm
feruzm merged commit 89af621 into develop Aug 13, 2026
8 checks passed
@feruzm
feruzm deleted the bugfix/paste-empty-table-cell branch August 13, 2026 20:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant