[Webkit-unassigned] [Bug 15914] [GTK] Implement Unicode functionality using GLib

[bugzilla-daemon at webkit.org]

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





------- Comment #58 from zuh at iki.fi  2009-01-13 03:34 PDT -------
(In reply to comment #54)
> On another issue, I guess related to comment #50, there's something that
> introduces a seemingly infinite loop with the glib code. I haven't been able to
> make real sense of it, but at least it's easy to reproduce:
>
> 1. Load google.com
> 2. type something to the search field (I think it needs to be > somecount
> chars, but not sure. 1234567890 should work)
> 3. go back to the beginning of the line and try typing additional text there
> 4. consistently, glib backend goes in to a busyloop while icu does not

Yesterday I took time to debug this further and found the following (excerpt
from mail conversation):

I did some digging with gdb and found that the busyloop
revolves inside VisiblePosition::leftVisuallyDistinctCandidate() in
WebCore/editing/VisiblePosition.cpp. There's two while(true) loops
there and the inner one never exits. After a while of
head-scratching, comparison with ICU implementation and reading ICU
reference, I came to the conclusion that the following should be the
correct fix:

@@ -197,7 +197,7 @@ int textBreakPrevious(TextBreakIterator* bi)
            return i;
        }
    }
-    return textBreakFirst(bi);
+    return TextBreakDone;
 }

The icu docs for ubrk_preceding() say:

 "The value returned is always smaller than offset, or UBRK_DONE."

but the glib implementation was never returning DONE (which is -1)
even for 0 since it calls the BreakFirst which (as the BreakLast
comments also state) always returns the first character of the text.
Also note that BreakNext also returns DONE instead of the last
character already.

---

Dominik agreed and will incorporate this into the next petch/patches.


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