581764 - [IMM32] Sometimes ATOK failed to initialize Kana-Nyuryoku mode

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

1. Use Kana-Nyuryoku (かな入力) mode of ATOK.
2. Load http://www.cocolog-nifty.com/ and set focus to an input element.
3. Load http://www.google.co.jp/ on the tab.

Then, an input field of google is focused. But we cannot input Kana.

I'm not sure why this bug cannot be reproduced on other pages. But I find what is the cause. ATOK sends WM_IME_COMPOSITION before WM_IME_STARTCOMPOSITION, and we handle the WM_IME_COMPOSITION. But if we access ATOK via API at this time, ATOK failed to initialize the Kana-Nyuryoku mode.

We cannot ignore WM_IME_COMPOSITION before WM_IME_STARTCOMPOSITION if the IME is MS-IME, see bug 60050. Therefore, I'm looking for the condition we can ignore the message.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v1.0

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v2.0

This is safer than v1.0.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 460189 [details] [diff] [review]
Patch v2.0

Ah, I should check lParam too.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v3.0

ATOK always sends same lParam at composing, so, this should be safer than v2.0.

Comment 5

[Jim Mathies [:jimm]]

Comment on attachment 460245 [details] [diff] [review]
Patch v3.0


>+ // and if we access ATOK via some APIs, ATOK sometimes fail to initialize its
+  // and if we access ATOK via some APIs, ATOK will sometimes fail to initialize its

>+ // state.  If WM_IME_STARTCOMPOSITION is already in queue, we should ignore
+  // state.  If WM_IME_STARTCOMPOSITION is already in the message queue, we should ignore

>+ // the strange WM_IME_COMPOSITION message.  So, we should look for next
+  // the strange WM_IME_COMPOSITION message and skip to the next

>+ // ATOK, probably.  Otherwise, we should start composition forcibly.

'probably'? :) This sounds like a bit of a hack, which I know we do occasionally have to do for 3rd party ime's, but what are the risks here?

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v4.0

(In reply to comment #5)
> >+ // ATOK, probably.  Otherwise, we should start composition forcibly.
> 
> 'probably'? :) This sounds like a bit of a hack, which I know we do
> occasionally have to do for 3rd party ime's, but what are the risks here?

I think the risk is minimum. If the next composition message is WM_IME_STARTCOMPOSITION, that means composition will be starting normally. So, we can handle the composition without the strange WM_IME_COMPOSITION.

However, I found a new risk when I was writing this comment. That is, if IME sends WM_IME_COMPOSITION -> WM_IME_STARTCOMPOSITION -> WM_IME_ENDCOMPOSITION, we cannot handle WM_IME_COMPOSITION by the previous patch. So, this patch also checks whether both WM_IME_STARTCOMPOSITION and WM_IME_COMPOSITION messages are coming or not. I think that lParam check isn't needed by this check because even if we ignore the strange WM_IME_COMPOSITION message unexpectedly, we can recover at the next WM_IME_COMPOSITION message.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, WM_IME_STARTCOMPOSITION is sent by MS-IME of latest Win2k and WinXP. So, bug 60050 has been also fixed by MS. So, we don't need to worry about MS-IME.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 460419 [details] [diff] [review]
Patch v4.0

The Kana-nyuryoku mode user of ATOK is minority. But this fix is important for them. The risk should be low because this patch only works with strange Windows message pattern (i.e., with normal message order, this patch doesn't change any behavior).

Comment 9

[Joe Drew (not getting mail)]

No tests? :(

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #9)
> No tests? :(

Yes, we cannot test the native IME handling code, see bug 460056.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

http://hg.mozilla.org/mozilla-central/rev/dd0ca5cf12ea

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 460419 [details] [diff] [review]
Patch v4.0

I haven't seen any regression reports about this bug. See comment 8, this bug doesn't happen on most Japanese IME users, but this bug is very annoying the other users. So, I hope that this is fixed on 1.9.2 branch too.

Comment 13

[Daniel Veditz [:dveditz]]

Comment on attachment 460419 [details] [diff] [review]
Patch v4.0

Approved for 1.9.2.10 and 1.9.1.13, a=dveditz for release-drivers

Comment 14

[Daniel Veditz [:dveditz]]

er, not approved for 1.9.1.13, there was no request.

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fc024eb82e9e

Comment 16

[Marco Bonardo [:mak]]

looks like you forgot to set status-1.9.2, I'm setting it as .10-fixed, correct me if i'm wrong.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, thank you!

Comment 18

[Al Billings [:abillings - ex-MoCo]]

I've asked Naoki to verify this for 1.9.2.

Comment 19

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I do not mind testing this, however I would need a copy of ATOK for bug regression purposes.

Comment 20

[Al Billings [:abillings - ex-MoCo]]

Masayuki, can you help Naoki with getting a copy of ATOK?

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

If you test only this bug, you can use a trial version.
http://www.atok.com/try/

But if you want to use it continuously, you need to buy the license.
http://www.atok.com/products/index.html
# There is download version.

Note that ATOK2010 is a first version of unicode version. So, it should work on non-Japanese locale Windows, but might have some problems. And also the UI is written only in Japanese, there is no English UI.

Comment 22

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Nakano-san, should I be able to reproduce the issue with Mozilla Firefox 4.0 Beta 2?  According to the release date : 20100720 it should not have the fix.
I have tried to test to make sure I understand the issue, but perhaps I do not have the right settings.  I have tried with a English locale of Windows with Japanese IME + ATOK 2010.

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #22)
> Nakano-san, should I be able to reproduce the issue with Mozilla Firefox 4.0
> Beta 2?

Yes. But we're not sure what are the conditions of this bug.

> I have tried to test to make sure I understand the issue, but perhaps I do not
> have the right settings.  I have tried with a English locale of Windows with
> Japanese IME + ATOK 2010.

Cannot you reproduce this bug with the STR of comment 0?

If you're using Roman mode (ローマ字入力), you must change the input mode when Fx has focus (IME settings are not shared between processes after they are started).

And set focus to an input field on http://www.cocolog-nifty.com/

And load http://www.google.co.jp/ on the same tab (i.e., you should add this to bookmark toolbar).

Then, the focus is moved to the input field of google. Then, type 'A' key, you should see 'ち', but you can see 'a' on the old build.

Comment 24

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Nakano-san, I am still not able to reproduce the issue using what I have.  While FireFox was loaded, I have tried switching the mode to Kana mode after the site in step 2 as well as before the site in step 2.  I have tried several other combinations in trying to reproduce the issue.  http://www.youtube.com/watch?v=L37E1ty0PCI is a sample video of what I have been doing to try to reproduce the issue.

I am using a Virtual Machine on Mac OS X 10.6, of Windows 7 English.

Comment 25

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Um, I cannot reproduce it on 4.0b2 too. It's strange...

I guess that flash player's version or the web pages were changed... I believe that this bug is an ATOK's. In fact, sometimes, I can still see this bug in other cases. I think that my patch killed only one triger of the bug but the trigger is hidden by something now.

Comment 26

[Al Billings [:abillings - ex-MoCo]]

So it looks like there is no way to verify this fix. Would you agree, Masayuki?

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Yes.

Comment 28

[Al Billings [:abillings - ex-MoCo]]

All, marking it as such for QA in the whiteboard.

Comment 29

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

ATOK 2012 added a new setting for preventing this problem. You can enable the workaround from ATOK's property dialog. See my blog post for how to do it:
http://www.d-toybox.com/studio/weblog/show.php?mode=single;id=2012021001