Reproduce on: 0.3.154.3 (Official Build 3339)

BTW, To get "ไป" mentioned at insert step3: Switch to Thai IME, hit keyboard "wx".

For the rest, you can just copy and paste them to reproduce the bug.

Delete word
1. Type "ญี่ปุ้" hit keyboard "Pujx6h"
2. Backspace
3. Result "ญี่"
4. expected result "ญี่ปุ"

Insert in the middle sentence
1. Type "อยากญี่ปุ่น"  hit keyboard "vpkdPujx6jo"
2. move cursor to before "ญี่ปุ่น" after "อยาก" like this  "อยาก|ญี่ปุ่น" "vpkd|Pujx6jo"
3. Type "ไป"
4. Result "อยากไญี่ปปุ่น" "vpkdwPujxx6jo"
5. expected result "อยากไปญี่ปุ่น" "vpkdwxPujx6jo"

Thank you for your bug report.

I have investigated this issue today.
Technically, your first case (delete word) is a duplicate of  Issue 1097  in chromium (http://code.google.com/p/chromium/issues/detail?id=1097). As 
written in the said URL, this issue is caused by WebKit and we need to change WebKit directly. Even though this is fixed in my local build, we need 
to verify this fix covers all possible cases.

Your second case (insert in the middle sentence) is a little more complicated. In brief, this is a problem of WebKit which moves the input cursor to 
an incorrect position.
WebKit moves the input cursor to right after inserting a character U+0E44 'ไ'. Unfortunately, at this time, WebKit considers it should not move the 
input cursor after U+0E44 but move the input cursor after a ligature (U+0E0D, U+0E35, and U+0E48) 'ญี่'.
As far as I have investigated today, this problem possibly happens when inputting one of the following "Prepend" characters written in UAX #29 
(http://unicode.org/reports/tr29/):
* U+0E40 THAI CHARACTER SARA E 'เ';
* U+0E41 THAI CHARACTER SARA AE 'แ';
* U+0E42 THAI CHARACTER SARA O 'โ';
* U+0E43 THAI CHARACTER SARA AI MAIMUAN 'ใ';
* U+0E44 THAI CHARACTER SARA AI MAIMALAI 'ไ';
* U+0EC0 LAO VOWEL SIGN E 'ເ';
* U+0EC1 LAO VOWEL SIGN EI 'ແ';
* U+0EC2 LAO VOWEL SIGN O 'ໂ';
* U+0EC3 LAO VOWEL SIGN AY 'ໃ', and;
* U+0EC4 LAO VOWEL SIGN AI 'ໄ'.

jshin, WebKit internally calls the ubrk_following() function of ICU to move an input cursor and this function prevent an input cursor from being set 
after the above characters because UAX #29 prohibits breaking after "Prepend" characters. I'm writing a workaround for WebKit to avoid this issue. 
Nevertheless, it is better for ICU to provide a rule-set which can handle this case.

Regards,

Hironori Bono
E-mail: hbono@chromium.org

(No comment was entered for this change.)

This problem does not happen in other path of chrome
ex. address bar,option
only WebKit.
:)
Can it fix?
wait for next version (^  ^) 

Thank you for your updates.
Fpr your first issue, we have sent a review request to webkit.org and I hope I can be 
able to merge it to Chrome soon.
For your second issue, we noticed this is caused by an inconsistency between WebKit 
and our patched ICU library. So, we need to determine which we should fix, WebKit or 
ICU. Nevertheless, we are trying to fix this issues as soon as possible because we 
realize this issue is very serious one.

"อยากไปญี่ปุ่น" is mean "I want to go to  japan." mean "日本に行きたい。"
lol (^ ^) 

(No comment was entered for this change.)

what is it mean Assigned.

Sorry I forgot about this issue. I'll take a look. I think webkit needs to be changed
. It cannot use ubrk_XXX unconditionally because ICU's character iterator is for
grapheme cluster rather than a single unicode character. I'm not sure what's
expectation of speakers of various languages in different situations. At least when a
syllable (made of multiple Unicode characters) is inserted or 'backspace'[1] is
pressed at the end of a syllable ( issue 1097 ), the unit of the movement/delete should
be a Unicode character rather than a syllable. 

BTW, does 'U+0E44 U+0E0D, U+0E35, U+0E48'  form a valid syllable in Thai? I can check
myself, but I'm taking a shortcut by asking suteanfx. :-)

[1] To be precise, 'backspace with decomposition' as mentioned in  issue 1097 

On gnome-character-map
ไญี่ (wPuj) is not valid syllable in thai.

it has many error with Thai language.

i think i just found a duplicate bug for this in issue #1853

U+0E40 to U+0E44 is "Pretend" character.
if type this character do not move cursor to after two character
[U+0E40] {cursor will be here} [U+0E0D] [U+0E35] [U+0E48] {not here}.

btw I am not good in English skill.
I am suteanfx. my computer can not post today(i don't know why.)
I am real rookie.

(No comment was entered for this change.)

Mstone-2.0 => what is it mean?(my English skill is bad)
Is it mean ? "it will come with Chromium 2.0"

Suteanfx,

Sorry for my lazy updates.
Yes, the fix will come with GOOGLE CHROME 2.0 as well as Chromium 2.0.
As for the progress, we have been writing a WebKit fix to fix this issue now.

Regards,

Yeah! it is the good new.

update!. today I test safari on windows it has the same problem about delete character.
but it has something different something the same
safari (good)
1. type 'ไป' (key 'wx')
2. backspace
3. result 'ไ'

chrome (not good)
1. type 'ไป' (key 'wx')
2. backspace
3. result ''

safari and chrome (same not good)
1. 'ที่' (key 'muj')
2. backspace
3. result ''

about simple typing on safari (very bad. not found on chrome)
1. type 'ปุ' (key 'x6')
2. type '่' (key '่' )
3. can not type anything anymore. T-T

I found something different on Acer Aspire 5593 MWXMi
Windows XP Professional SP3.
Chrome Version 2.0.158.0
It not has bug about delete character.
It has only bug of insert character.

Thank you for the update. When you said 'insert' problem, is it the same problem as 
you initially reported in October?  

Xiaolu, can you test this with the latest build and update us on it? 

Yes,it is the same problem as initially reported.
How can I get lated build?

Now I test it on Chromium 2.0.167.0 (10542)
I test is in the same way. It has only problem insert character.

1. For the insert issue:

   Still reproduce.

   As suteanfx mentioned, still reproduce on latest Chrome trunk build 2.0.168.0 
(developer build 10605) and Webkit nightly build r41199

2. For the delete issue:

   Fixed.

   The issue mentioned in comment 20 doesn't happen to me on latest trunk and Beta 
build, even it happens on Stable build 1.0.154.48

 Issue 8225  has been merged into this issue.

Update For the delete issue on 2.0.168.0 (10787)
can not delete "Prepend" character with out delete after character.

What steps will reproduce the problem?
Delete word
1. Type "ไป"
2. Try to move cursor to middle of  word "ไ|ป"
3. result : can not move, so that can not delete,too.

1. Type "ไป"
2. Try to move cursor to font of  word "|ไป"
3. hit delete key.
4. it delete both.

expected result: if hit delete will delete only one character. cursor can move to the middle of word.

I didn't test this steps last time.

Sorry for my slow updates.
I filed a bug to WebKit and sent a review request which fixes this issue (*1) because 
this issue happens all platforms which uses WebKit with ICU 4.0.

(*1) https://bugs.webkit.org/show_bug.cgi?id=24342

Sorry for my slow updates.
My WebKit fix has been merged into our trunk (as r11209).
Would it be possible to get the latest trunk build from the following URL (*1) and 
check if this issue is fixed?

(*1) http://build.chromium.org/buildbot/continuous/LATEST/

I check it yesterday, and today.
Now i think it all fixed.
Thank you. ^_^

hm....I don't see it improved, getting the issue what I inserted to the sentence for 
example

1. Type "อยากญี่ปุ่น"
2. move cursor to before "ญี่ปุ่น" after "อยาก" like this  "อยาก|ญี่ปุ่น"
3. Type "ไป"
4. Result "อยากไญี่ปปุ่น"
5. expected result "อยากไปญี่ปุ่น"

I don't get the problem in the "deleting word" case.

Thanks
Pornthip

Pornthip

latest version that I have tested is 2.0.170. It has fixed insert and delete.

Verified on trunk build 2.0.172.0 (Developer Build 12303), fixed.

Hi, Anthony:

    Can you please help merge the fix to Beta branch? Thank you very much!

Regards,
Xiaolu

form me on 2.0.172.0 (12332) it fixed. How about any test from other?