569932 - contenteditable=true on inline elements: pasting messes up DOM

Status: NEW

(Core :: DOM: Editor, defect)

Description

[Veit Lehmann]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.0 (KHTML, like Gecko) Chrome/6.0.408.1 Safari/534.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

Given following example code:

<span contenteditable="true">foo bar baz</span>

Pasting any RichText (even copied from that element) in it creates a new empty span and does not paste it.

<span style="display:block"> shows the same problem.

<div style="display:inline"> does not show that problem.

With contenteditable="true" on <b> or <i> elements, the problem is also reproducable.

So it depends on the element's nature, not on its styling.

Reproducible: Always

Steps to Reproduce:
1. Create an empty HTML file with the code: <span contenteditable="true">foo bar baz</span>
2. Copy the word "bar" and try to paste it
3. Copy any RichText (e.g. from some website) and try to paste it
Actual Results:  
New empty spans with "contenteditale=true" are created at the cursor position. No content is pasted.

Expected Results:  
Content should be pasted as RichText. Pasted elements should not have any "contenteditable" attribute.

This feature is used by CMS providing true insite editing and should therefore be fixed.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Could you please attach a minimal testcase.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Are you pasting content containing block-level (in the HTML sense) elements?

Comment 3

[Veit Lehmann]

Thanks for your quick response, guys. I have attached a test case:
http://veitlehmann.de/mozilla-contenteditable.html

I am pasting inline elements. Block level elements would break that by nature and could possibly be filtered out on paste. Pasting inline elements should work.

Comment 4

[(no longer active)]

Confirming and taking.  This looks *really* bad.  :(

Comment 5

[(no longer active)]

It's interesting that pasting plain text seems to be working correctly.

Comment 6

[Loic]

I think it's fixed by bug 858918.
Veit, could you download Nightly and confirm your testcase works in all cases?
https://nightly.mozilla.org/

Comment 7

[Veit Lehmann]

Hi Loic,

it's almost fixed in the recent Nightly. Test case 2 on http://veitlehmann.de/mozilla-contenteditable.html (span with dispay: block) still behaves unexpectedly. Copy/pasting there creates new <span style="display: block"> elements inside.

Strangely there's no problem in test case 4: del element with display: block. Pasted plain text behaves nicely there.

All other test cases work as expected, which is really great to see! Thanks a lot for your effort!

I tested in Nightly 36.0a1 (2014-10-23) on Mac OS X 10.10.

Comment 8

[Loic]

(In reply to Veit Lehmann from comment #7)
> Hi Loic,
> 
> it's almost fixed in the recent Nightly. Test case 2 on
> http://veitlehmann.de/mozilla-contenteditable.html (span with dispay: block)
> still behaves unexpectedly. Copy/pasting there creates new <span
> style="display: block"> elements inside.

But that's the case for case 1 too, isn't it?
Ex:
<span contenteditable="true">Select some text, then copy <span contenteditable="true">some text</span>and paste it here</span>

Comment 9

[Veit Lehmann]

You're right! I didn't recognize it since it doesn't break visually. But yes, the problem is there, too. Pasted text should not be wrapped in new spans.

Comment 10

[Veit Lehmann]

I did another test:
1) Copy text from test case 1 and paste into test case 3: unwanted spans are appearing there.
2) Copy text from test case 3 and paste into test case 1: only plain text is pasted as expected.

So it seems that the problem is with copying text from a span.

Comment 11

[Loic]

As this bug is pretty old and Nightly has partially fixed your testcase after 4 years, could you clone your bug to file a new one explaining the new issue, please?