Summary: | KeyboardEvents -- standards-compliant behavior | ||
---|---|---|---|
Product: | WebKit | Reporter: | Ivo Krab <ivo.krab> |
Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
Status: | UNCONFIRMED --- | ||
Severity: | Enhancement | CC: | ap, rniwa |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | All |
Description
Ivo Krab
2010-03-19 06:54:36 PDT
It's not correct that keypress is always a consequence of keydown. On Windows, any process can send a WM_CHAR message to the browser, which will result in only keypress being dispatched. Generating a keypress from a programmatically created keydown is technically possible, but it would introduce lots of unexpected edge case behaviors. That's because we'd need to call back into OS keyboard event handling code to process the raw keydown. On different OSes, we'd get some or all of issues: - it would be possible to control the browser by dispatching e.g. Cmd+Q; - event queue would be out of sync, so stateful input methods (inline input, or just dead keys for plain keyboards) will be confused; - since processing a raw keydown with an input method frequently pops up additional UI elements, and runs a nested event loop, we'd get stuck in these. |