Closed Bug 53025 Opened 24 years ago Closed 23 years ago

[IME] preedit string remains on focus change

Categories

(Core :: Internationalization, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: tee, Assigned: masaki.katakai)

References

()

Details

(Keywords: inputmethod, intl, Whiteboard: ??????)

1.Use IME which supports on-the-spot-style.
2.Open a page with many textfields.
 (for example this bugzilla page.)
3.Enable IME and type something.
4.Change input focus before commit the text.
    -> then the preedit string ramains in previous textfield.
BUILD is 2000091721
Turbo Linux 6.0
kinput2 v3.0

I also saw this bug in recent windows build.
IQA please test if this is reproducible.
Reassign to tajima san.
IQA, is this reproducible?
Assignee: nhotta → tajima
Can anyone confirm this?
Confirmed the problem with 2000110616-mn6 build.
URL: ???
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: ??????
Keywords: intl
Changed QA contact to ylong@netscape.com.
QA Contact: teruko → ylong
Ftang - Please triage, and determine target milestone.

Yuying - How important is this for you, as an IME customer.
I can reproduce this on both Linux and Mac on 04-25 trunk build.
For my point of view, it is bad but not show-stopper.  I had another bug 77632 
is talking about similar issue on Windows, I think we should fix that one first?
It's existing on WinME-Ja too.
Ftang - Pls assign M0.9.2
Keywords: rtm
I think editor/base/nsTextEditorFocusLister::Blur() needs to call
nsIEditorIMESupport::ForceCompositionEnd().
+ nsCOMPtr<nsIEditorIMESupport> imeEditor = do_QueryInterface(mEditor);
+ if (imeEditor) mEditor->ForceCompositionEnd();

But this does not fix the problem, because ForceCompositionEnd() does
not remove preedit strings. This can cause other bug.
For exapmple, we can save a document with preedit string by HTML editor.
reassign
Assignee: tajima → katakai
Tabata-san is correct. Editor should call ForceCompositionEnd()
before the input focus is moved to other. IME has to know the
input focus is leaving. IME in each platform (gtk/, windows/, mac/)
should handle this event properly in ResetInputState().
I undersand deleting existing preedit should be handled by
IME in the method.

ResetInputState() should do,

 - Reset (Delete) preedit if exists
 - commit existing preedit if exists
 - call NS_COMPOSITION_END to close the composition

On Linux, only adding the codes into Editor can solve 90% of
this problem. Some code changes will be needed around
ResetInputState().

I'll ask Editor folks whether the changes in Editor module
is corret. Then, I'll file separate bug for each platform
toolkit. I'll take Linux part. Any suggestion?

filed bug against Editor, bug 81356.
Depends on: 81356
filed linux (gtk) problem separately in bug 81360 and
assigned to myself.
Depends on: 81360
Depends on: 81365
Depends on: 81364
I've filed separate bug 81364 and bug 81365 for Windows and Mac.
Can anyone try the patch in bug 81356 on your platform? If it
works and the editor bug is fixed, you can mark them as WORKSFORME.

I've checked on gtk and found some problems.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
Editor side (bug 81356) is OK, patch is ready. But gtk has
a problem as bug 81360.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla1.0
Editor side (bug 81356) has been checked in. 
I've verified the fix on Windows and Linux on 1118 nightlies.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I tried it on 11-19 trunk build / RH7.1-Ja:
1. Open a page that have textfields - e.g. this bug report page.
2. Enable IME and type some "kana" in a text field- don't commit it yet.
3. Move the mouse cursor to another text field.

Result:
The string in step 2 has gone.

Do we expect that string get commit by doing the above steps?
Hi Yuying,

I think you're using canna (default) and I belive this is correct behavior
because canna does not return committed string by XmbResetIC(). Some IMEs
don't have this feature and there is no way to get committed string.
I think wnn has this feature.
Thanks, Katakai-san!

Yes, I was using canna.  But I still have a question here:
If I turn on kinput2 before launch netscape ( got a warning mes_id=207: message
not found), then following the steps as before, e.g. if I typed "kann" will
display as "かんn" - very strenge, a extra "n" at the end, the string is no
hightlighted, and if I press space key, no candidate window pops-up, I can not
delete it neither with this stage.

Is this a seperate problem?

I can reproduce the same problem with 2001112508/Win98.

Koike-san, can you file new separate bug ?
Bug 115848 has been filed against the last problem. 

Mark this one as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.