NEW 9933
DOM3 keyboard events are not working like real ones 
https://bugs.webkit.org/show_bug.cgi?id=9933
Summary DOM3 keyboard events are not working like real ones
David Carson
Reported 2006-07-15 09:53:05 PDT
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
Comment 1 2006-07-15 09:55:26 PDT
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
Comment 2 2006-07-17 10:45:56 PDT
(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
Comment 3 2006-08-07 16:49:54 PDT
When this defect is corrected, hasFeature("keyboardevent", "3.0") should return true
David Carson
Comment 4 2006-08-07 16:51:23 PDT
(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
Comment 5 2006-08-08 17:28:48 PDT
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
Comment 6 2008-01-12 14:04:46 PST
See also: http://bugs.webkit.org/show_bug.cgi?id=16735
Alexey Proskuryakov
Comment 7 2011-01-27 14:33:58 PST
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
Comment 8 2011-01-27 14:35:32 PST
(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.
Note You need to log in before you can comment on or make changes to this bug.