Closed Bug 1217275 Opened 4 years ago Closed 4 years ago

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

Categories

(Core :: Widget: Win32, defect, blocker)

42 Branch
Unspecified
Windows XP
defect
Not set
blocker

Tracking

()

VERIFIED FIXED
mozilla44
Tracking Status
firefox41 --- unaffected
firefox42 + verified
firefox43 + verified
firefox44 + verified
firefox-esr38 --- unaffected

People

(Reporter: alice0775, Assigned: masayuki)

References

()

Details

(Keywords: inputmethod, jp-critical, regression)

Attachments

(2 files)

[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:
もじら
Flags: needinfo?(masayuki)
(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.
Flags: needinfo?(masayuki)
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)
(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.
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?
Flags: needinfo?(m_kato)
FYI: I cannot reproduce the short hung up with other major Japanese IMEs.
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
> 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="もj"
Oh, this must be the cause!
https://hg.mozilla.org/integration/mozilla-inbound/rev/6dfb81107960#l1.2019
Flags: needinfo?(m_kato)
Summary: Cannot type text using Microsoft IME on WindowsXP SP3 → [IME] MS-IME for Japanese on WinXP SP3 hangs up at inputting first Kana character
Summary: [IME] MS-IME for Japanese on WinXP SP3 hangs up at inputting first Kana character → [IMM] MS-IME for Japanese on WinXP SP3 hangs up at inputting first Kana character
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!
Attachment #8677530 - Flags: review?(m_kato)
Attachment #8677530 - Flags: review?(m_kato) → review+
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.
Attachment #8677530 - Flags: approval-mozilla-beta?
Attachment #8677530 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/4d1821f24254
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
Regression, crash, tracking.
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... :(
Attachment #8677530 - Flags: approval-mozilla-beta?
Attachment #8677530 - Flags: approval-mozilla-beta+
Attachment #8677530 - Flags: approval-mozilla-aurora?
Attachment #8677530 - Flags: approval-mozilla-aurora+
Flags: qe-verify+
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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.