I tried today's nightly of 111403 and found Japanese IME (MSIME on Win2K) doesn't work at all. Now sure which check-in causes this problem, but I verified 1113 nightly worked well.
Sorry, "Now sure" -> "*Not* sure"
Changing severity to blocker. Does the fix for bug 107494 cause this bug?
I could reproduce this with 111403 trunk build on Win2k-J. Yoying, could you reproduce this on other Windows?
WinME-Ja has same result. Linux and Mac OS 10.1 work fine though.
I have 11/13 trunk build and I see the same problem. My local tree doesn't have the patch for bug 107494. Does 11/13 works for you guys?
On my Win2K, 2001111303 build works fine.
I don't think my patch to bug 107494 could cause this. Nonetheless, Roy let me know if you need me to come down and look at this with you.
seen on windows commercial build 2001-11-15-05-trunk reinstalling yesterdays smoketest build to confirm that I hadn't seen it yesterday per Roy's request.
I am on it.
IME Composition handling is done in widget\src\windows\nsWindow.cpp. There was a check-in on 11/14/2001 04:35 ccing firstname.lastname@example.org
Returned string 'mIMECompUnicode' from NS_IMM_GETCOMPOSITIONSTRINGW() is empty. 5188 NS_IMM_GETCOMPOSITIONSTRINGW(hIMEContext, 5189 GCS_COMPSTR, 5190 (LPVOID)mIMECompUnicode->get(), 5191 compStrLen, compStrLen); http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#5190 When I give a WCHAR string to NS_IMM_GETCOMPOSITIONSTRINGW(), it contains a correct text. jag: How does nsString change affect this?
ack, there was a typo.. I think that 2nd compStrLen should be compStrLen+1.. can you try that and see if it helps?
what used to happen before is that we'd call SetCapacity() and then look at the capacity member to see what our actual capacity is. mCapacity is now private, so we have to just assume that we got the minimum capacity. Unfortunately, we were off by one in the patch.
yokoyama is working on this one. Sheriff agreed to downgrade this bug. Loan
Created attachment 58024 [details] [diff] [review] missed by one byte and use of buflen Found two problem. 1) as jag comments, we were off by one 2) we shouldn't use compStrLen in NS_IMM_GETCOMPOSITIONSTRING() as in and out param. NS_IMM_GETCOMPOSITIONSTRING macro always set out param to 0 ftang: can you review?
Comment on attachment 58024 [details] [diff] [review] missed by one byte and use of buflen got /r=ftang.
alecf,jag: can you /sr=?
Comment on attachment 58024 [details] [diff] [review] missed by one byte and use of buflen sr=alecf
verified on windows commercial build 2001-11-16-05-trunk