110170 - Win: IME doesn't work at all on 111403 build

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Masaki Katakai]

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.

Comment 1

[Masaki Katakai]

Sorry,

"Now sure" -> "*Not* sure"

Comment 2

[Koike Kazuhiko]

Changing severity to blocker.

Does the fix for bug 107494 cause this bug?

Comment 3

[Teruko Kobayashi]

I could reproduce this with 111403 trunk build on Win2k-J.  

Yoying, could you reproduce this on other Windows?

Comment 4

[Yuying Long]

WinME-Ja has same result.

Linux and Mac OS 10.1 work fine though.

Comment 5

[Roy Yokoyama]

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?

Comment 6

[Masaki Katakai]

On my Win2K, 2001111303 build works fine.

Comment 7

[Joe Francis]

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.  

Comment 8

[Tracy Walker [:tracy]]

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.

Comment 9

[Roy Yokoyama]

I am on it.

Comment 10

[Roy Yokoyama]

IME Composition handling is done in widget\src\windows\nsWindow.cpp.
There was a check-in on 11/14/2001 04:35

ccing  [e-mail]

Comment 11

[Roy Yokoyama]

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?

Comment 12

[Alec Flett]

ack, there was a typo.. I think that 2nd compStrLen should be compStrLen+1.. 
can you try that and see if it helps?

Comment 13

[Alec Flett]

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.

Comment 14

[lpham]

yokoyama is working on this one.  Sheriff agreed to downgrade this bug.

Loan

Comment 15

[Roy Yokoyama]

Attachment: 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 16

[Roy Yokoyama]

Comment on attachment 58024 [details] [diff] [review]
missed by one byte and use of buflen

got /r=ftang.

Comment 17

[Roy Yokoyama]

alecf,jag: can you /sr=?

Comment 18

[Alec Flett]

Comment on attachment 58024 [details] [diff] [review]
missed by one byte and use of buflen

sr=alecf

Comment 19

[Roy Yokoyama]

checked in

Comment 20

[Tracy Walker [:tracy]]

verified on windows commercial build 2001-11-16-05-trunk