[Webkit-unassigned] [Bug 26633] Pasting a H2 into an H2 results in 2 H2's wrapping the content

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=26633


ojan at chromium.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eric at webkit.org,
                   |                            |justin.garcia at apple.com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1




------- Comment #2 from ojan at chromium.org  2009-06-22 18:23 PDT -------
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.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.