This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I think that this is very important difference, even though it's edge case. There are 2 timing to dispatch keydown event. 1. Dispatch keydown event *before* IME handles native key event. If the keydown event is consumed (preventDefault() is called), browser don't need to pass the native key event to IME. One of the merits of this approach is, even there is no way to cancel composition on the platform, browser can prevent to start composition by first keydown event. One of the demerits of this approach is, web apps may consume a shortcut key of IME. But even this approach is preferred, if composition is already started, native key events must be passed to IME even if keydown events are consumed by web content since it can prevent to close candidate window of IME! 2. Dispatch keydown event *after* IME handles native key event. Even if keydown event is consumed by web apps, browser may not cancel composition (e.g., on Linux). I guess that current browsers uses the latter approach. But I think that the former approach is preferred by D3E according to the documentation of the default action of keydown event.
The principle that we applied in IE11 when addressing a similar scenario, was that keydown is always first given to the web application to handle and cancel if desired. Then, if not handled, everything else kick-starts. Our own IME system has a convoluted relationship with the keydown windows message. In some cases the IME actually consumes the windows message first (such as when starting to type on an input element where the IME is initialized) no matter how much we'd like to handle it in the browser. In these cases we do still get a shot at the keyboard event, and we have to synthesize a trusted event to the web apps. Basically, we try to maintain the principle that the web application gets the first opportunity to cancel the event or let it play out. Overall, I think this is an implementation detail, and not one that the W3C spec can specify across different IMEs/platforms.
(In reply to Travis Leithead [MSFT] from comment #1) > Overall, I think this is an implementation detail, and not one that the W3C > spec can specify across different IMEs/platforms. This may make difference of some attributes of KeyboardEvent. If the case of bug 23910 should set IME inputting character to the .key value, keydown event must be handled after native IME handles it. Additionally, e.g., on Linux, there is no way to cancel composition even if keydown event is consumed by web apps by a call of preventDefault(). If browser dispatches keydown event before IME handles the event, browser can prevent starting composition with consumed keydown event. However, if we do so, keydowen event's .key value must be input text without IME.
(1) is the model that we have been using for all our key/IME discussions so far: the key event is sent to the webapp and then the IME If the key event is cancelled, the browser is supposed to make a best-effort to cancel the IME, but the spec is written to allow the case where the IME cannot be cancelled. Bug 23910 describes a "fix" to workaround bugs in poorly-written websites. The fix seems a bit hackish to me (and it only partially addresses the bug). While it seems OK to write the spec to allow this workaround, it seems very wrong to use this situation to drive larger spec decisions.