Bug 33360 - Web Inspector: Console-invoked ObjC methods lose their string parameters
Summary: Web Inspector: Console-invoked ObjC methods lose their string parameters
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2010-01-07 20:26 PST by Daniel Jalkut
Modified: 2016-12-14 11:04 PST (History)
10 users (show)

See Also:


Attachments
Patch to MiniBrowser that allows testing of this issue (1.53 KB, patch)
2010-01-08 04:30 PST, Mark Rowe (bdash)
no flags Details | Formatted Diff | Diff
Patch for the issue (24.91 KB, patch)
2011-11-03 10:07 PDT, Rémy SAISSY
no flags Details | Formatted Diff | Diff
Patch (1.32 KB, patch)
2011-11-03 10:56 PDT, Rémy SAISSY
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Jalkut 2010-01-07 20:26:37 PST
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
Comment 1 Daniel Jalkut 2010-01-07 20:27:33 PST
I meant to mention that the buggy behavior is true as of trunk WebKit sources, checked out earlier today.
Comment 2 Mark Rowe (bdash) 2010-01-07 21:12:35 PST
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.
Comment 3 Mark Rowe (bdash) 2010-01-07 21:13:10 PST
<rdar://problem/7521765>
Comment 4 Mark Rowe (bdash) 2010-01-08 04:30:58 PST
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.
Comment 5 Daniel Jalkut 2010-01-08 08:06:24 PST
Mark, sorry I didn't include an example.  Thanks for running with it and putting together the patch for easily reproducing it.
Comment 6 Rémy SAISSY 2011-11-03 10:05:11 PDT
(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
Comment 7 Rémy SAISSY 2011-11-03 10:07:00 PDT
Created attachment 113513 [details]
Patch for the issue
Comment 8 Joseph Pecoraro 2011-11-03 10:35:46 PDT
(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.
Comment 9 Rémy SAISSY 2011-11-03 10:56:28 PDT
Created attachment 113521 [details]
Patch

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

Regards,
Rémy
Comment 10 BJ Burg 2016-12-14 10:22:09 PST
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.
Comment 11 Daniel Jalkut 2016-12-14 11:04:09 PST
Happily, I can confirm that this is not reproducable in the WebKit that ships with macOS 10.12.2.