Bug 126121 - The JavaScriptCore API ignores dynamically created protocols
Summary: The JavaScriptCore API ignores dynamically created protocols
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-21 12:30 PST by Mark Villacampa
Modified: 2013-12-30 16:44 PST (History)
4 users (show)

See Also:


Attachments
Example of dynamically generated protocol ignored by JavaScriptCore (1.09 KB, application/octet-stream)
2013-12-21 12:30 PST, Mark Villacampa
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Villacampa 2013-12-21 12:30:48 PST
Created attachment 219854 [details]
Example of dynamically generated protocol ignored by JavaScriptCore

I would like to use a dynamically generated protocol as my JSExport sub-protocol for interacting with JavaScriptCore.

However JavaScriptCore ignores dynamically generated protocols. Attached is a snippet which shows the behaviour when the protocol is statically defined, and when it is dynamically defined.

The "hello" method is only called when the protocol is statically defined.

I have tracked down the issue to the private Objective-C runtime method  _protocol_getMethodTypeEncoding() which returns null if the protocol method has been dynamically defined.

Said method is extensively used in the ObjCCallbackFunction.mm file. A solution, if possible, would be to use the method_getTypeEncoding() method which correctly outputs the type encoding for both dynamically and statically generated protocol methods.
Comment 1 Brandon Evans 2013-12-30 16:44:22 PST
I've been investigating this bug as well, and it seems that the private _protocol_getMethodTypeEncoding method also emits type strings (e.g. 'v24@0:8@16' vs. 'v24@0:8@"JSValue"16') when the compiler's type information is available. This extended type information is used when invoking Objective-C code, specifically when parseObjCType calls typeOfClass in ObjcRuntimeExtras.h at L197.

I made the appropriate changes to use method_getTypeEncoding instead like you suggested and most cases seem to work with the exception of methods that accept a JSValue as a parameter (such as a JS function). These end up getting passed an empty NSDictionary, so there's clearly some problems that occur when the argument type information isn't available to JSC.

It may be possible to work around this by also providing protocols for these specific methods and then ignoring them when doing a dynamic export to avoid losing the type information. This is clearly less elegant though.