34156 - Inconsistent Enter key event handling with CJK text input

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P3)

Description

[blee]

For CJK text input, hitting Enter usually just commits the input to the apps 
after the text is typed in via an IME. 
Following this convention, hitting Enter after typing CJK char's in location 
field should just commit the input and hitting it again should invoke KW server 
URL to be loaded.
Currently, when Enter is depressed after text input via an IME, it commits the 
input and invoke KW URL at the same time, and this is inconsistent with how 
other apps accept CJK text input.

The same behavior is observed in Win(03-22-06-M15b1) and Mac(03-23-07-M15b1) 
blds. Linux bld exhibits the opposite behavior (bug 33990).

Comment 1

[Frank Tang]

The reason it behavie like this is because the key handler of the URL bar track 
the of the keyup of 13 while it really should track the key pressed of the CR. 
mozilla/xpfe/browser/resources/content/navigator.xul
351 hangas    1.105              <html:input id="urlbar" type="text" 
chromeclass="location" 
352                                 onkeyup="if (event.which == 13) { 
BrowserLoadURL(); }" 
353                                 flex = "100%" /> 
354                   
Notice it is tracking the onkeyup, not the onkeypressed. It should track the 
onkeypressed instead. 

The cvsblame show hangas . reassign to hangas  and cc matt.

Comment 2

[hangas]

Looks like a leftover from the old days when some of these key handlers did not 
work.  No problem, this will get changed.

Comment 3

[hangas]

Bumping to M17.

Comment 4

[msanz]

marking nsbeta2

Comment 5

[hangas]

Fix checked in.  Since a request was made for nsbeta2 and ftang was kind enough 
to include the fix, I moved this from M17 to M16 and checked it in.

Comment 6

[blee]

Verified fixed in Win 04-23-16-M16 and Mac 04-24-10-M16 blds.

Comment 7

[blee]

Reopening as the problem hasn't been fixed for KO IME - fixed for JA IME.

Comment 8

[hangas]

Please help me understand what was meant by the comment: "Reopening as the 
problem hasn't been fixed for KO IME - fixed for JA IME."  
What is the problem?  What is "KO"?  What is "IME"?  And, what is "JA"?  FTang 
descibed the fix as switching onkeyup to onkeypress, this has been done.  Since I 
do not work with CJK text input I will need some help understanding the real 
problem so that we can find this bug a good home.

Comment 9

[blee]

The problem is fixed for Japanese Input Method Editor. When tried on Korean, 
however, the problem still happens as described originally.

Comment 10

[bobj]

ftang,
   I don't understand why tracking onkeypressed instead of onkeyup should fix
***this*** bug (it may be another problem).  Shouldn't the Input Method Editor
(IME) code swallow the Enter key event for the IME commit instead of passing
the event onto the location bar?  

Comment 11

[blee]

The problem still happens in Sidebar Search input field with both JA and KO 
IME in Win 04-27-09 bld.

Comment 12

[hangas]

This bug is really outside of my area.  If there is a problem with sidebar 
search, then I suggest a bug to slamm.  If there is a problem with only KO then I 
suggest a bug to localization or event handling or maybe text input (editor).  
Ftang assigned this bug to me because the "fix" was in a line that I had once 
modified.  Please reassign this bug to a more appropriate owner.

Comment 13

[blee]

reassigned to ftang for now.

Comment 14

[Frank Tang]

I think hangus did fix the problem. The reason the Korean IME fire the URL is 
because in Korean IME the return key mean commit + return. Blee and I look at it 
together and we thing it is fair to say this bug is fixed. Usually, when Korean 
uesr type in text document and hit a return key, it does commit + adding an 
return (new line). So Korean user should expect this will fire the URL. If the 
user do not want to fire the url, they will hit space or esc key instead.

Comment 15

[blee]

Verified