Bug 126121 – The JavaScriptCore API ignores dynamically created protocols

• Status: NEW
• Component: JavaScriptCore

[Mark Villacampa]

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.

[Brandon Evans]

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.