Issue metadata
Sign in to add a comment
|
Editing of text that contains a pulli (Tamil: புள்ளி, puḷḷi, character ் mentioned at http://graphemica.com/0BCD) results in the consonant+pulli combination of characters being interpreted as a part of the subsequent character.
Reported by
shankark...@gmail.com,
Dec 18 2016
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Example URL: https://www.facebook.com/ Steps to reproduce the problem: 1. Open Facebook (as an example) 2. Type அச்சம் using a Tamil keyboard driver. 3. From the end of the word, move the cursor to the left. The cursor position would change behind ம். 4. Move to the left again. What is the expected behavior? The cursor should move behind ச. What went wrong? The cursor moves behind ச், one more character away than it is supposed to go Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 52.0.2743.116 Channel: stable OS Version: Linux Mint 18 Flash Version: Shockwave Flash 24.0 r0 The root cause may be related to the other issue about editing content, filed as https://bugs.chromium.org/p/chromium/issues/detail?id=675477 .
,
Dec 18 2016
Same issue happens in Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
,
Dec 18 2016
,
Dec 18 2016
,
Dec 19 2016
Able to reproduce the issue on the latest canary(57.0.2956.0) of Mac OS 10.12.2 as well. Regressed in M-51. Last good build: 51.0.2702.0 First bad build: 51.0.2703.0 Changelog: ========== https://chromium.googlesource.com/chromium/src/+log/93a08a4b973b9cca6f7f3d182d9a13102755da2b..c8047e8e3db7bb1878da59f18446b15b123f1edf Suspecting: https://codereview.chromium.org/1853033002. nona@: Could you please take a look at this. Note: Getting We dont have enough builds to bisect when trying hasbisect-per-revision bisect for win(32 bit).
,
Apr 26 2017
Minimal repro: <textarea>ச்ச</textarea>
Press ArrowRight at left edge
Expect: caret before U+0B9A
Actual: caret at right edge
Suspicious is below code in IsGraphemeBreak().
// Cluster Indic syllables together.
if (IsIndicSyllabicCategoryVirama(prev_code_point) &&
u_getIntPropertyValue(next_code_point, UCHAR_GENERAL_CATEGORY) ==
U_OTHER_LETTER)
return false;
,
Apr 26 2017
If my understanding is correct, to fix this issue completely, need to shape the virama sequence and see the result. Currently, the grapheme cluster is calculated only from code points but in virama case we need to shape the code point and see the result whether it is came from single glyph (ligatured) or two or more glyph. See variant glyph forms in this article. https://www.w3.org/2002/Talks/09-ri-indic/indic-paper.html I think this requires huge changes in Blink, so if Chrome used to breaks grapheme cluster inside the virama sequence, it would be good to revert the behavior as the old one. Note that, in that case, if the font has a ligature for virama sequence, the caret will be placed middle of the character.
,
Apr 26 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by shankark...@gmail.com
, Dec 18 2016