[Webkit-unassigned] [Bug 61344] --webkit-visual-word does not work in multi-line

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Oct 12 18:16:48 PDT 2011


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





--- Comment #41 from Xiaomei Ji <xji at chromium.org>  2011-10-12 18:16:47 PST ---
(From update of attachment 110748)
View in context: https://bugs.webkit.org/attachment.cgi?id=110748&action=review

>>>>>> Source/WebCore/editing/visible_units.cpp:606
>>>>>> +    }
>>>>> 
>>>>> Why do we need this struct? Can't we just pass arguments around?
>>>> 
>>>> yes you are right that we do not need this struct. instead, we can just pass arguments around. then, instead of a struct, we will need to pass 4 arguments around. Also, the |offset| and |root| are only needed if the |rule| is CanNotCrossEditingBoundary.
>>> 
>>> Could you elaborate on why we need those 4 arguments?
>> 
>> this function is extracted to be shared by nextLinePosition() and nextRootInlineBox().
>> nextLinePosition() honor editing boundary while nextRootInlineBox() does not. This is from the 1st data member.
>> 
>> When it is honor editing boundary, in original code inside nextLinePosition(), the first next leaf node it gets is through nextLeafWithSameEditability(), and it accepts 2 parameters -- the node, and the original visible position's Position's offset which is the 2nd data member here.
>> 
>> When it is honor editing boundary, the code exits earlier when the next node's highest editable root is not the same as original node's highest editable root. original node's highest editable root is the 3rd data member.
>> 
>> In original code inside nextLinePosition(), when position is a candidate but without root inline box, this position is returned as next line position. I am not clear on what to do when we only want to get next root inline box in this case (pls. refer comment at line 656), and I ignored such case for nextRootInlineBox(), hence the 4th parameter to differentiate.
> 
> It seems to me we need to decide to do either and refactor the code first accordingly. It's not great to support both behaviors.

nextRootInlinBox() can do honor editing boundary. It is just that honor editing boundary is the last step in those editing operations, so that we do that as the last step in rightWordPosition()/leftWordPosition. If we honor editing boundary in nextRootInlineBox, the functionality should be the same, but the code will exit earlier.

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