Bug 26633 – Pasting a H2 into an H2 results in 2 H2's wrapping the content

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: HTML Editing

[Venkat Karun]

Assume we have a snippet like 
<div contentEditable>
  <h2>Heading 1</h2>
  <div>line 1</div>

  <h2>Heading 2</h2>
  <div>line 2</div>
</div>

1) Place your cursor at the beginning of Header 2 and press enter to create a newline.
2) Go to the line created in the previous step and paste the entire section 1 (from Heading 1 to end of line 1). 

Expected result:
The content is pasted without being wrapped in an h2.

Actual result:
The pasted content is wrapped in the h2 created in step (1) and results in the following HTML.

<h2><span class="Apple-style-span" style="font-size:16px;font-weight: normal;"><h2>Heading 1</h2><div>line 1</div><div>line 2</div></span></h2>

FF and IE seem to handle this quite gracefully.

[Venkat Karun]

Created attachment 31694 [details]
Sample HTML for reproducing this bug

[Ojan Vafai]

This is actually considerably more general. Anytime you copy-paste from one type of "special" block to another type of "special" block, they get nested. There are a number of block types that have this bug, e.g. pasting a pre into an h1 will also do this.

Also, simpler steps to reproduce:
1. select all the text inside an H1
2. copy
3. paste

You get an H1, nested inside a SPAN, nested inside an H1.

See http://trac.webkit.org/browser/trunk/WebCore/editing/markup.cpp#L739 for the full list of affected nodes.

It's not clear to me what the best behavior for this situation is. There are a bunch of edge cases that IE, Gecko and WebKit deal with very differently with these sorts of copy-pastes.

1. IE only copies the block if the whole line is selected, otherwise, it just copies the inline content (in this case, the plain text).
2. Gecko/WebKit copy the block if it's one of these specialAncestorBlocks, even if only one character in the block is selected.

Presumably the Gecko/WebKit behavior is to maintain the appearance of the old code while trying to maintain sane markup. There are cases here where Gecko ends up with strange markup as well. There are also cases where WebKit will convert the block into an inline span and transfer all the appropriate styling. 

Perhaps the latter is the correct thing to do and then to remove all the extraneous styles. Although, really the IE behavior is a lot simpler, but users can't wrap their heads around an H1 being different than bold+large-font-size, which is what leads to the Gecko/WebKit approach.

[Ryosuke Niwa]

Created attachment 32750 [details]
demonstrates the same bug but also in Firefox

[Ryosuke Niwa]

Comment on attachment 32750 [details]
demonstrates the same bug but also in Firefox

sorry, wrong bug.

[Tony Chang]

I think this is fixed by http://trac.webkit.org/changeset/54933 from bug 26937.  The extra span is now removed and the styles are propagated to the child nodes.  In this case, there's nothing to propagate so when I try the test case in ToT Safari, I get:

<div contenteditable=""> <h2>Heading 1</h2> <div>line 1</div> <h2>Heading 2</h2><div><h2>Heading 1</h2><div>line 1</div></div><div><br></div> <div>line 2</div> </div>

Which seems fine to me.

Please comment if you see otherwise and I will investigate some more.

*** This bug has been marked as a duplicate of bug 26937 ***