[Webkit-unassigned] [Bug 71207] An extra line break is inserted when pasting into a font element

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 22 18:36:11 PDT 2012


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





--- Comment #8 from Ryosuke Niwa <rniwa at webkit.org>  2012-03-22 18:36:11 PST ---
(From update of attachment 133329)
View in context: https://bugs.webkit.org/attachment.cgi?id=133329&action=review

>>>>> Source/WebCore/editing/ReplaceSelectionCommand.cpp:125
>>>>> +    return createLegacyEditingPosition(parent, n->nodeIndex() + 1);
>>>> 
>>>> Why do we always want to move up in the node hierarchy? If we had a bunch of siblings after pos's container node, then we'll still want to skip those. r- because I don't think this is a correct fix.
>>> 
>>> The insertion position only move up if the visible positions of the current position and the high level node's position are the same. So, if we had a bunch of siblings after pos's container node, they won't get skipped because of the difference visible positions.
>> 
>> Right, but what if they're empty? If that case, I think we do want to skip those empty elements but moving to the next position in the parent may not be possible due to it being a different visible position.
> 
> Correct me if I am wrong :) In the context, the empty elements means they don't occupy any space, right? If so, all the empty sibling elements would have the same visible position as the next position in the parent. For example,
> <div><u>abc^<u></u><u></u></u></div>, "^" is the insertion position. After calling the positionAvoidingPrecedingNodes(), it should be <div><u>abc<u></u><u></u></u>^</div>

Yes, but your code doesn't do that at the moment because you always retrieve the parent of the deprecated node. i.e. the first call to nextPositionInContainerNode would move the position to be anchored at div, then the next call will try to move out of div.

In general, we shouldn't try to out-smart what Position does. Position.next/previous and all other editing code has been well-tested and deals with all sorts of edge-cases. Adding completely different algorithm to deal with this particular situation is extremely undesirable.

-- 
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