[Webkit-unassigned] [Bug 26937] Copying and pasting into a contenteditable area can create <div>s surrounded by <span>s

[bugzilla-daemon at webkit.org]

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





--- Comment #5 from Ryosuke Niwa <rniwa at webkit.org>  2009-07-31 18:20:11 PDT ---
It turned out that fixing this bug is rather challenging because so much of
existing code depends on the fact that we pass Apple-style-span.  In
particular, when we add div, we end up producing a lot of extra div's, and
removing them later is hard because removing arbitrary div would cause
paragraph to disappear.  What we really need to do is to re-design how we
handle style during copy & paste ground up.  Unfortunately, I don't think I can
fix this bug anytime soon.

Here is my note for future reference.

1. The bug is caused by the last two calls to addStyleMarkup in createMarkup.

2. I added new boolean type to getStartMarkup that keeps track of whether we
encountered block flow element yet or not.  If we did, then we should use div
instead of span as the wrapping node.  But it turned out that this is not a
sufficient condition beacuse if we have a <span>foo</span><div>bar</div>, and
copy and paste this, we should not be wrapping it with a div.

3. To remove redundant styles and divs, I edited handleStyleSpans and
handleStyleSpansBeforeInsertion.  But removing extra div caused another problem
that we don't know whether we can remove a given div safely or not.

4. For the re-deign of copy&paste logic, we should push down all relevant
comptuedStyles to each root node we're copying.  e.g. when we're copying
<span>foo</span><div>bar</div>, we should apply computedStyles to each span and
div node, instead of adding extra node to preserve style.  This would prevent
us from producing extra spans and there will be no need to remove span's/div's
later.

With this approach, only case in which we might need to produce a span is when
we have a plain text and copying it without wrapping HTML element.  But this is
highly unlikely because we can safely assume that any text node is a child of
some HTML element that applies the style to the text.  If there was no HTML
element to split, then we should treat it as plain text anyways.

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