15496 - [PP][dogfood] IME bug-Japanese characters you are typing cannot be seen

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P2)

Description

[Teruko Kobayashi]

In the Editor, when you type Japanese characters at the beginning of the first
line, the character you type cannot be seen.

I am using the Wnn4 and Kinput2.

Steps of reproduce
1. Open the Editor by selecting the menu Task|Editor
2. Turn on the IME by Shift+Space
3. Move the cursor to at the beginnig of the first line, before "Here's the
deal.."
4. Type some Japanese

Notice that the Japanese characters you type are hidden.
After you hit the enter, the Japanese character will show up.

Tested 10-02 M10 Linux build.

Comment 1

[Teruko Kobayashi]

*** Bug 15531 has been marked as a duplicate of this bug. ***

Comment 2

[Erik van der Poel]

Tague, if I remember correctly, currently we only get the spot location back
from the editor(?) when some text has been committed. However, we need the spot
location in the beginning too, before any text has been typed. Do you have some
ideas for addressing this?

Comment 3

[tague]

I've actually changed that behavior to support XIM. Right now, you get the
cursor x,y coordinate back as a reply from generating the BeginComposition and
TextEvent messages.  The x,y coordinate is translated back into absolute
platform coordinates in the reply message.  You can use this initial value to
position the spot, which is how I've implemented candidate window position on
Windows.  Take a look at mozilla/widget/src/windows/nsWindow.cpp for an example
in the current architecture.

As far as future direction, I've been thinking of some kind of Input Method
manager service that would serve as a bridge between the platform-dependent and
cross platform editor code.  The IME service would have various "observers"
watch the state of IME-interesting data (cursor position, current font, focus)
and maintain a private context for each of the know editors.  This would also
allow us to use a single IC/TSMDocuemtns/HIMC for multiple editor widgets if
desired.

I can sketch out some ideas in the newsgroup if people are interested, XIM seems
to be the most demanding client, so if tajima-san has any particular ideas or
requirements, I'd love to get some feedback.

Comment 4

[Hidetoshi Tajima]

That is because the initial x, y location was not set to XIM. Thanks to Tague's
input,
Now the location can be got by dispatching a NS_COMPOSITION_START composing
event and examinng a reply field for the event. Hence, the fix will be to get
the location and
set to XIM when a document window gets an input focus at OnFocusInSignal() in
nsWidget.cpp.

Comment 5

[Frank Tang]

Mark as M11 P2.  Have you submit your fix to erik yet ?

Comment 6

[Erik van der Poel]

Toshi, if this bug has been fixed, please mark it RESOLVED FIXED. If it is a
duplicate of some other bug, please mark it RESOLVED DUPLICATE. If it has not
been fixed, and you don't think you can fix it for M11 (deadline is 11/2 at
11:59pm), then please change the Target Milestone to something after M11.

Comment 7

[bobj]

I looked at http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsWidget.cpp
and I don't see the change for dispatching NS_COMPOSITION_START and examining
the reply as suggested above.  So it looks like the fix has not been applied.

Should we move this to M12?

Comment 8

[chris hofmann]

m12.  let me know if a status change happens

Comment 9

[Hidetoshi Tajima]

*** Bug 15520 has been marked as a duplicate of this bug. ***

Comment 10

[Hidetoshi Tajima]

Here are the fixes to set initial spotlocation problem by looking at
ns_composition_start reply. The fix should solve 15520, too.
This changes are made on top of cvs checkout I ran at 12pm of 11/08/99. Thanks
to review and check-in if they work well and solve both 15520 and 15496.

Index: nsGtkEventHandler.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsGtkEventHandler.cpp,v
retrieving revision 1.113
diff -c -r1.113 nsGtkEventHandler.cpp
*** nsGtkEventHandler.cpp       1999/11/06 03:38:08     1.113
--- nsGtkEventHandler.cpp       1999/11/08 23:29:59
***************
*** 598,603 ****
--- 598,605 ----
    compEvent.compositionMessage = NS_COMPOSITION_START;
    aWin->DispatchEvent(&compEvent, *aStatus);

+   // set SpotLocation
+   aWin->SetXICSpotLocation(compEvent.theReply.mCursorPosition);
    return PR_TRUE;
  }

***************
*** 797,802 ****
--- 799,807 ----
      } else {
        InitKeyPressEvent(event,p, kevent);
        win->OnKey(kevent);
+       nsEventStatus status;
+       composition_start(event, win, &status);
+       composition_end(event, win, &status);
      }
    } else { // for Home/End/Up/Down/Left/Right/PageUp/PageDown key
      InitKeyPressEvent(event,p, kevent);
Index: nsWidget.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsWidget.cpp,v
retrieving revision 1.162
diff -c -r1.162 nsWidget.cpp
*** nsWidget.cpp        1999/11/06 03:38:20     1.162
--- nsWidget.cpp        1999/11/08 23:29:59
***************
*** 1972,1977 ****
--- 1972,1990 ----
      if (gdkWindow)
      {
        gdk_im_begin ((GdkIC*)mIC, gdkWindow);
+       // set spot location
+       nsCompositionEvent compEvent;
+       nsEventStatus status;
+       compEvent.widget = (nsWidget*)this;
+       compEvent.point.x = 0;
+       compEvent.point.y = 0;
+       compEvent.time = 0;
+       compEvent.message = NS_COMPOSITION_START;
+       compEvent.eventStructType = NS_COMPOSITION_START;
+       compEvent.compositionMessage = NS_COMPOSITION_START;
+       DispatchEvent(&compEvent, status);
+       // set SpotLocation
+       SetXICSpotLocation(compEvent.theReply.mCursorPosition);
      }
      else
      {

Comment 11

[Erik van der Poel]

I checked in the above fixes.

Comment 12

[Teruko Kobayashi]

I tested this in 11-18-08 M12 Linux build.  This still happen.
Reproduciable steps have been changed.

Steps of reproduce
1. Open the Editor by selecting the menu Task|Editor
2. Turn on the IME by Shift+Space
3. Move the cursor to at the beginnig of the first line
4. Type some Japanese
Notice that the Japanese characters you type are hidden.
After you hit the enter, the Japanese character will show up.

Bug 15520 still happens, too.  I need to reopen this.

Comment 13

[Erik van der Poel]

Toshi, please don't do any more work on this until we all agree on the right
approach. Frank has looked into supporting XIM's over-the-spot in Mozilla, but
it currently looks very difficult (font, spot location, color, etc). So please
wait until you get the go-ahead from Frank. Thanks.

Comment 14

[Teruko Kobayashi]

This still happens at the beginning of first line in Composer and at the beginning of Text area.  I tested 12-01-09 Linux build.

Comment 15

[Erik van der Poel]

I have a fix for this. (I set the initial Y coordinate to 14, since the font is
set to *-16-*.)

Comment 16

[Teruko Kobayashi]

I verified this in 120608 Linux build.