1851242 - user-select: none eats a line break on copy of surrounding <p>

Status: RESOLVED DUPLICATE of bug 1832443

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Eliot Lear]

Attachment: Actual output with run on paragraphs

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

1. Visit https://www.ietf.org/archive/id/draft-thomson-rswg-syntax-change-00.html
2. Go to section 2 and copy the text from the first 3 paragraphs.
3. Paste the text into some other buffer.

Actual results:

All the paragraphs run together, <p> blocks not withstanding.

Expected results:

There should have been line breaks between the paragraphs, as displayed.

I'll follow up with more detail after opening.

Comment 1

[Eliot Lear]

The document in question is HTML with self-contained CSS. Each paragraph ends with a little ¶ character, which is a link to the bottom of the next paragraph. The HTML is as follows:

<p id="section-2-2">The RSWG publishes an RFC on the Editorial stream that describes the format
change. An updated XML format is used for the publication of new RFCs. Some
time might be necessary to implement those changes in tools and active
documents.<a href="#section-2-2" class="pilcrow">¶</a></p>

Down in a.pilcrow, user-select: none appears.

The intent is to suppress the ¶ on copy so that the character doesn't appear in inappropriate places. Disabling user-select adds the paragraph breaks back on copy. And indeed, when I cut and paste to Thunderbird, I don't even get the character. I get the same behavior in Chrome and Safari. Perhaps I am misunderstanding the situation?

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Eliot Lear]

Correction to my previous comment 1: I now only see the problem in FF.

Comment 4

[Eliot Lear]

indeed bug 1832443 is reported by the author of the work I cite, and is a simpler example. Maybe dup this one?

Comment 5

[Sean Feng [:sefeng211]]

Thanks for the bug report!