60050 - Can't enter text in hankaku-input/non-conversion mode

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[Koike Kazuhiko]

Can't enter text in hankaku-input/non-conversion mode.

(1) Set input mode of IME to 'hankaku-eisuuji' and conversion mode to 'muhenkan'.
(2) Can' enter text in input field or composer.

This problem was reported on Japanese Bugzilla.
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=429

Comment 1

[nhottanscp]

I can reproduce this on Windows 2000.
Roy, please take a look at this.

Comment 2

[Makoto Kato [:m_kato]]

WM_IME_COMPOSITION seems to be send since WM_IME_STARTCOMPOSITION isn't send...

Comment 3

[Makoto Kato [:m_kato]]

Attachment: fix code

Comment 4

[Roy Yokoyama]

Shouldn't we allocate these memories in nsWindow::nsWindow()
since they are deleted/recycled in nsWindow::~nsWindow()?
We rely on allocating these memories upon receiving the
nsWindow::HandleStartComposition(); but Windows does not
send the WM_IME_STARTCOMPOSITION msg in hankaku-input/non-conversion
 mode.  You never know what other combinations we may need to support
in the future.  By moving the allocation code to the constructor
will eliminate this problem.  What do you guys think?

Comment 5

[Makoto Kato [:m_kato]]

If users do not need IME, WM_IME_* messages is not send.  So when first message 
is send, IME's memory should allocate.
Why WM_IME_STARTCOMPOSITION is not send, I don't know.  But if this is MS-IME's 
bug, workaround codes will need.
And ATOK13 seems to send this message when non-conversion mode.

Comment 6

[Roy Yokoyama]

Attachment: Move the allocations to nsWindow::nsWindow()

Comment 7

[Shanjian Li]

Among all windows instance used inside browser, only a very small number of 
windows need to handle input. The ones that need to handle IME is even less.
I was comfortable with kato's fix. If we can not think of any situation where
his fix is not enough, I would like to avoid moving it to constructor. 

Comment 8

[Roy Yokoyama]

Hummm... I need little clarifcation.
Why do we even checking for nsnulls for mIMECompString and mIMECompUnicode at
the first place?
I see
if (!mIMEIsComposing)
  HandleStartComposition(hIMEContext);
everywhere before accessing these strings in the execution path.
Can we simply remove the check for nsnulls and replace it with
HandlStartComposition(hIMEContext) call?

Comment 9

[Makoto Kato [:m_kato]]

Roy, If the codes remove, it will crash!!!
Does you think the users which not use IME???

Shanjian, please review my patch.  I want to check in with bug 55256

Comment 10

[Roy Yokoyama]

Very strange.  I have removed the code and tested before I put my previous
comments. It worked fine on my W2K-J.   I hope I didn't offend you by simply
trying to identify the best course of action.    Shanjian, please review
Kato-san's patch. :)

Comment 11

[Shanjian Li]

Kato,
I talked with roy today, and we agreed on your fix. You might need to get 
it super-reviewed before your can checkin. That is a process netscape 
set up for after 6.0 development.

Comment 12

[Simon Fraser [no longer active]]

This isn't really mode code, or my platform. But...

Index: src/windows/nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/windows/nsWindow.cpp,v
retrieving revision 3.303
diff -c -r3.303 nsWindow.cpp
*** nsWindow.cpp        2000/12/09 07:28:14     3.303
--- nsWindow.cpp        2000/12/09 20:34:51
***************
*** 4468,4473 ****
--- 4592,4611 ----
  #ifdef DEBUG_IME
        printf("OnIMEComposition\n");
  #endif
+ 
+   // for bug #60050
+   // MS-IME 95/97/2000 may send WM_IME_COMPOSITION with non-conversion mode
+   // before it send WM_IME_STARTCOMPOSITION.
+ 
+   if (mIMEIsComposing != PR_TRUE)

Ugh. if (!mIMEIsComposing) or if (mIMEIsComposing == PR_FALSE) please.

+   {
+     if(!mIMECompString)
+       mIMECompString = new nsCAutoString();
+ 
+     if(!mIMECompUnicode)
+       mIMECompUnicode = new nsAutoString();

Auto strings were not designed to be allocated on the heap. Why not just
use a member varibable nsString, and changes its contents, instead of
allocating a new object?

Comment 13

[nhottanscp]

>mIMECompString = new nsCAutoString();
This is not specific to this patch (in nsWindow.h, nsCString*  mIMECompString).
Cc to Frank, is this for optimization?

Comment 14

[Makoto Kato [:m_kato]]

hotta-san, I think that it should convert from nsCAutoString / nsAutoString to 
char* / PRUnichar* for few performance and memory usage.  Please open new bug.  
If frank have no enough time, please assign to me.

Comment 15

[Roy Yokoyama]

ftang using yokoyama's account
sr=ftang
The Auto string issue is a sepeate one. I agree that we should consistently use
the same class here as the patch. As for the reason why we use the
nsCAutoString/nsAutoString instead of nsCString/nsString: The reason is usually
the size of the composition string is limited (by the nature of the user) within
5 characters for Chinese + Korean and less than ~15 characters for Japanese.
Therefore, using nsCAutoString and nsString here save one malloc for the buffer
allocation.

Comment 16

[Makoto Kato [:m_kato]]

Who is check in?
If I should check in, please reply (because this case is assigned to roy)...

Comment 17

[Roy Yokoyama]

I asked Frank to /sr= your code.  I am assigning to you, Kato-san.

Comment 18

[Makoto Kato [:m_kato]]

check in

Comment 19

[Teruko Kobayashi]

I verified this in 2001012205 Mtrunk Win32 build with WinNT 4.0J, Windows 2000J, Win98J, and Win95J.