38342 - CR to commit Japanese IME candidate is treated as if it is a regular CR affecting Mail addressing

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[Katsuhiko Momoi]

** Observed with 5/5/2000 Win32 build **

1. Place Japanese IME cursor into new Mail Composer's address field.
2. Type a few characters which will match a nickname entry in the Collected or Personal Address Book.
3. Now commit the pressing "Enter" key.
4. The caret moves to the next header field. 
5. The above problem prevents the user from doing 2 additional things:
    a. to continue to input additional chaarcters in the same header field.
    b. prevents auto-completion from  to functioning properly.

Comment 1

[Katsuhiko Momoi]

These 2 are serious problems for Japanese mail. 
NOminating for beta 2.

Comment 2

[Katsuhiko Momoi]

I've looked through other bugs similar to this one and it seems that there might be some 
relationship between this bug and Bug 35356. 
I can tell, however, this is a serious problem and needs to be fixed before Beta 2. 

An action to commit a candidate string with IME should not be treated like CR. 
When the user presses CR after the candiadte has been committed, that is when
 it should act like a CR. 

You can observe the same problem in the Sidebar search field. 
There, too, if you try to commit a string, it will both commit and
start the search. This prevents you from enterign additional words before
serach begins.
A must fix for both Mail addressing/auto-completion and sidebar search.

Looks like the same problem is not observed in Navigation Location field or Form input field.
Sending it [e-mail] intially. Maybe this belongs to jfrancis?

Comment 3

[Frank Tang]

no this is a problem with listening CR on keyup or keydown when it should really 
listen of keypress. When we operate in IME, we still send keyup keydown for each 
key we press, but we only send keypress for the CHARACTER we enter. We need to 
press ENTER in the mid of IME operation so keyup keydown will receive keycode 
13. The correct way is to listent to keypress which gurantee it will only 
receive 13 when it is not part of the IME operation.

See bug 38319. I actually have already mention this problem when I try to find 
the fix for bug 38319. 

you should check the if (event.which == 13) also in keypress but not keyup. The 
reason is IME may hit enter as intermediate process of typing a Japanese, in 
that case, it will generate keyup/keydown 13 but not keypress 13.

Also, probably we should also fix 
mailnews/compose/resources/content/addressingWidgetOverlay.xul

 71                                                                                         
onkeyup="if (event.which == 13) awReturnHit(this);"
 72                                                                                         
onkeydown="if (event.which == 9) {awTabFromRecipient(this, event);}"

I think both should be in keypress but not keyup/keydown

reassign to ducarroz

Comment 4

[Frank Tang]

This problem is not INSIDE IME code and are caused by misused of keyup/keydown 
in different places. Therefore, please limit the scope of this bug to the mail 
addressing issue. The mail subject issue have already been track under 38319.
I will ask momoi to file seperate bug for the sidebar search.

Comment 5

[Katsuhiko Momoi]

The Sidebar search problem has been filed as Bug 38545.
Ccorrecting the summary line accordingly.

Comment 6

[leger]

Putting on [nsbeta2+] radar for beta2 fix.

Comment 7

[Jean-Francois Ducarroz]

Fixed and checked in

Comment 8

[Katsuhiko Momoi]

** Checked with 5/10/2000 Win32 build **

We have a new regression with this build -- this was not seen with 5/9/2000 Win32 build.

Problem: When I turn on Japanese IME and beign to input, I'm supposed to be able "build" a candidate
             string until I decide I like the input entry, and then press "CR" to commit the candidate string
             into a text widget. When I try to input into Addressing field, I now "commit" immediately
              without creating a candidate string (with undelines). This is a very serrious regression.
             Now I get auto-completion the moment I input 1 character without pressing the CR.
 
Re-opening....

Comment 9

[Jean-Francois Ducarroz]

Momoi, can I come to see you tomorrow. I need to do some test on a japaneese 
machine

Comment 10

[selmer (gone)]

Mass moving M16 to M17 - look for nsbeta2 before anything else.

Comment 11

[Frank Tang]

momoi, we are shifting the scope of this bug now. What you report is a seperate 
problem without involving the CR key. Please open a new bug for that. The scope 
of this bug is we do extra action IF the CR get pressed. From your description , 
it seems a valid bug but different bug. And that bug blocking you to test the 
fix of this one. Am I right ? If so, please file a seperate bug against that and 
mark this bug depend on that. (Which is really the verification depend on that 
but not the fix depend on that.)

Comment 12

[Katsuhiko Momoi]

As per ftang's last comment, I created a new bug to deal with 
the problem I mentioned above.

Comment 13

[Katsuhiko Momoi]

Since there is now a bug to deal with the problem mentioned
above, I'm resolving this bug as fixed.

Comment 14

[Katsuhiko Momoi]

** Checked with 6/27/2000 Win32 build **

Now hitting the CR before the candidate string is committed no longer
moves the caret to the next line.
Marking it verified fixed.