WebKit: pasting block elements results in an extra div

[Wiktor Walc]

Confirmed on both Safari and Chrome, on Mac and Windows.

Steps to reproduce

• start with

  <h1>
           Heading1</h1>
  

• copy the first line, press enter and paste it below
• result: heading is surrounded with a div tag.

<h1>
        Heading1</h1>
<p>
        &nbsp;</p>
<div style="font-family: Arial, Verdana, sans-serif; font-size: 12px;
color: rgb(34, 34, 34); background-color: rgb(255, 255, 255); ">
        <h1>
                Heading1</h1>
</div>

The result in Chrome 9.0.597.94 is similar, but note the extra <meta> tag:

<h1>
        Heading1</h1>
<p>
        &nbsp;</p>
<meta charset="utf-8" />
<div style="font-family: Arial, Verdana, sans-serif; font-size: 12px;
color: rgb(34, 34, 34); background-color: rgb(255, 255, 255); ">
        <h1>
                Heading1</h1>
</div>

[Wiktor Walc]

Looks like a similar issue to #6194.

[Garry Yao]

Not a heading specific issue, a reduced TC:

1. Load any sample page, select all doc content and copy to clipboard.
2. Open new paragraph, paste into it;
   • Actual Result: an extra div's wrapping around copied content;

[Garry Yao]

It's a pity that even the comments inline had aware of the bug but not the codes ;/

[Wiktor Walc]

Note that if you change the background color in contents.css into any other than white (e.g #eee), Safari will use the same background-color in this extra div element:

<div style="font-family: Arial, Verdana, sans-serif; font-size: 12px; color: rgb(34, 34, 34); background-color: rgb(238, 238, 238); ">

[Garry Yao]

#6783 marked as a DUP.

[Garry Yao]

Replying to wwalc:

Note that if you change the background color in contents.css into any other than white (e.g #eee), Safari will use the same background-color in this extra div element:

<div style="font-family: Arial, Verdana, sans-serif; font-size: 12px; color: rgb(34, 34, 34); background-color: rgb(238, 238, 238); ">

In that case it's difficult to find a proper way to determinate such an extra div, we might need to wait for a Webkit fix eventually.

[Jakub Ś]

Similar (perhaps related) issue #6366

[Jakub Ś]

Bug reported by @garry.yao to Webkit - ​https://bugs.webkit.org/show_bug.cgi?id=61779

As agreed with @wwalc I'm confirming this ticket.

[Garry Yao]

The fixing of this bug has been planned in the new pasting system of v4 thus is not likely to be resolved in recent milestones.

[Satya Minnekanti]

Replying to garry.yao:

@garry.yao could you please add the ticket that you logged with Safari & Chrome for this issue

[Frederico Caldeira Knabben]

@satya, please check previous comments.

[Jakub Ś]

This ticket was duplicated in #5394

[Jakub Ś]

#6366 was marked as duplicate.

The same thing happens when you drag the contents from one editor to another.

[Jakub Ś]

This is Webkit pasting problem and also our problem.

When you paste something from Notepad in Webkit or when you paste HTML it gets wrapped in Divs. When you have your enter mode set to default ENTER_P (paragraph) those Divs get pasted inside this paragraph.
This can be confirmed when looking at elements path and when viewing the code with Chrome developer tools (Please check the attached screen.png)
This invalid code gets fixed when switching to source or getting the data from editor (when HTML data processor is called). That is why users get impression that extra p is added.

For the above example with heading scenario is acctually the same. You paste Heading wrapped in Div into Heading what results in:

<h1><div style="font-family: Arial, Verdana, sans-serif; font-size: 12px; color: rgb(34, 34, 34); background-color: rgb(255, 255, 255); ">
	<h1>
		Heading1</h1>
</div></h1>

This gets fixed when you swich to source mode and the result is:

<h1>
	&nbsp;</h1>
<div style="font-family: Arial, Verdana, sans-serif; font-size: 12px; color: rgb(34, 34, 34); background-color: rgb(255, 255, 255); ">
	<h1>
		Heading1</h1>
</div>

Note that with the above example extra paragraph at the bottom is generated - it was described here: #8231 .

NOTE: This will be fixed in version 4 of editor which will soon be introduced.

[Jakub Ś]

Other tickets that also concern pasting in Webkit: #6436 and #6131

[Jakub Ś]

Original ticket is no longer reproducible in Chrome 18 but there is a way to still reproduce it. All you have to do is copy element like p or h1 with new line

TC taken from #8932:

1. Content in the editor:

   <p>This is some <strong>sample text</strong>. You are using <a href="http://ckeditor.com/">CKEditor</a>.</p>
   

2. Insert new paragraph at the end (hit return)
3. Select all (Ctrl+A) and copy (Ctrl+C)
4. Go to the end of the editor (the blank line)
5. Paste in the text (Ctrl+V) several times

[Jakub Ś]

#9051 was marked as duplicate.

[Piotrek Koszuliński]

Replying to j.swiderski:

Original ticket is no longer reproducible in Chrome 18 but there is a way to still reproduce it. All you have to do is copy element like p or h1 with new line

This issue is no longer reproducible in v4.

[Jakub Ś]

#9257 was markes as duplicate.

Comment from that ticket -

Because that's Safari's 5 problem. I believe that it was occurring in old version of Chrome, but was fixed in Webkit's version released between Safari 5 and Safari 6 (so it's also fixed in Safari 6).

[Piotrek Koszuliński]

This issue definitely isn't reproducible any more.

[Satya Minnekanti]

Replying to Reinmar:

This issue definitely isn't reproducible any more.

This is still reproducible in Safari on latest 4.x nightly builds as well. Please re-open this defect

[Piotrek Koszuliński]

On which version of Safari?

[Satya Minnekanti]

Replying to Reinmar:

On which version of Safari?

On Safari 5.1.2 & 5.1.7

[Piotrek Koszuliński]

I can reopen this ticket but we're not going to fix this issue, because it has been fixed in Webkit many months (years?) ago, so both - Chrome and Safari 6 work correctly. It would be pointless to keep this ticket until we drop support for Safari 5.

Nota bene - since CKEditor 4.1 when editor is initialized without div support (removed div plugin or div button from toolbar) this issue will be fixed by the ACF (see #9829).