See the thread here: http://lists.apple.com/archives/Webkitsdk-dev/2005/May/msg00050.html In short, adding event listeners via Obj-C has no effect. WebKit doesn't call handleEvent on the target (which conforms to the EventListener protocol).
Uh oh. I see why: - (void)addEventListener:(NSString *)type :(id <DOMEventListener>)listener :(BOOL)useCapture { ERROR("unimplemented"); } - (void)removeEventListener:(NSString *)type :(id <DOMEventListener>)listener :(BOOL)useCapture { ERROR("unimplemented"); }
Created attachment 3190 [details] patch to implement this
Comment on attachment 3190 [details] patch to implement this Anders said he tried this out and it worked.
Comment on attachment 3190 [details] patch to implement this Looks fine. Two comments: 1. I don't understand the ListenerMap map = listenerMap; dance that you do in two places. You had made some comment before about locals being faster to access... but particularly in the ObjCEventListener::find case it seems superfluous. 2. Although I personally agree with the style of returning objects ref-counted... ObjCEventListener::create differs from the rest of the C++ code in WebCore by doing so. I think that wrapper should be returned floating and stuck into a SharedPtr if necessary, or simply returned as a SharedPtr<ObjCEventListener> for consistancy. I'll leave those corrections to your discression. r=me.
As ggaren correctly points out, all of these really should have layout tests. For better or worse I ignored that fact, realizing that we don't currently (AFAIK) have any way of testing the Obj-C DOM API. I talked with andersca a bit on IRC, he said he started the py-objc Obj-C DOM testing system, but hasn't finished yet.
OK, since we don't have a way to test the bindings yet, I'm landing this without a test.
<rdar://problem/4562444>