When using the Japanese IME, alphabetic characters are entered and then converted into the desired kanji. After conversion, hitting Return completes the process while Esc returns to the pre-conversion state. Firefox does not handle Esc correctly in this state, it exits the IME state altogether. Setup steps: 1. In System Preferences, enable Japanese input method via International > Input Methods 2. Select "Show input menu in menu bar" Steps to reproduce: 1. Click on the URL above 2. Click in the main textarea 3. Switch to Hiragana mode in the IME menu (a small あ will appear) 4. Enter the text below: genki Displayed Japanese text: げんき 5. Hit the space bar to convert to kanji characters. Display Japanese text: 元気 (the underline indicates that IME mode is enabled) 6. Hit Esc Expected result: げんき Actual result: 元気 and IME mode is exited This is an incredibly annoying bug when editing Japanese text, the use of esc serves as a way of fixing an error in the sequence of input characters. If the IME mode is exited, then the entire text needs to be deleted and reentered.
Seems to work fine here . I hit Esc, the string reverts to げんき and IME is still active. 10.5.5, Apple (aluminium) JIS keyboard, latest official nightly build.
John - did this ever work for you? If so, can you give an exact date or a guess as to when this stopped working?
Now I'm puzzled. After creating a new profile, then switching back to my old one, testpage works fine. Argh. However, gmail still has this buggy behavior. Steps: 1. Open gmail, compose a new message 2. Steps as above Results: as above Safari works fine, FF2/Opera 9.6 do not (same as FF3).
@ Gmail: not only does it not work correctly for IME/Kotoeri, but the Esc moves the focus out of the textarea, independently of the input method - both with the English Gmail UI and the Jpn Gmail UI. Does that make this a Gmail bug ? Or is there some conflict in the handling of the Esc key in combination with Gmail JS ?
So you think this is a bug in gmail's user-agent specific key-handling code? Using the esc key works fine in Safari, that's why I wonder...
Is Safari sending the same keycode(s) for Esc? We've had "bugs" with sites before where we sent keycodes and Safari didn't, so Safari didn't exhibit a "bug" because it wasn't sending the keycode the site was trapping. The other thing I can think of is that Safari is giving IME priority over the site's trapping/binding. (Or it could be bug 442660, but at that point we're in a world of hurt.)
This bug should be ours. Any DOM key events should not be fired during IME transaction.
Created attachment 348719 [details] [diff] [review] Patch v1.0 I need to test...
Assignee: joshmoz → masayuki
Status: NEW → ASSIGNED
Created attachment 349710 [details] [diff] [review] Patch v1.1 Sorry for the delay. NS_KEY_DOWN/NS_KEY_UP/NS_KEY_PRESS events must not be generated during IME composing. nsWindow of Win32 runs so.
Tested patch v1.1, confirmed that use of esc key with input method works correctly (yay!).
Comment on attachment 349710 [details] [diff] [review] Patch v1.1 WARNING: GetCharCode used for wrong key event; should use onkeypress.: file /Users/josh/src/mozilla/ff_192_debug/content/events/src/nsDOMKeyboardEvent.cpp, line 116 This warning gets spit out every time I hit a key in a gmail message compose field. Is that OK?
(In reply to comment #11) > (From update of attachment 349710 [details] [diff] [review]) > WARNING: GetCharCode used for wrong key event; should use onkeypress.: file > /Users/josh/src/mozilla/ff_192_debug/content/events/src/nsDOMKeyboardEvent.cpp, > line 116 > > This warning gets spit out every time I hit a key in a gmail message compose > field. Is that OK? It's OK for this bug. I can reproduce it on Win32 too. It's another bug.
oops, Josh is not in the cc list... Josh, please read my previous comment.
Attachment #349710 - Flags: superreview?(roc)
Attachment #349710 - Flags: superreview?(roc) → superreview+
Attachment #349710 - Flags: approval1.9.1?
Comment on attachment 349710 [details] [diff] [review] Patch v1.1 This patch makes same behavior as Win32 key events during IME composing.
landed to trunk. http://hg.mozilla.org/mozilla-central/rev/c110c33e9470
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [needs 191 landing]
Target Milestone: --- → mozilla1.9.2a1
Whiteboard: [needs 191 landing] → [c-n: baking for 1.9.1]
Attachment #349710 - Flags: approval1.9.1? → approval1.9.1+
Whiteboard: [c-n: baking for 1.9.1]
You need to log in before you can comment on or make changes to this bug.