User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 Firefox returns 229 key code in one onKeyDown event when the first letter is typed via Korean IME, but it doesn't pass any other events after that. Some set of JavaScript events should be available to indicate that user input is occurring for each keystroke. Reproducible: Always

I cannot understand what you said. Please add the comment for more detail. And if you can, please attach a simple test case and write the steps for the testing.

Key typing event on korean are not caputured in Firefox.

This sample is for above capture.

This problem has been well known in korean web developers. But, they didn't file a bug yet in bugzilla. Firefox returns 229 key code in onKeyDown event in typing korean characters, and it doesn't do any event on typing after that. So they use a code when it catches 229 code or all events, it always send to all charaters in input box with setTimeOut(). I know this is trick. Google suggest in japanese uses same trick. http://www.google.co.jp/webhp?complete=1&hl=ja. Anyway similiar Bug 338585 by me.

I forgot this bug, sorry. We don't send any key events in composing with IME. On Mac and Linux, the composing transaction may be separated between characters. However, on Windows, may not be so. I think that the behavior depends on the IME. http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindow.cpp#4457 If we send keydown/keyup events at that time, there may be too big impact for XUL apps (including Fx) and Web apps.

(In reply to comment #7) > If we send keydown/keyup events at that time, there may be too big impact for > XUL apps (including Fx) and Web apps. This has been discussed @ W3C webapi (now webapps) mailing list and during DOM 3 Events conference calls - but so far no resolution. IE and Safari do dispatch keyup/down while composing IME, Opera doesn't dispatch anything and Gecko - depending on the IME, I assume - dispatch 'text' events while composing. Personally I prefer the way Gecko does it on Windows with MS IME Standard 2002 in the simple testcase I used in http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0034.html

Smaug- thank you for the update. Who is best to handle this bug longer-term?

Smaug: Thank you for the information, I think web browsers should not fire any key events during composing, but HTML5 should have a new event handler, e.g., "oncomposing". Because web apps cannot know the key events fired during composing.

As you know, one Hangul character(syllable) is composed with several phonemes. ( 참 => ㅊ ㅏ ㅁ) On Mac and Linux, key events are fired in every phoneme, but MS IME doesn't fire any key events when even a syllable is composed. Only if the user inputs space or period in during composing, key event could be fired. I think that key event should be fired when a syllable is composed. How could we know the length of string during typing Hangul on Windows?

(In reply to comment #11) > On Mac and Linux, key events are fired in every phoneme, Really?? Isn't that fired every *syllable*?? I think that it should not be so in current our design. See the current code: Cocoa: http://mxr.mozilla.org/mozilla-central/source/widget/src/cocoa/nsChildView.mm#4649 Gtk2: http://mxr.mozilla.org/mozilla-central/source/widget/src/gtk2/nsWindow.cpp#2335 If there is a composition string of IME, looks like we don't send any key events. > How could we know the length of string during typing Hangul on Windows? Web developers cannot get the composing character. Because the state of the character is "inputting", not "inputted". Should we implement textInput event of DOM3 for handling? http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-textInput

(In reply to comment #12) > Should we implement textInput event of DOM3 for handling? > http://www.w3.org/TR/DOM-Level-3-Events/events.html#event-textInput Yes we should, once DOM 3 Events is stabilized a bit.

Masayuki, In the context of your comment on bug 491819 > I guess that you want to know the timing of updating the IME composition > string. If so, this is dup of bug 354358. > I think that the composition string may be updated without keyboards, > e.g., the inputting trigger might be sound inputting device. And also > some IME frameworks may eat the key events during composition. But the > IME composition string updating can be handled all situations. > Therefore, DOM3 or HTML5 should define a new event which is IME > composition string updating event. I believe that the way is better. Totally agree - another example being using the mouse to select a Japanese character from the popup not generating any key event. Also, unrelated to IME, I believe Mac OSX allows users to define combos that will do arbitrary changes to text - not sure if Firefox supports this feature or not. Therefore we need some kind of event to let us know the browser intends to modify the DOM in some way, before it happens. In practice however, at least if we still get events for actual key strokes, that would cover 98% of the use cases, so perhaps it is worth preserving those for the time being?

Sorry for my poor english. In korean language, Firefox key event is the huge problem with MS IME. One character has vowel and consonant. Usually one character needs two or three times keypress. Moreover, Although it has many characters, it doesn’t fire to all of any korean characters until i reached at latin character and special keys. Opera is the same as firefox. but safari, chrome and MSIE works well. I can’t use autocomplete in wikipedia with firefox at all.

So the current DOM 3 Events draft has now compositionstart/update/end events. Those are pretty close to what gecko has now, though gecko has events calls compositionstart/text/compositionend. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-compositionevents We should probably add support for compositionupdate, but still support 'text' event for backward compatibility. And we should also add missing features of the other composition events. Anyway, does Gecko not dispatch compositionstart/text/compositionend events with Korean IME? That would be a bug. (Not dispatching key events during composition isn't a bug.)

(In reply to comment #16) > calls s/calls/called So when testing this, which IME should I be using on Windows XP?

(In reply to comment #17) > (In reply to comment #16) > > calls > s/calls/called > > So when testing this, which IME should I be using on Windows XP? I'm not sure the English interface of WinXP. But I think you can look only one Korean keyboard layout in the dropdown list which chooses an additional keyboard layout. Perhaps, you can test with it.

I just have written blog entry for testing key event in KO IME. http://ddinguri.blogspot.com/2009/12/using-korean-ime-in-windows-xp.html

So seems like Korean IME on Windows XP does generate 'compositionstart', 'text' and 'compositionend' events. One could also use non-standard (but supported by many browsers) input event. http://mozilla.pettay.fi/moztests/key_event_test.html Based on DOM 3 Events (draft), web apps which want to handle IME input, shouldn't rely on key events, but use composition events. Or use 'textInput' event, which Gecko doesn't support yet. But we do have 'input' event.

I just typed "나무(skan)". ㄴ(s) : 1 ~ 4 나(sk) : 5 (text) 남(ska) : 6 (text) 나무(skan) : 7~11 1 : keydown 2 : keypress 3 : compositionstart ㄴ(s) 4 : text ㄴ(s) 5 : text 나(sk) 6 : text 남(ska) 7 : text 나무(skan) 8 : input 나무(skan) 9 : compositionend 나무(skan) 10 : compositionstart 나무(skan) 11 : text 나무(skan)

(In reply to comment #20) > So seems like Korean IME on Windows XP does generate 'compositionstart', 'text' > and 'compositionend' events. > One could also use non-standard (but supported by many browsers) input event. > http://mozilla.pettay.fi/moztests/key_event_test.html > > Based on DOM 3 Events (draft), web apps which want to handle IME input, > shouldn't rely on key events, but use composition events. Or use 'textInput' > event, which > Gecko doesn't support yet. But we do have 'input' event. (In reply to comment #20) > So seems like Korean IME on Windows XP does generate 'compositionstart', 'text' > and 'compositionend' events. > One could also use non-standard (but supported by many browsers) input event. > http://mozilla.pettay.fi/moztests/key_event_test.html > > Based on DOM 3 Events (draft), web apps which want to handle IME input, > shouldn't rely on key events, but use composition events. Or use 'textInput' > event, which > Gecko doesn't support yet. But we do have 'input' event. I modified blog thread and added [8] result of other IME and browser. I don't know relation between browser and IME. I am a just second user. I checked and read W3C DOM l3 events again. I think that keyboard event type is one, composition and text events type are others. If the problem is based on IME, I think that proprietary OS would not modify their IME. Someone can fill lack of these events *virtually* to browser with referring other events (text,input,composition*). There is a pattern.

(In reply to comment #10) > Smaug: > > Thank you for the information, I think web browsers should not fire any key > events during composing, but HTML5 should have a new event handler, e.g., > "oncomposing". Because web apps cannot know the key events fired during > composing. I don't agree with that. Korean character is based on phoneme like english. When composing, (korean) key events need to be fired for browsers. That makes possible to search word within dictionary by key. And definitionally composing events is treated independently. I think korean is more similar to english, not to chinese and japanese. Though it needs to be composing, one key is one phoneme. eg. Additional Comments A/ddi/tio/nal/ /co/mmen/ts/ -> /./ means one character to korean ㅇ/ㄷㅣ/ㅅㅕ/ㄴㅓㄹ/ /ㅋㅓ/ㅁㅔㄴ/ㅊ/ 어/디/셔/널/ /커/멘/츠/ Moreover composing event type is another to keyboard event. It seems to block mouse event during composiong. But webapps would be solved this problem by properly selecting events in the future.

(In reply to comment #23) > (In reply to comment #10) > > Smaug: > > > > Thank you for the information, I think web browsers should not fire any key > > events during composing, but HTML5 should have a new event handler, e.g., > > "oncomposing". Because web apps cannot know the key events fired during > > composing. > > I don't agree with that. Korean character is based on phoneme like english. > When composing, (korean) key events need to be fired for browsers. That makes > possible to search word within dictionary by key. And definitionally composing > events is treated independently. I still think that we shouldn't fire any key events during composing. The compositionupdate event is enough for this issue. It is fired when the composition string is modified. And also there is another problem. We've never caught any native key events during composing in some cases. E.g., composition string is generated by mouse operation. So, using key event is wrong way for catching the text modification. Note that the composition string can be gotten by application developers via CompositionEvent.data (and also they can access to the text of input element via value attribute). > Moreover composing event type is another to keyboard event. It seems to block > mouse event during composiong. But webapps would be solved this problem by > properly selecting events in the future. I'm not sure what you mean. (In reply to comment #22) > If the problem is based on IME, I think that proprietary OS would not modify > their IME. Someone can fill lack of these events *virtually* to browser with > referring other events (text,input,composition*). There is a pattern. This paragraph too.

(In reply to comment #24) I'm very very sorry for my poor english and i can't modify comments. Moreover adding the comments for fixing my poor language makes just more jammed things. So i stopped write comment. I'm sorry again. I want the second paragraph is to be ignored. It seems that the issue has a more important thing based not on the IME, but on the policy or ideal at first. First paragraph means that blocking keyboard events would be so strange to me like that blocking the mouse events type while composing. That makes me simply to think that one event type would be independent from other types as a principle rule. But, I've noticed that other enviroment using mouse or more other environment(webapps) is(or would exist) for composing text. Surely composing or other event will be more gracefull and cover many webapps. but these event has still issue and left in W3C DOM L3 Events(DRAFT). Until now, keyboard event type has many issue too. but it exists and has been used generally for (korean) most of mordern other browsers. Yet some browsers don't have events about composing, too. but in the future they would adopt this, and decision like this makes trouble in compatibility. they should consider the remedies by timelines and i think when these issue properly solved, and then adopt this. Maybe as the thesis-antithesis-synthesis, one simple suggestion is a option or flag attaching to composition event(or field) about on-off these relation. Second problem is to catch a native key events. As you know that I don't know well and deeply about these issue. (I don't have one lesson about this field and major in humanities) but I tried to catch that at best. I've one question. How about safari(chrome) or IE? Don't these browsers fire any key events while composing? To korean, they fire key events by every key pressing or releasing. At least FF@LINUX has one keyup event which can solve this trouble. (IBus, I have not tested other IME within linux). I think there would be one solution. Alternatively, one suggestion is a more abstract event type which check the just changes of field(or node) live. It is similar to onchange event but live. I think It would be no trouble to other event type and don't needs to catch a result that makes different things(i.e. keycode) But this suggestion is just a ideal. there would be much effort of developers to test or materialize that. and I don't know it effects bad to overall performance extremly and how to check changes of value while composing. I just had started from one curiosity which is about autofill input from wikipedia by using firefox. But now i see the many things and your efforts from other reports. I love firefox. Many thanks. :)

W3C DOM Level3 Spec. also introduces that keyboard events should not be dispatched to the DOM during a composition. Firefox4.0b1 has three issues for handling composition events. 1. compositionupdate event is not implemented ( already reported => Bug 543789 - No compositionupdate events using IME ) 2. When a composition starts in Firefox4.0b1 for OS X & Windows7, a keydown event still is dispatched and each platform handles composition events a little bit different. => Refer to Composition Events Test (http://bit.ly/99tkd0) However, Safari and Chrome still fire keyup/down event during a composition with composition events. Is this a bug?

3. textEvent should be fired after compositionend if a character value is produced

I discussed this issue with WebKit folks. https://lists.webkit.org/pipermail/webkit-dev/2010-July/013684.html They thought that keyboard events must be sent while an IME is active. Because WebKit has been firing key events for a long time so they told me that a lot of sites would break without key events in WebKit browsers. Is there any way for Firefox and Webkit based browsers to handle key events and composition events in the same way?

I think you may not always get key events with IME. It depends on the IME you're using. And issue with Webkit is that they haven't supported composition events for a long time, so they need to support their old style events too.

OK, I understand the current situation. Instead, we need to add those reasons to the W3C spec. Because, If someone read the spec, he or she may be confused due to inconsistent key events fired from browsers even using the same IME.

Using key events as text input events doesn't make sense because some IME/platform may not fire key events during composition, e.g., GTK2 with uim and SCIM. And some IME may allow to change the composition string by mouse operation.

Currently, D3E spec said that keypress events must not be dispatched during composition. However, keydown and keyup events are not so. See also: http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0117.html http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0118.html If we can dispatch the events during composition, we should do it. But maybe, we need to research all of our internal event handlers before that. So, I don't think that this bug should be given priority now. Anyway, web developers shouldn't use keydown event and keyup event if they want to know when composition string is updated. IME composition string can be modified by mouse too. They should use compositionupdate event which is going to be available on Fx9.

Note: When we fix this bug, we MUST check all keydown and keyup event handlers of us. Use following regexp for searching them. (["'](keydown|keyup)["']|onkeydown|onkeyup|NS_KEY_DOWN|NS_KEY_UP)

given that bug 687717 has landed, do we still need this bug to fix these issues on Android?

(In reply to Brad Lassey [:blassey] from comment #36) > given that bug 687717 has landed, do we still need this bug to fix these > issues on Android? I am told on irc that this is the case. If anyone disagrees, please explain why and re-nom.

Brad: This bug shouldn't block it. Actually, there is this issue for some keyboard layout users of Android too. However, it needs a lot of work, therefore, we cannot fix this bug easily. Additionally, web developers shouldn't use keydown/keyup events for handling text input. They should use HTML5's input event instead. It makes sense for non-keyboard text input devices such as hand-writing.

FYI: D3E WG members are now thinking key events shouldn't be fired during composition. If D3E would define so, I'm not sure if this should be fixed. For compatibility with other browsers, this should be fixed. However, other browsers may change their behavior like ours in the future.

5.2.7.5 Key Events During Composition https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#events-composition-event-key-events During the composition session, all keydown and keyup events MAY be suppressed. And: Firefox (suppressed keyup/keydown) Chrome and IE (not suppressed keyup/keydown) Better have the same behaviour, but like you said, in future other browser may change their behaviour (or D3E may change definition:).

Is there any update regarding this issue? its blocking some features we need to use Korean characters in. Why its working on old Firefox versions but not working on new ones? Is there any work around to solve this?

(In reply to Asma from comment #42) > Is there any update regarding this issue? its blocking some features we need > to use Korean characters in. > > Why its working on old Firefox versions but not working on new ones? As far as I know, we never dispatch key events during composition. > Is there any work around to solve this? Why don't you use "input" or "compositionupdate"? We'll dispatch "keydown" and "keyup" events in the future for compatibility with other browsers, you should handle "input" or "compositionupdate" event since neither "keydown" nor "keyup" event is fired when the user uses voice input or handwriting system which are implemented as IME.

Do you have an example how to use compositionupdate in javascript ? I will try may it help..

I tried and its working now, typing korean in textfield was captured using compositionupdate. Thanks alot !!

(In reply to Asma from comment #45) > I tried and its working now, typing korean in textfield was captured using > compositionupdate. > > Thanks alot !! FYI: compositionupdate is fired *before* modifying the editor content. input is fired *after* modifying the editor content. I recommend web authors use input event because it's fired when it's enough safe to do anything. For example, compositionudpate is fired during handling composition string modification. So, changing editor content from compositionupdate *might* hit browser's bug.

Hi! Any updates on this issue? We are developing custom rich text editor, so it is important to handle all key events. I didn't find any workaround for Korean language. Such event as compositionupdate doesn't contain data about key that was pressed.

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Will be fixed by bug 1496288.

Posted site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2018/keydown-and-keyup-events-are-now-fired-during-ime-composition/