basecamp / basecamp/trix

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

Open
#1,347 0 comments 0 reactions 0 assignees View on GitHub
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 (`

` or `

`) — 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

/

blocks become Trix paragraphs and define tests for the intended spacing behavior; the issue does not specify an accepted direct-fix behavior, so completion criteria need maintainer agreement.

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.