Bug 33360 – Web Inspector: Console-invoked ObjC methods lose their string parameters

• Component: WebCore JavaScript
• Status: RESOLVED FIXED

[Daniel Jalkut]

1. Inspect a document whose DOM has a WebScriptObject attached with exposed methods.
2. Arrange that one of those exposed methods takes a string parameter, e.g.:

- (void) debugLog:(NSString*)theLogString
{
	NSLog(@"%@", theLogString);
}

3. Attempt to call the bridged method from the inspector's console window, e.g.:

window.myObject.debugLog_("hello there!");

RESULT: Although the bridged method is called, the "hello there!" string does not survive the transition, and arrives as a nil parameter.

Expected: The strings generated in the context of the Console/Inspector should survive as well as strings evaluated and passed in the course of a page's imported scripts.

Note that it's not just a literal vs. object type of problem. I declared a string object in the console as:

var myString = new String("hello there!");

And passing that variable to the bridged method fails as well.

I did a cursory hunt through WebCore before I gave up trying to find the root cause. But my naive assumption is it has something to do with the convertValueToObjcValue: method in objc_utility.mm. It appears that a valid JSValue exists at this point, and even claims to be a string, but the block of code starting with "case ObjcObjectType:" is not able to locate a root object for the JSValue.

Hope this helps,
Daniel

[Daniel Jalkut]

I meant to mention that the buggy behavior is true as of trunk WebKit sources, checked out earlier today.

[Mark Rowe (bdash)]

Daniel, this would be easier to test and investigate if there was a simple test application that could easily be used to demonstrate the problem.

[Mark Rowe (bdash)]

<rdar://problem/7521765>

[Mark Rowe (bdash)]

Created attachment 46131 [details]
Patch to MiniBrowser that allows testing of this issue

After applying this patch to MiniBrowser the issue can be reproduced by opening the inspector from the context menu and entering “browser.log_(‘I am not null!’)” at the console.

[Daniel Jalkut]

Mark, sorry I didn't include an example.  Thanks for running with it and putting together the patch for easily reproducing it.

[Rémy SAISSY]

(In reply to comment #5)
> Mark, sorry I didn't include an example.  Thanks for running with it and putting together the patch for easily reproducing it.

Hi,
I've attached a patch for this issue. It applies to WebCore/bridge/objc/objc_utility.mm.

I was also not able to find the root cause but I've found that it has something to do with RootObject initialization.
Indeed, the call to findRootObject() in objc_utility.mm returns nil whereas it should return a valid pointer since the conversion code is in _convertValueToObjcValue:.

I've also found that - (void)setValue:(id)value forKey:(NSString *)key in bindings/objc/WebScriptObject.mm
uses a rootObject to add the webscript. Maybe an initialization is missing here.

Hope this helps,
Rémy

[Rémy SAISSY]

Created attachment 113513 [details]
Patch for the issue

[Joseph Pecoraro]

(In reply to comment #7)
> Created an attachment (id=113513) [details]
> Patch for the issue

Something appears wrong with this patch. It shows an entirely replaced file
instead of what differed within the file. Could you upload a new patch?
Also, it looks like you used tabs for your changes. You should follow
WebKit's style of 4 spaces no tabs.

[Rémy SAISSY]

Created attachment 113521 [details]
Patch

Hi Joseph,
a ^M issue, sorry.
I fixed it, here is the new patch.

Regards,
Rémy

[Blaze Burg]

I am unable to reproduce this issue. A test application would a help a lot. Please re-open if this is still relevant to anything.

[Daniel Jalkut]

Happily, I can confirm that this is not reproducable in the WebKit that ships with macOS 10.12.2.