406488 - Copy highlighted text to clipboard ignores non-inlined CSS styling when pasting as rich text (to HTML editors, MS Word, Excel, Outlook etc.)

Status: NEW

(Core :: DOM: Serializers, defect)

Description

[Duncan Loveday]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112705 Minefield/3.0b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112705 Minefield/3.0b2pre

On a windows platform, highlighting a portion of an HTML document and copying it to the clipboard preserves explicit HTML styling and inline CSS styling but ignores references to internal and external stylesheets. IE7 preserves both inline and out of line styles.

Reproducible: Always

Steps to Reproduce:
1. Open the attached HTML test case.
2. Right click->Select all then ctrl-C to copy to clipboard.
3. Paste the result into Microsoft Word
Actual Results:  
HTML and inline styling (the first two rows of the table) are preserved. Internal and External stylesheet references (the last two rows of the table) are lost.

Expected Results:  
Ideally all styling would be preserved.

FWIW, Opera doesn't preserve styling at all.

Comment 1

[Duncan Loveday]

Attachment: External Stylesheet

Comment 2

[Duncan Loveday]

Attachment: HTML test case

Comment 3

[Przemyslaw Bialik]

Confirming.
There is similar Bug 116083 but it's focused on <pre> tag so I'm not duplicating to it.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007120505 Minefield/3.0b2pre ID:2007120505

Comment 4

[Nickolay_Ponomarev]

This was wontfixed per bug 189320 comment 2, but it may be needs to be reconsidered, as Chrome does this (by inserting the computed style inline in the copied elements).

Comment 5

[Nickolay_Ponomarev]

To test without MS Word you can open this data URL:

data:text/html,<div contenteditable>Text

then focus the div and paste.

Comment 11

[Herouth Maoz]

Firefox 37.0.2 no longer copies even the inline styles. I'm not sure whether this merits opening a new bug or not. Operating system: MacOS X Yosemite. Safari and Chrome copy rich text properly.

Comment 12

[Herouth Maoz]

I wouldn't say it's related to Microsoft or Outlook. The reason I added myself to the bug is that on Mac OS, when I try to copy from Firefox to a native Mac application that supports rich text (not a Microsoft application), the styling is not kept, while copying from Chrome/Safari keeps the styling. And it used to work in Firefox in the past.

Comment 13

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Comment 14

[Thomas Wisniewski [:twisniewski]]

This was also reported on webcompat.com for LinkedIn copy-pasting.

Comment 15

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 16

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 17

[Mike Taylor [:miketaylr]]

Kagami, should this block blink-editor-compat?

Comment 18

[Kagami Rosylight [:saschanaz] (they/them)]

It seems Chrome adds inline style="background-color: blue" but only when pasting across apps. cc'ing Mirko who have recently done some copy-paste work, as I'm not quite familiar with clipboard things.

Comment 19

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

Chrome also adds inline style when copy-pasting within the browser (e.g. to data:text/html,<div contentEditable="true">X</div>). Firefox doesn't.

So this should also block "blink-editor-compat".

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Chrome inlines each element's style a lot. If we do similar things, cannot we apply same style smarter? (I don't have any concrete idea though.)

Comment 21

[Ignat Remizov]

+1 - This bug still looks worth prioritizing.

I took a look at a plausible implementation direction, and I think this could be better framed as a scoped "rich-copy fidelity" project, not a
generic serializer change.

Proposed approach:

1. Keep plain-text clipboard behavior unchanged.
2. In the HTML copy path, clone the selected fragment into an inert fragment/document.
3. Inline a conservative allowlist of computed styles before serializing to text/html.
4. Prioritize the properties that matter most for real-world paste targets like Gmail / Docs / Outlook / Word / Excel: color, background-color, font-*, text-decoration, text-align, vertical-align, white-space, border*, padding*, margin*, and table-related properties.
5. Focus on table structure + cell formatting first, since that seems to be the highest-value compatibility gap.
6. Pref-gate initially and add tests for colored table cells, borders, nested spans, and contenteditable paste cases.

A Gecko-native implementation here seems more realistic than trying to mirror all of Blink’s copy behavior. The existing copy encoder / node-fixup code path looks like the right place to experiment, because this should affect clipboard HTML generation specifically, not general HTML serialization.

If maintainers think this direction is reasonable, I’d support filing a new issue dependency for: "Inline allowlisted computed styles during HTML clipboard copy (pref-gated)" so we can start work on this.

Comment 22

[Emilio Cobos Álvarez [:emilio]]

I think it's worth prototyping something like that... But feels a bit whack-a-mole-ish to me.