53072 - IME candidate window position problem

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[Teruko Kobayashi]

IME candidate window position is not right when you type Japanese characters at 
the bottom of the Composer window.

Steps of reproduce
1. Open Composer
2. Turn on IME
3. Move the cursor to the little below the middle of the Composer window
4. Type hiragana character, like "にほん"
5. Hit space twice to open Candidate window

Look at the position of the Candidate Window. It opens at the top of the 
Composer window not the place of the Japanese characters are typed.

If you type Japanese characters at the beginning of the Composer window, the
candidate window will open just below the characters are typed.

This does not happen in PR2.  I can reproduce this in 2000-09-18-08 Mac and
2000-09-18-05 Win32 build.  I can reproduce this in 2000-08-29-08 Win32 build.

IME candidate window does not open just below the characters in linux.

Comment 1

[Teruko Kobayashi]

Nominating this for nsbeta3.

Comment 2

[nhottanscp]

Is this same as bug 53025?
[IME] preedit string remains on focus change

Comment 3

[Shanjian Li]

This problem also cause bug 52206. Since over-the-spot is the only thing 
available for HPUX, the importance of this bug should be further raised.

Comment 4

[Shanjian Li]

The problem seems exist in file nsCaret.cpp. A proposed fix:
Index: nsCaret.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/base/src/nsCaret.cpp,v
retrieving revision 1.61
diff -c -r1.61 nsCaret.cpp
*** nsCaret.cpp 2000/09/14 11:44:46     1.61
--- nsCaret.cpp 2000/09/18 20:58:00
***************
*** 604,610 ****
    {
      // window-relative coordinates (walk right to the top of the view 
hierarchy)
      // we don't do anything with clipping here
!
      do {
        theView->GetPosition(&x, &y);

--- 604,611 ----
    {
      // window-relative coordinates (walk right to the top of the view 
hierarchy)
      // we don't do anything with clipping here
!     viewOffset = withinViewOffset;
!
      do {
        theView->GetPosition(&x, &y);

Comment 5

[Simon Fraser [no longer active]]

The fix looks good. Sorry, I didn't realise that this routine was being called 
from IME code.

Comment 6

[Frank Tang]

roy, can you verify this patch on window ?

Comment 7

[Shanjian Li]

I tried it on windows already. 

Comment 8

[Frank Tang]

nsbeta3+ . check it in.

Comment 9

[Shanjian Li]

fix checked in.

Comment 10

[Teruko Kobayashi]

I verified this in 2000-09-20-05 Win32 build.  I need to verify this in Mac build, but I cannot launch today's mac build.  

Comment 11

[Teruko Kobayashi]

I see the some problem in Mac build, but it was not Netscape problem.  It is
system problem.  I verified this as fixed.

Comment 12

[Shanjian Li]

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

Comment 13

[Masaki Katakai]

I found this problem still exist on some widgets, e.g.

 - To: field of Mail Composer window
 - All text fields on New Card dialog of Address book

Try to invoke candidate window of IME, the position is not
correct on Windows platform. On Linux, the pre-edit position
is not correct when the input style is over-the-spot.

Please re-open this bug report or I need new one.

Comment 14

[Teruko Kobayashi]

I logged new bug about To: field and New card address book in 59405.

Comment 15

[Shanjian Li]

Base on my preliminary observation, the problem is a different issue from 
this one. Most likely, the problem exist in the same function, 
nsCaret::GetViewForRendering. I think we 'd better open a new bug. Katakai,
thanks for your great job. I will assign the new bug to you.

Comment 16

[Katsuhiko Momoi]

Is this problem really fixed when the cursor is toward the end of
a composer window? In that case, the candidate window comes above
the line but in Mozilla (11/7/2000 Win32 build), it covers the
line and therefore you cannot see the line you're editing.
In other applications like Wordpad, you see the line you're editing.

Comment 17

[Katsuhiko Momoi]

Rather than re-opening this bug, I filed a new bug, Bug 59924
for the same problem when the candidate window is placed above
the current line of editing.