[Webkit-unassigned] [Bug 62621] Span ID duplicated when pressing enter at beginning of span

[bugzilla-daemon at webkit.org]

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





--- Comment #11 from Annie Sullivan <sullivan at chromium.org>  2011-06-14 17:56:46 PST ---
(In reply to comment #10)
> (From update of attachment 97197 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=97197&action=review
> 
> > LayoutTests/editing/inserting/return-key-span-start-expected.txt:7
> > +| <span>
> > +|   id="dupe"
> > +|   <div>
> > +|     <span>
> > +|       <br>
> 
> Wow!  Why are we nesting div inside span?  Can we fix this?

This is the current behavior, and my change hasn't affected it. If you look at InsertParagraphSeparatorCommand::doApply(), we have started with the following tree:

<div contenteditable>
  <span>
    hello

startBlock gets set to the contenteditable div. The code falls into the "// Handle case when position is in the first visible position in its block.." block that starts on line 250 of my patch. That code looks for a refNode to insert the new div before:

        if (isFirstInBlock && !nestNewBlock)
            refNode = startBlock;
        else if (insertionPosition.deprecatedNode() == startBlock && nestNewBlock) {
            refNode = startBlock->childNode(insertionPosition.deprecatedEditingOffset());
            ASSERT(refNode); // must be true or we'd be in the end of block case
        } else
            refNode = insertionPosition.deprecatedNode();

nestNewBlock is true and the insertion position is at the start of the text node (not the startBlock), so it falls through to the "refNode = insertionPosition.deprecatedNode();" line. So the div gets inserted right before the "hello" text, as a child of the span.

We know that if we've fallen into this code path, and isFirstInBlock and nestNewBlock are true, that the insertion position is in the first visible position in the block. So I think we want to modify the code in that case to always insert the new div as this first child of startBlock. Does that sound right? In this case, we'd end up with:

<div contenteditable>
  <div>
    <span>
      <br>
  <span>
    hello

It seems like something that should be done in a separate patch. I know my layout test result looks strange, but other than that it doesn't seem to have much to do with this patch. So does that fix need to block this one?

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