Bug 9736 – -(void)init*Event missing in DOMKeyboardEvent and DOMWheelEvent

• Component: WebKit API
• Status: RESOLVED FIXED

[Jonas Witt]

When adding the APIs for these two classes in Bug 9181, I didn't add the -initKeyboardEvent and -initWheelEvent like the other ObjC events have. Therefore, one can't create these events.

[Jonas Witt]

Created attachment 9202 [details]
initKeyboardEvent attempt

This is what I've got for the DOMKeyboardEvent so far.

However, I'm having a problem with WebKit that is likely related to this code. I'm creating a DOMKeyboardEvent with [DOMDocument createEvent:@"KeyboardEvent"], then I use the initializer from the patch with the following values (from the XML my app reads):

   <event>
      <target domindex="0,1,0,5,2,0,0,1,1"/>
      <property name="type" value="keypress"/>
      <property name="class" value="KeyboardEvent"/>
      <property name="bubbles" value="true"/>
      <property name="cancelable" value="true"/>
      <property name="detail" value="0"/>
      <property name="ctrlKey" value="false"/>
      <property name="shiftKey" value="false"/>
      <property name="altKey" value="false"/>
      <property name="metaKey" value="false"/>
      <property name="keyIndentifier" value="U+000041"/>
      <property name="keyLocation" value="0"/>
   </event>

(For the abstract view argument, I pass NULL. Maybe that could be the problem...)

Then I dispatch this event to a <input> field in my WebView. When I do this, WebKit crashes:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
WebCore::FrameMac::doTextFieldCommandFromEvent (this=0x14a0cf20, input=0x14a2ce10, event=0x0) at /Users/jonas/Desktop/itCampus/WebKit/WebKitBuild/Release/JavaScriptCore.framework/PrivateHeaders/RefPtr.h:37
37              RefPtr(const RefPtr& o) : m_ptr(o.m_ptr) { if (T *ptr = m_ptr) ptr->ref(); }
(gdb) bt
#0  WebCore::FrameMac::doTextFieldCommandFromEvent (this=0x14a0cf20, input=0x14a2ce10, event=0x0) at /Users/jonas/Desktop/itCampus/WebKit/WebKitBuild/Release/JavaScriptCore.framework/PrivateHeaders/RefPtr.h:37
#1  0x010d00a4 in WebCore::HTMLInputElement::defaultEventHandler (this=0x14a2ce10, evt=0x14a52688) at /Users/jonas/Desktop/itCampus/WebKit/WebCore/html/HTMLInputElement.cpp:1245
#2  0x0127a9d8 in WebCore::EventTargetNode::dispatchGenericEvent (this=0x14a2ce10, e=@0x48, tempEvent=false) at /Users/jonas/Desktop/itCampus/WebKit/WebCore/dom/EventTargetNode.cpp:255
#3  0x0127ae04 in WebCore::EventTargetNode::dispatchEvent (this=0x14a2ce10, e=@0x48, ec=@0xbfffd35c, tempEvent=false) at /Users/jonas/Desktop/itCampus/WebKit/WebCore/dom/EventTargetNode.cpp:290
#4  0x0113fb94 in -[DOMNode dispatchEvent:] (self=0x186e9600, _cmd=0x48, event=0x186f4170) at /Users/jonas/Desktop/itCampus/WebKit/WebCore/bindings/objc/DOM.mm:440
#5  0x90a431f4 in objc_msgSendv ()
#6  0x9293fce0 in -[NSInvocation invoke] ()
[...]

What's wrong with the initializer?

[Joost de Valk (AlthA)]

Comment on attachment 9202 [details]
initKeyboardEvent attempt

Setting review on this patch, so that someone can have a look at it and deliver some comments.

[Joost de Valk (AlthA)]

Confirmed, Jonas, could you email me a few bugs you've been working on? I think you're in title to have editbugs and canconfirm rights, if so, i'll get them set up for you.

[Geoffrey Garen]

I believe the crash you're seeing is a dup of bug 9743. However, you shouldn't pass NULL as the abstractView argument. document.defaultView should work.

[Geoffrey Garen]

Comment on attachment 9202 [details]
initKeyboardEvent attempt

This patch looks correct, but it's missing the test you mentioned and a ChangeLog entry.

[Darin Adler]

You don't need to be blocked by bug 9743 if you dispatch the event to something other than an input element.

[Jonas Witt]

Created attachment 9811 [details]
DOMKeyboardEvent and DOMWheelEvent initializer wrappers plus test

I've added the DOMKeyboardEvent and DOMWheelEvent initializer wrappers (for the WheelEvent, there was no C++ initializer, so I've written one) and a test that asks EventSendingController to dispatch a few DOMKeyboardEvent (created using the new initializer) on an input element.

BTW: Fixing of Bug 9743 has also fixed my crash, so Geoffrey was right.

[Darin Adler]

Adding more wrappers one at a time is not the best use of our time. Instead we need to get Objective-C bindings to be generated as the JavaScript ones are.

These are new API so they will need API review before they can be released by Apple as part of OS X. To help with that, we should probably put these in a "pending public" header rather than adding them right to the public header.

[Maciej Stachowiak]

Comment on attachment 9811 [details]
DOMKeyboardEvent and DOMWheelEvent initializer wrappers plus test

r- for darin's comment about using a pending public header.

[Jonas Witt]

Created attachment 9845 [details]
DOMKeyboardEvent and DOMWheelEvent initializer wrappers plus test - 2

Moved the two init* methods to DOMPrivate.h.

What about the autogeneration? Is bug 4624 the right place to talk about that?

[Darin Adler]

Comment on attachment 9845 [details]
DOMKeyboardEvent and DOMWheelEvent initializer wrappers plus test - 2

The approach here looks wrong. The idea is to use the bridge to call methods from JavaScript tests. Writing a custom function inside DumpRenderTree for each test is not the right idea.

[Darin Adler]

(In reply to comment #10)
> What about the autogeneration? Is bug 4624 the right place to talk about that?

I think that it's OK to add more to the bindings, but it's a way better use of our time to get the autogeneration working. I'll just keep complaining as we do more by hand.

[Darin Adler]

Comment on attachment 9845 [details]
DOMKeyboardEvent and DOMWheelEvent initializer wrappers plus test - 2

r=me for now, but I'd like to see this test reworked to be written more in JavaScript and remove the specific code for this test added to DumpRenderTree. I guess that can be done in a separate patch.

[Darin Adler]

Committed revision 15905.