[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