[Webkit-unassigned] [Bug 61594] REGRESSION: Hitting enter in the middle of this span causes the cursor to go to the end of the span

[bugzilla-daemon at webkit.org]

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





--- Comment #15 from Ryosuke Niwa <rniwa at webkit.org>  2011-06-07 18:28:07 PST ---
(In reply to comment #14)
> The new layout tests I added work fine with this new code. However, when I converted the other callers of splitTreeToNode to call splitTree() with a position, I ran into some trouble because I am making too many assumptions about positions, and several layout tests regressed. I think the problems all have the same root cause--I am assuming the containerNode of the position is the same node that was passed into splitTreeToNode originally. However, stepping through the debugger I have found that this is definitely not always the case.

Right, I was expecting this to happen.

> I think I want to use containerNode instead of deprecatedNode/anchorNode, because I also call offsetInContainerNode(). But I  don't see a normalization function for Position except parentAnchoredEquivalent(), which I think sets the containerNode to the parent of the node I wanted it to be. Do you know what the correct thing to do here is?

The correct thing to do is to fix each caller of splitTree.  You're getting into the nasty part of editing now where fixing one bug gives you new bug.  Unfortunately, there's no easy way out of this other than looking at each caller of splitTree and fixing each one of them.

parentAnchoredEquivalent is specifically designed to create a Position to be passed to Range objects and we don't want to call it everywhere because as we discussed during the contributor's meeting, we want to move away from having positions with offset inside an element and calling parentAnchoredEquivalent will move us away from that goal.

> > Source/WebCore/editing/CompositeEditCommand.cpp:1247
> > +        // FIXME: startNode can be null if traverseNextNode returns null. What should it be set to in that case?
> 
> If traverseNextNode() returns null on line 1249, it is because the position is at the end of the last node inside the end node. I am not sure how the function should behave in that case--should it start splitting at the containerNode's parent?

If traverseNextNode returns true, then there's no node left in the tree after this node.  There's no point in splitting tree at that point.  You should probably assert that this never happens.

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