Pasting multi-line content (e.g. plain-text-style emails) creates excessive spacing between lines, even with explicit margin:0
- Dominant language
- JavaScript
- Stars
- 20k
- Forks
- 1.1k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 13
Description
## Summary
When pasting HTML where each visual "line" of the source is its own block-level element (`
`) — 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
```html
Line one
Line two
Line three
```
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](https://github.com/advisories/GHSA-6vx4-v2jw-qwqh) 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-`
` 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 `
` blocks each containing only inline content) and rewriting them to a single Trix block with `
`-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.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the HTML with editor.insertHTML(...) and inspect the HTML parser's mentioned getBlockElementMargin/window.getComputedStyle machinery. Compare how sibling
/
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100