[Webkit-unassigned] [Bug 61324] --webkit-visual-word does not work well in words separated by multiple spaces

[bugzilla-daemon at webkit.org]

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





--- Comment #12 from Xiaomei Ji <xji at chromium.org>  2011-06-06 22:41:43 PST ---
(In reply to comment #11)
> (In reply to comment #10)
> > (From update of attachment 95834 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=95834&action=review
> > 
> > > Source/WebCore/ChangeLog:13
> > > +
> > 
> > The old code was trying to find the right word boundary (before the space or after the space) by using previousWordPosition and nextWordPosition. It was introduced as short-cut to improve performance. But they are not correct functionality wise.
> > 
> > Using positionBeforeNextWord() as example, 
> > 
> > first, it checks whether the current position is one kind (either before the space or after the space, but not the right kind we are looking for) of word break position by checking the current position's previousWordPosition's nextWordPosition is the same position as current position, which is wrong for words separated by multiple spaces. For example, given words A and B separated by 3 continuous spaces "A   B", position "A|", "A |", and "A  |" should all be considered as word break positions, but not the right ones we are looking for. But the old code only takes care of case "A|", for which, positonBeforeNextWord() returns correct result "A   |B". It returns "A   B |C" for cases "A |" and "A  |", which are wrong.
> 
> I see.  In the case of "A |", do we hit positionAfterCurrentWord = nextWordPosition(position); and then positionAfterNextWord = nextWordPosition(positionAfterCurrentWord) ?

Yes. That is right.

> 
> > second, The code was assuming calling nextWordPosition by going forward and calling previousWordPosition by going backward returns different positions, which is not true for words not separated by spaces. Given 3 Chinese words "ABC", when cursor is at "A|BC", current position is after current word, and positionBeforeNextWord() still returns current position after calling current position's nextWordPosition's previousWordPosition. It should returns position "AB|C" (ignore the naming accuracy now).
> 
> Ah, I see.
> 
> It'll be nice to summarize this explanation and put it in ChangeLog.

Sure. Will do.

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