[Webkit-unassigned] [Bug 38231] crash in WebCore::CompositeEditCommand::splitTreeToNode when indenting pre
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Apr 28 00:49:50 PDT 2010
https://bugs.webkit.org/show_bug.cgi?id=38231
Tony Chang (Google) <tony at chromium.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|crash in |crash in
|WebCore::CompositeEditComma |WebCore::CompositeEditComma
|nd::splitTreeToNode when |nd::splitTreeToNode when
|indenting in an unclosed |indenting pre
|pre |
--- Comment #5 from Tony Chang (Google) <tony at chromium.org> 2010-04-28 00:49:49 PST ---
Here's a test case with a closed pre. I've also posted a patch, but it's
wrong. It's just showing some of the things I tried.
There are two problems. First is that
CompositeEditCommand::cloneParagraphUnderNewElement expects paragraphs to map
to nodes. However, with <pre>, paragraphs can be strings of text. For
example, in the test case, we have:
<pre>a
b
</pre>
a and b are both separate paragraphs. However, when we try to clone the
paragraphs, we clone the whole pre node. I tried modifying
cloneParagraphUnderNewElement to handle the case where we're only cloning part
of a node (see patch).
The second problem is in IndentOutdentCommand::indentRegion. It has similar
logic that keeps track of the next paragraph to indent. Unfortunately, after
the first indent, |endOfNextParagraph| is pointing to the wrong place since we
just removed text from the <pre> node causing the node offset to be wrong. I
tried to fix that in the patch as well, but it doesn't properly update
|endAfterSelection|.
This seems very fragile, so maybe someone has some better ideas. For example,
maybe rather than trying to indent each paragraph, we would try to do a single
indent if everything is in a single node. Or maybe we can split the pre into
multiple pre tags before we start moving paragraphs. Thoughts?
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list