11994 - [IME/rule?Txn?][IME-InsertIMEText]IME-Cannot add spaces when turn on IME

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P2)

Description

[Teruko Kobayashi]

When you turn on IME to type Japanese character, the caret does not move
double byte for space bar.

Steps of reproduce
1. Open editor by selecting menu Task|Editor
2. Set the cursor on the editor to type Japanese characters
3. Turn on the IME by Ctrl+~ and change the Zenkaku Hiragana mode
4. Hit the Space bar several times
The caret moves the first single byte.  After that, it does not move at all.
Without IME, the caret moves fine.

Tested 8-16 Win32 build.  This works fine in Mac build.

Comment 1

[Frank Tang]

I think the non IME input replace the 2nd (and later) space into NBSP and we didn't do that in the IMETextTxn.

Comment 2

[daver]

PDT would like to know if only moving one byte forward corupts the data?
Do the spaces really show up in your sentenance anyway?

In html mail compose, the first space does not show up until you hit another
character, space or otherwise.

Comment 3

[msanz]

I cannot reproduce the bug now because IME is crashing in Editor as well (it
used to work in Win editor, now it doesn't). Can you put this bug on hold until
we can investigate more about it when IME is back and working? Teruko doesn't
remember the specifics of this bug in August.

Comment 4

[Joe Francis]

IME should be working now.  This bug does not happen on mac.  Is win IME using
regular space characters for ime input?  If it is we will need to take that into
account in the ime code (multiple spaces render as a single space in html).

Comment 5

[Frank Tang]

fix by joe. !!! :)

Comment 6

[Teruko Kobayashi]

I verified this in 10-28-08 Win32 build.

Comment 7

[Teruko Kobayashi]

I need to reopen this.  This happens in 120208 and 120315 Win32 build.

Steps of reproduce
1. Open Composer
2. Turn on IME
3. Hit the space bar
IME inserts the double byte spaces.

Comment 8

[leger]

Putting on pdt- radar.  bobj, please change to PDT+ if you feel differently.

Comment 9

[Teruko Kobayashi]

Correction of my previous comment.
IME does not insert double byte spaces.

Comment 10

[Frank Tang]

The spaces are actually insert into the content module. But the 2nd space make
the 1st space turn into nbsp - which implemented by HTML typing rule. This is
because last time we try to not to break IME text . joe could you do a special
case for a single ' ' in IME text and treat it as the normal space text ?

Comment 11

[rubydoo123]

moving to m13

Comment 12

[Joe Francis]

i've spoken with Frank about this and I know what's going on.  Will investigate
possible fix...

Comment 13

[rubydoo123]

removing dogfood and PDT-

Comment 14

[Joe Francis]

I have a possible fix for this which I will try out when I return in early
January.

Comment 15

[Joe Francis]

I sent this patch to Frank:

in nsHTMLEditRules.cpp, line 168, change it from:

if ((action == nsEditor::kOpInsertText) || (action ==
nsEditor::kOpDeleteSelection))

to:

if ((action == nsEditor::kOpInsertText) ||
    (action == nsEditor::kOpInsertIMEText) ||
    (action == nsEditor::kOpDeleteSelection))

Awaiting his feedback on the results...

Comment 16

[Joe Francis]

i checked in this fix.  Can someone verify for me?  I can't test it.

Comment 17

[Teruko Kobayashi]

I tested this in 2000011108 Win32 build.  Single space can be added when I turn on IME.
However, I found one problem.
When the spaces are added to the next line, the caret does not move one space bar (need to hit space bar twice) at
the beginning of the next line.

Steps of reproduce
1. Open Composer by selecting menu Task|Composer
2. Turn on the IME by Ctrl+~ and change the Zenkaku Hiragana mode
3. Hit the Space bar several times until go to the next line
The carret moves fine, but at the beginning of the next line, you need to hit space twice to move one carret.
I need to reopen this.

Comment 18

[Joe Francis]

this sounds like a different bug.  Am I right that you can now get multiple
spaces to show up (the original bug is fixed?).  If so, I'll move the new bug to
m14 - it doesn't sound as serious as the original problem.

Comment 19

[Teruko Kobayashi]

I logged the new problem in 23851.  I marked this bug as fixed.

Comment 20

[Teruko Kobayashi]

Verified in 2000011108 Win32 build