Pasting multi-line content (e.g. plain-text-style emails) creates excessive spacing between lines, even with explicit margin:0

Summary

When pasting HTML where each visual "line" of the source is its own block-level element (<div> or <p>) — which is how several email clients format a plain, non-nested message (Outlook desktop, Outlook Web/"New Outlook", Gmail, Apple Mail) — Trix converts every one of those blocks into its own separate Trix paragraph. Trix's own default margin between paragraphs then applies to each one, producing noticeably larger gaps between lines than the source had, even when the source explicitly sets margin: 0 on those elements.

Reproduction

<p style="margin:0">Line one</p>
<p style="margin:0">Line two</p>
<p style="margin:0">Line three</p>

Paste this (or call editor.insertHTML(...) with it directly). Each line becomes its own block in Trix's document model, rendered with Trix's default block margin — the source's margin:0 has no effect.

Investigation notes

• Reproduced with a real-world sample: a multi-paragraph email copied from Outlook Web ("New Outlook"), several paragraphs carrying an explicit style="margin: 0px". Same result.
• Not a recent regression. Tested this exact input against Trix 2.1.8 (before DOMPurify was added for paste sanitization in 2.1.9, per the CVE-2024-53847 fix) and current 2.1.19, side by side, calling editor.insertHTML() directly with no other app code involved — output was byte-for-byte identical on both. So this isn't a DOMPurify sanitization side effect or tied to any particular version; every version checked behaves the same way.
• getBlockElementMargin/window.getComputedStyle machinery in the HTML parser (still present in 2.1.19) looks like it's meant to read a pasted element's own margin, but empirically doesn't prevent the splitting/spacing described above for a plain multi-<p> paste.

Environment

• Trix 2.1.8 and 2.1.19 tested directly; current app runs 2.1.19
• Chrome (via Puppeteer / Chrome for Testing) — haven't checked Firefox/Safari

Workaround

We worked around this in our app by detecting "flat" multi-line pastes (a sequence of sibling <div>/<p> blocks each containing only inline content) and rewriting them to a single Trix block with <br>-joined lines before Trix processes the paste — preserving bold/italic/underline/links, dropping block-level spacing. It's fairly app-specific (assumes any flat multi-block paste should collapse to plain line breaks), so not proposing it as a direct fix, just context on what worked for us.