1217275 - [IMM] MS-IME for Japanese on WinXP SP3 hangs up at inputting first Kana character

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[Alice0775 White]

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

Build Identifier:
https://hg.mozilla.org/releases/mozilla-beta/rev/cb549dab9a62
Mozilla/5.0 (Windows NT 5.1; rv:42.0) Gecko/20100101 Firefox/42.0

Cannot type text using Microsoft IME standard 2002 ver8.1 on WindowsXP SP3.

Steps to reproduce:
1. IME on
2. Keypress mojira

Actual Results:
も
remaining text will appear after approx. 10sec

Expected Results:
もじら

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=72744e6c31df&tochange=6dfb81107960

Regressed by: Bug 1186015

Comment 2

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

(In reply to Alice0775 White from comment #1)
> Regression window:
> https://hg.mozilla.org/integration/mozilla-inbound/
> pushloghtml?fromchange=72744e6c31df&tochange=6dfb81107960
> 
> Regressed by: Bug 1186015

Are you sure?? The bug just renames the class names and cleaning up the logging code. So, nothing should have been changed.

Comment 3

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

Hmm, I cannot reproduce this bug on my WinXP (on VMware). Are you sure to disable TSF mode? (On XP, intl.tsf.force_enable needs to be true for enabling TSF on XP and Server2k3)

Comment 4

[Alice0775 White]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #2)
> (In reply to Alice0775 White from comment #1)
> > Regression window:
> > https://hg.mozilla.org/integration/mozilla-inbound/
> > pushloghtml?fromchange=72744e6c31df&tochange=6dfb81107960
> > 
> > Regressed by: Bug 1186015
> 
> Are you sure?? The bug just renames the class names and cleaning up the
> logging code. So, nothing should have been changed.


Yes, re-checked and got same range.

Regression range m-c:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1f77b78797d6&tochange=ea320711a2e3

Regression range m-i:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=72744e6c31df&tochange=6dfb81107960



(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #3)
> Hmm, I cannot reproduce this bug on my WinXP (on VMware). Are you sure to
> disable TSF mode? (On XP, intl.tsf.force_enable needs to be true for
> enabling TSF on XP and Server2k3)

I tested new profile on WindowsXP Sp3 on VMWare Player (host win7).
I did not change any prefs.

Comment 5

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

Okay, I reproduced this bug when I uncheck "Extend support of advanced text services to all programs" or check "Turn off advanced text services".

Unfortunately, I'm working on other urgent bugs and I'll go TPAC next week. Kato-san, do you have a chance to check this?

Comment 6

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

FYI: I cannot reproduce the short hung up with other major Japanese IMEs.

Comment 7

[Alice0775 White]

Attachment: log (on Nightly44.0a1(2015-10-21) disable TSF and disable e10s)

set NSPR_LOG_MODULES=timestamp,nsTextStoreWidgets:5,nsIMM32HandlerWidgets:5
set NSPR_LOG_FILE=c:\log\ime.txt


steps
1. open testcase
2. click the textarea
3. type m o j i r a  ---  も is displayed now.
4. wait until all the text(もじら) is displayed.
5. pres ENTER to commit
6. quit browser

Comment 8

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

> 2015-10-22 10:32:01.093000 UTC - 0[362a000]: IMM: OnIMERequest, hWnd=003601c6, IMR_DOCUMENTFEED
> 2015-10-22 10:32:01.093000 UTC - 0[362a000]: IMM: HandleDocumentFeed, succeeded, result=32
> 2015-10-22 10:32:01.093000 UTC - 0[362a000]: IMM: OnIMERequest, hWnd=003601c6, IMR_DOCUMENTFEED
> 2015-10-22 10:32:01.093000 UTC - 0[362a000]: IMM: HandleDocumentFeed, SUCCEEDED, pReconv={ dwSize=32, dwVersion=0, dwStrLen=0, dwStrOffset=32, dwCompStrLen=1, dwCompStrOffset=4294967294, dwTargetStrLen=1, dwTargetStrOffset=4294967294, result str="" }, result=32

Here is the gap! So, replying IMR_DOCUMENTFEED causes hangs up in MS-IME.

> 2015-10-22 10:32:14.562000 UTC - 0[362a000]: IMM: OnKeyDownEvent, hWnd=003601c6, wParam=000000e5, lParam=00240001
> 2015-10-22 10:32:14.578000 UTC - 0[362a000]: IMM: OnFocusChange(aFocus=false, aWindow=eef1c00), sHasFocus=true
> 2015-10-22 10:32:14.578000 UTC - 0[362a000]: IMM: OnIMESetContext, hWnd=003601c6, Deactive, lParam=c000000f
> 2015-10-22 10:32:14.578000 UTC - 0[362a000]: IMM: OnIMESetContext, hWnd=0012f0e8 is top level window
> 2015-10-22 10:32:14.593000 UTC - 0[362a000]: IMM: OnIMENotify, hWnd=003601c6, IMN_CLOSESTATUSWINDOW
> 2015-10-22 10:32:14.593000 UTC - 0[362a000]: IMM: OnIMESetContext, hWnd=003601c6, Active, lParam=c000000f
> 2015-10-22 10:32:14.593000 UTC - 0[362a000]: IMM: OnIMESetContext, hWnd=0012ed90 is top level window
> 2015-10-22 10:32:14.593000 UTC - 0[362a000]: IMM: OnIMENotify, hWnd=003601c6, IMN_OPENSTATUSWINDOW
> 2015-10-22 10:32:14.625000 UTC - 0[362a000]: IMM: OnFocusChange(aFocus=true, aWindow=eef1c00), sHasFocus=false
> 2015-10-22 10:32:14.703000 UTC - 0[362a000]: IMM: OnIMEComposition, hWnd=003601c6, lParam=000001bf, mIsComposing=true, GCS_RESULTSTR=false, GCS_COMPSTR=true, GCS_COMPATTR=true, GCS_COMPCLAUSE=true, GCS_CURSORPOS=true,
> 2015-10-22 10:32:14.703000 UTC - 0[362a000]: IMM: HandleComposition, GCS_COMPSTR
> 2015-10-22 10:32:14.703000 UTC - 0[362a000]: IMM: GetCompositionString, succeeded, aCompositionString="もｊ"

Comment 9

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

Oh, this must be the cause!
https://hg.mozilla.org/integration/mozilla-inbound/rev/6dfb81107960#l1.2019

Comment 10

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

https://treeherder.mozilla.org/#/jobs?repo=try&revision=dea7f98cc02f

Comment 11

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

Attachment: Fix missing \n in IMMHandler::HandleDocumentFeed(), it was replaced to empty string accidentally

Comment 12

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

Comment on attachment 8677530 [details] [diff] [review]
Fix missing \n in IMMHandler::HandleDocumentFeed(), it was replaced to empty string accidentally

Okay, I confirmed that this mistake is the cause!

Comment 13

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/4d1821f242547fc64ff9417de0406bd1f36c0734
Bug 1217275 Fix missing \n in IMMHandler::HandleDocumentFeed(), it was replaced to empty string accidentally r=m_kato

Comment 14

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

Comment on attachment 8677530 [details] [diff] [review]
Fix missing \n in IMMHandler::HandleDocumentFeed(), it was replaced to empty string accidentally

Approval Request Comment
[Feature/regressing bug #]: bug 1186015
[User impact if declined]: Users of IME which uses IMR_DOCUMENTFEED (retrieving text around caret) and TSF-anware (even on Vista or later) see this bug or crash or something.
[Describe test coverage new/current, TreeHerder]: Tested manually on WinXP.
[Risks and why]: No risk because I replaced "\n" to "" in logging code of IMMHandler at working on bug 1186015. At this time, I took this simple mistake replacing "\n" of nsCString::RFind(). So, just backing out a part of the patch.
[String/UUID change made/needed]: Nothing.

Comment 15

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

Thank you, Alice-san, Kato-san for your contribution!

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/4d1821f24254

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Regression, crash, tracking.

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8677530 [details] [diff] [review]
Fix missing \n in IMMHandler::HandleDocumentFeed(), it was replaced to empty string accidentally

Recent regression, taking it but not happy to take such patch in rc... :(

Comment 19

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a507b89d922c
https://hg.mozilla.org/releases/mozilla-beta/rev/322adf3cdef3

Comment 20

[Ada [:adalucinet]]

Reproduced with Nightly from 2015-10-22 with STR via comment 0/comment 7; even a crash encountered - bp-e019f89e-01ff-4177-a022-80c0f2151027

Verified fixed with Firefox 42.0 RC (Build ID: 20151026170526), latest 43.0a2 and 44.0a1 (from 2015-10-26), under Windows XP 64-bit.