26633 2009-06-22 17:46:43 -0700 Pasting a H2 into an H2 results in 2 H2's wrapping the content 2010-02-21 20:23:06 -0800 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) PC OS X 10.5 RESOLVED DUPLICATE 26937 P3 Normal --- 1 vkarun webkit-unassigned eric jparent justin.garcia ojan tony oldest_to_newest 127520 0 vkarun 2009-06-22 17:46:43 -0700 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. 127521 1 31694 vkarun 2009-06-22 17:47:50 -0700 Created attachment 31694 Sample HTML for reproducing this bug 127540 2 ojan 2009-06-22 18:23:26 -0700 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. 131762 3 32750 rniwa 2009-07-14 17:32:49 -0700 Created attachment 32750 demonstrates the same bug but also in Firefox 131764 4 32750 rniwa 2009-07-14 17:34:11 -0700 Comment on attachment 32750 demonstrates the same bug but also in Firefox sorry, wrong bug. 192339 5 tony 2010-02-21 20:23:06 -0800 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 *** 31694 2009-06-22 17:47:50 -0700 2009-06-22 17:47:50 -0700 Sample HTML for reproducing this bug webkit_h2_paste.html text/html 205 vkarun PGh0bWw+Cjxib2R5Pgo8ZGl2IGNvbnRlbnRFZGl0YWJsZSBzdHlsZT0iYm9yZGVyOiAycHggc29s aWQgI2U4ZThlOCI+CjxoMj5IZWFkaW5nIDE8L2gyPgo8ZGl2PmxpbmUgMTwvZGl2Pgo8ZGl2Pmxp bmUgMjwvZGl2PgoKPGgyPkhlYWRpbmcgMjwvaDI+CjxkaXY+bGluZSAzPC9kaXY+CjxkaXY+bGlu ZSA0PC9kaXY+CjwvZGl2PgoKPC9ib2R5Pgo8L2h0bWw+Cg== 32750 2009-07-14 17:32:49 -0700 2009-07-14 17:34:11 -0700 demonstrates the same bug but also in Firefox noneditable-style-change.html text/html 872 rniwa PGh0bWw+Cjxib2R5Pgo8ZGl2IGlkPSJlIj4KPGRpdiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjb250ZW50ZWRpdGFibGU9ImZhbHNlIj48ZGl2IGlkPSJ0ZXN0IiBzdHlsZT0i dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjb250ZW50ZWRpdGFibGU9InRydWUiPnRleHQ8 L2Rpdj48L2Rpdj4KPC9kaXY+Cgo8dWw+CjxsaT5CZWZvcmU6PHNwYW4gaWQ9ImMxIj48L3NwYW4+ PC9saT4KPGxpPkFmdGVyOjxzcGFuIGlkPSJjMiI+PC9zcGFuPjwvbGk+CjwvdWw+Cgo8c2NyaXB0 IHR5cGU9InRleHQvamF2YXNjcmlwdCI+CgppZiAod2luZG93LmxheW91dFRlc3RDb250cm9sbGVy KQogICAgbGF5b3V0VGVzdENvbnRyb2xsZXIuZHVtcEFzVGV4dCgpOwoKd2luZG93LmRvY3VtZW50 LmRlc2lnbk1vZGUgPSAiT24iOwoKdmFyIGUgPSBkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnZScp Owpkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgnYzEnKS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVh dGVUZXh0Tm9kZShlLmlubmVySFRNTCkpOwoKdmFyIHMgPSB3aW5kb3cuZ2V0U2VsZWN0aW9uKCk7 CnZhciByID0gZG9jdW1lbnQuY3JlYXRlUmFuZ2UoKTsKci5zZXRTdGFydChkb2N1bWVudC5nZXRF bGVtZW50QnlJZCgndGVzdCcpLDApOwpyLnNldEVuZChkb2N1bWVudC5nZXRFbGVtZW50QnlJZCgn dGVzdCcpLDEpOwpzLnJlbW92ZUFsbFJhbmdlcygpOwpzLmFkZFJhbmdlKHIpOwpkb2N1bWVudC5l eGVjQ29tbWFuZCgidW5kZXJsaW5lIiwgZmFsc2UsIG51bGwpOwoKZG9jdW1lbnQuZ2V0RWxlbWVu dEJ5SWQoJ2MyJykuYXBwZW5kQ2hpbGQoZG9jdW1lbnQuY3JlYXRlVGV4dE5vZGUoZS5pbm5lckhU TUwpKTsKCjwvc2NyaXB0Pgo=