[Webkit-unassigned] [Bug 28306] double-clicking a word inside <b> beside newline select two words

[bugzilla-daemon at webkit.org]

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


Darin Adler <darin at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #35046|review?                     |review-
               Flag|                            |




--- Comment #14 from Darin Adler <darin at apple.com>  2009-10-13 13:13:04 PDT ---
(From update of attachment 35046)
Thanks for tackling this.

I believe this code change is not quite right. It may make the word break work
correctly in this case, but it is probably not right in all cases for the
backwards text iterator.

The backwards text iterator does need to detect that there's a word break here,
but it is not good for it to do this by just emitting all the trailing
whitespace that happens to be in the string. I suspect there are also cases
where there could be a line break but no actual whitespace in the string,
depending on what element comes after the string. One example I can think of
would be a subsequent text node that is entirely whitespace.

We should consider carefully why the forward text iterator has whitespace there
and figure out how to do the equivalent for backward. The forward iterator
definitely does *not* use the trailing whitespace in the DOM string to do this.

> +    // use str.length() instead of caretMaxOffset()
> +    // because caretMaxOffset() is based on InlineBox and not considering trailing whitespaces,
> +    // which should be handled during word-boundary detection.

There should be a capital "U" on use, and this should be broken into lines of
similar length.

> +    if (m_positionEndOffset == 0)
> +      return false;

WebKit style is to use !m_positionEndOffset rather than "== 0" and the second
line should be indented four spaces, not two.

review- for now. It may turn out that with more analysis we conclude that this
is the best fix, but I suspect that it's not quite right.

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