[Webkit-unassigned] [Bug 56027] Assert that editing does not ignore position's anchorNode if position is an offset in anchor

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Mar 10 19:36:21 PST 2011


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





--- Comment #6 from Ryosuke Niwa <rniwa at webkit.org>  2011-03-10 19:36:21 PST ---
(From update of attachment 85422)
View in context: https://bugs.webkit.org/attachment.cgi?id=85422&action=review

>> Source/WebCore/dom/PositionIterator.cpp:43
>> +            return positionBeforeNode(m_anchorNode);
> 
> How does this change behavior?  How do we test this?

It doesn't.  It only helps us moving towards getting rid of weird positions like [textarea, 0]

>> Source/WebCore/editing/ApplyStyleCommand.cpp:1699
>> +        positionForStyleComparison = firstPositionInOrBeforeNode(startNode.get());
> 
> Same question.

Ditto.

>> Source/WebCore/editing/htmlediting.cpp:-79
>> -           !node->hasTagName(buttonTag) &&
> 
> Same question. :)  Buttons are editing boundaries, aren't they?  And aren't their editable kids shadow DOMs?

Right.  I forgot to do "svn add".  I'm uploading a new patch with a test.

>> Source/WebCore/editing/visible_units.cpp:381
>> +    VisiblePosition visPos = startNode->isTextNode() ? VisiblePosition(Position(startNode, static_cast<InlineTextBox *>(startBox)->start(), Position::PositionIsOffsetInAnchor), DOWNSTREAM)
> 
> Same qeustion. :)

Same.  We don't really change the apparent behavior.  It's just that we used to have [br, 0] and now we do before br.

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