1489943 - Selection that begins/ends half-way through an element doesn't copy-paste to contenteditable correctly

Status: NEW

(Core :: DOM: Editor, defect, P3)

Description

[Stephan Sokolow]

Attachment: clipboard_bug_reproduction.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180906162647

Steps to reproduce:

1. Select some text from the middle of one <p> element, through several more, ending in the middle of another <p> element.
2. Copy it to the clipboard.
3. Paste it into a contenteditable=true field (anything which accepts HTML pastes would probably work)
4. Open up the DOM inspector and look at what arrived


Actual results:

The the first and last <p> elements are gone and their contents are bumped up in the hierarchy.

One thing that makes this pretty clear that this is NOT consistent. If the first element is twice as deep as the others (eg. <p><strong>[start of selection</strong></p>) then the final <p></p> will be preserved while, if it's not, then the final <p></p> will be lost.

It also *will* synthesize the opening <strong> in that case, while still discarding the opening <p>.

I've confirmed this on a fresh Nightly install with a brand new profile but it's actually something I've been meaning to report for many years after encountering it in the input field for my home-grown quote-saving tool... I just kept forgetting about it.


Expected results:

No tags which apply to the copied range should be discarded 

This is something Chrome does correctly. (ie. What Chrome does is equivalent to cloning the smallest DOM subtree that contains all nodes touched by the selection, then pruning away any nodes or ranges of text which lie entirely outside the selection.)

I've attached a minimal example with built-in instructions to demonstrate the problem.

Given the commonalities in their reduced forms, I suspect that fixing this will also fix bug 1327461.

Comment 1

[Stephan Sokolow]

In hindsight, I should have included a clear "Step 2.5: Clear the destination field" instruction rather than assuming it would be obvious.

Also, on rare occasions, steps 3 and 4 in the reproduction don't produce the bug even with that instruction. If it seems to work properly, 

I'm not entirely sure whether it's my fault for leaving some hidden markup in the destination box due to a rushed, sloppy execution of the instructions or something deeper in Firefox, but clearing the box and trying again has always produced the intended behaviour.

Comment 2

[Stefan [:StefanG_QA]]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0 (20180913100107)

I have tested this report on Windows 10 and Ubuntu 18.04 using the latest Nightly, Beta and Fx release builds. I was able to reproduce the mentioned behavior using the attached test case. After copying from before "quux" to after "Yorp", I can observe that some of the <p> elements are lost during the paste operation.

Comment 3

[Mirko Brodesser (:mbrodesser-Igalia), offline until April 25h]

This is possibly a duplicate of bug 1648765. I guess it happens because
"text/_moz_htmlinfo" flavor corresponds to 1,1. Which would mean the bug happens during the serialization, presumably in nsDocumentEncoder.