Bug 9933
| Summary: | DOM3 keyboard events are not working like real ones | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | David Carson <dacarson> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, darin, ggaren, syoichi |
| Priority: | P2 | ||
| Version: | 420+ | ||
| Hardware: | Mac | ||
| OS: | OS X 10.4 | ||
| URL: | http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-KeyboardEvents-Interfaces | ||
David Carson
DOM3 KeyboardEvents created with Javascript do not construct a PlatformKeyboardEvent, see http://bugzilla.opendarwin.org/show_bug.cgi?id=9743#c6
What should happen is KeyboardEvent is used through out the code. Presently PlatformKeyboardEvent is being used. PlatformKeyboardEvent should only be used to parse the platform event and setup the KeyboardEvent properly.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Geoffrey Garen
One benefit of fixing this bug is that editing will start to work with key events dispatched by JavaScript. See this comment in FrameMac.mm:
// FIXME: We might eventually need to make sure key bindings for editing work even with
// events created with the DOM API. Those don't have a PlatformKeyboardEvent.
Darin Adler
(In reply to comment #1)
> One benefit of fixing this bug is that editing will start to work with key
> events dispatched by JavaScript. See this comment in FrameMac.mm:
>
> // FIXME: We might eventually need to make sure key bindings for editing
> work even with
> // events created with the DOM API. Those don't have a
> PlatformKeyboardEvent.
There are really two separate issues.
One is that within WebCore itself we'd like to use the DOM keyboard event objects. That may turn out to be straightforward, but it also may turn out that there's information in the platform events that the DOM events don't contain. So we might need to extend the DOM.
The key bindings issue is a separate one. That mechanism, part of OS X, is based on NSEvent objects. So a PlatformKeyboardEvent is not good enough -- we actually need an NSEvent. To fix that we'll need to create NSEvent objects for events created by the DOM.
While similar, there are different types of fixes needed for each of these two issues.
David Carson
When this defect is corrected, hasFeature("keyboardevent", "3.0") should return true
David Carson
(In reply to comment #3)
> When this defect is corrected, hasFeature("keyboardevent", "3.0") should return
> true
>
Also see http://bugzilla.opendarwin.org/show_bug.cgi?id=10297
hasFeature() is implemented in DOMImplementation.cpp
David Carson
Current IDL represents the DOM3 KeyboardEvent IDL as of 31st march 2003. The IDL for keyboardevent was updated on 11th Nov 2003 to what it is today. What changed was the boolean for each of the modifier keys to a DOMString whitespace separated string list.
Alexey Proskuryakov
See also: http://bugs.webkit.org/show_bug.cgi?id=16735
Alexey Proskuryakov
The most tricky part here is probably to assess security implications. What exactly should DOM be allowed to do by dispatching synthetic events? Should it be able to dispatch Cmd+Q to quit the application, for example?
Darin Adler
(In reply to comment #7)
> The most tricky part here is probably to assess security implications.
OK.
> What exactly should DOM be allowed to do by dispatching synthetic events?
Generally speaking, commands that have effects within the webpage.
> Should it be able to dispatch Cmd+Q to quit the application, for example?
No.