5527 - Editor is not able to accumulate successive Japanese input

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Katsuhiko Momoi]

** Observed with 4/26/99 Win32 build **

Hopefully this problem has been filed already but it shows up also
in composing new mail messages.

1. Using Windows-Japanese IME (Input Method module), input
   Japanese into a composer window (mail or general editor).
2. Commit the first input strings by pressing "Enter" key.
3. Now start the new set of input using a Japanese IME.
4. Note that the 2nd set of strings are now replacing the 1st
  set of string instead of being appended to the 1st string.

Given this behavior, there is no way to retain anything other
than the current input string set. It seems that the insertion point
cursor gets reset to the beginning every time the Japanese IME
input string is committed instead of retaining the last character
position so that the next input set can be added after that
position.

Comment 1

[bobj]

IME is not really ready yet for IQA.
This is an architectural problem that kin and tague are trying
to resolve by M5.

Comment 2

[Katsuhiko Momoi]

I take bobj's comment to mean that we won't be committing to
Japanese mail-send feature for M5 except in a very primitive way.

Currently, copy/paste doesn't seem to be working into mail body
for Japanese strings, header cannot take IME input, and so they and
this bug leave only one kind of input possible, i.e. a few words
which can be entered via IME in the first set of input.
I guess we are now looking at very scaled-down enabling of
Japanese mail-send for M5?

There is also a blocking bug 5525 for Japanese mail-send.

Comment 3

[Greg Kostello]

Tague: please determine if anything else is required on the part of the editor
team.

Comment 4

[leger]

Adding to QA Blocker radar.

Comment 5

[tague]

I looked at Japanese mail today -- finishing up the enabling work is only going
to allow you to type in the mail textbody, you won't be able to type in the
headers or subject line.  all of the non body fields are implemented with native
text widgets and don't have IME support.

Comment 6

[sujay]

Momoi, can you please assign yourself as the qa_contact? I won't be
able to regress this type of bug...thanks!

Comment 7

[Teruko Kobayashi]

Changed QA contact to [e-mail]

Comment 8

[bobj]

Non-body text fields are using HTML forms.  HTML forms have not yet switched
to Ender and will not be I18N enabled until they're Ender-based.  That part
is M6, but the body part is M5.

Comment 9

[tague]

checked in a fix today with chofmann's approval.

Comment 10

[Teruko Kobayashi]

I verified this in 6-17-08 build.