ettoolong Reporter
	Description • 9 years ago

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151119130424

Steps to reproduce:

This is my test page:
http://ettoolong.github.io/test/input_test.html
This issue for Firefox 41 and later version.

My javascript code addEventListener for event compositionstart and compositionend.
When compositionend event fired, we output event.target.value and set event.target.value to null string.


Actual results:

When I input 5 Chinese character, enter, and input more Chinese character,
We can't select character any more.


Expected results:

We should select character when input.

	Loic
	Comment 2 • 9 years ago

Which Chinese keyboard do you select in Windows?
I'm not able to reproduce with Chinese Simplified QuanPin (on native AZERTY keyboard), each time I select a word, "enter" is fired and I can only type one word in the output.

	ettoolong Reporter
	Comment 3 • 9 years ago

(In reply to Loic from comment #2)
> Which Chinese keyboard do you select in Windows?
> I'm not able to reproduce with Chinese Simplified QuanPin (on native AZERTY
> keyboard), each time I select a word, "enter" is fired and I can only type
> one word in the output.

I use Chinese traditional US keyboard.

We have two type Chinese input method:

1. We type all character code and finish input.
ex: Cangjie(倉頡)/Boshiamy(嘸蝦米)/Phonetic(ㄅ半) input method

2. We type character code, it will auto select one Chinese character. Sometime, we need use arrow key to select correct Chinese character.
ex: Chewing/(新酷音) Microsoft New Phonetic(微軟新注音) input method

We can reproduce this bug on type 2 input method.

	Loic
	Comment 4 • 9 years ago

Ok, I'm able to reproduce the issue with the Simplified Chinese Microsoft Pinyin New Experience input method in FF41. But I tested with Nightly (FF45) and it works fine, so it's probably already fixed.

Could you download FF45 an confirm it's fixed on your side, please. https://nightly.mozilla.org/

	ettoolong Reporter
	Comment 5 • 9 years ago

Thanks, I have more testing for this issue:

FF41~42(Stable) reproduce bug.
FF43b5(Beta) reproduce bug.
FF44(Dev edition) works fine.
FF45(Nightly) works fine.

In fact, I test this issue one month ago.
FF42(Beta) reproduce bug.
FF43(Dev edition) works fine.
I think it already fixed in FF43 but it still wrong on FF43b5 today.

I hope it will be fixed on FF44 and later.
Thank you.

	Loic
	Comment 6 • 9 years ago

Ty for the feedback. Reopen the bug if the issue is not fixed in the next versions.

	ettoolong Reporter
	Comment 7 • 9 years ago

Update testing report:

FF43 (Stable) reproduce bug.

FF46.0a1 (Nightly) something wrong:
I can select character by arrow key bug input cursor display at wrong position.
(compare with Developer Edition 44.0a2)

In previous nightly build(2015-11-23 05:38:15 PST), it works fine(no cursor position issue).

Any ideas?

	Loic
	Comment 8 • 9 years ago

It's weird, it's wrong too with the build from 2015-11-23.
http://ftp.mozilla.org/pub/firefox/nightly/2015/11/2015-11-23-03-02-37-mozilla-central/firefox-45.0a1.en-US.win32.zip

Can you test?

	ettoolong Reporter
	Comment 9 • 9 years ago

(In reply to Loic from comment #8)
> It's weird, it's wrong too with the build from 2015-11-23.
> http://ftp.mozilla.org/pub/firefox/nightly/2015/11/2015-11-23-03-02-37-
> mozilla-central/firefox-45.0a1.en-US.win32.zip
> 
> Can you test?
This build 2015-11-23 also wrong. Can't select character and wrong cursor position.

	ettoolong Reporter
	Comment 10 • 9 years ago

test Nightly build 2015-12-30 (46.0a1), works fine.

	Loic
	Comment 11 • 9 years ago

not for me, this chinese keyboard is so broken.

	ettoolong Reporter
	Comment 12 • 8 years ago

(In reply to Loic from comment #11)
> not for me, this chinese keyboard is so broken.
Some builds work find and some builds broken.

This issue have another easy way to reproduce:
Step 1. The input field have some character. (ex: input.value='aaaaaaaaaaaa').
Step 2. Modify input.value in 'compositionstart', 'compositionend' or 'input' event. (ex: input.value = '')
Step 3. Type Chinese/Japanese/Korean character.

Notice that: 
If the input.value.length is short ex: ex: input.value='a' everything will find.
If the input.value.length is long ex: ex: input.value='aaaaaaaaaaaaa' will break IME/TSF.

I think it broken some memory data in step 2, and we can decide how many memory data to break.
It may cause some exploit and security issue.
Everyone can do this with an input field on HTML page.

This issue effected 3 Firefox stable release(41~43 and more?) on windows platform.
About one of Firefox 41 release notes:
"Enhance IME support on Windows (Vista +) using TSF (Text Services Framework)"
Is it caused this issue?

	ettoolong Reporter
	Comment 13 • 8 years ago

/s/find/fine

	Loic
	Comment 14 • 8 years ago

If you think it worked in previous versions of Firefox, can you use the tool mozregression to find a regression range, please.
See http://mozilla.github.io/mozregression/ for details.
Just use the command-line version, like "mozregression --bits=32 --good=40".
After that, copy here the final pushlog provided in the console output.

	Makoto Kato [:m_kato] (PTO until 5/6)
	Comment 15 • 8 years ago

(In reply to ettoolong from comment #12)
> (In reply to Loic from comment #11)
> > not for me, this chinese keyboard is so broken.
> Some builds work find and some builds broken.
> 
> This issue have another easy way to reproduce:
> Step 1. The input field have some character. (ex:
> input.value='aaaaaaaaaaaa').
> Step 2. Modify input.value in 'compositionstart', 'compositionend' or
> 'input' event. (ex: input.value = '')
> Step 3. Type Chinese/Japanese/Korean character.
> 
> Notice that: 
> If the input.value.length is short ex: ex: input.value='a' everything will
> find.
> If the input.value.length is long ex: ex: input.value='aaaaaaaaaaaaa' will
> break IME/TSF.

Maybe, this depends on bug 549674.

	ettoolong Reporter
	Comment 16 • 8 years ago

Resolved in Firefox 45 stable release.