[Webkit-unassigned] [Bug 75543] [GTK] Add webkit_web_view_run_javascript() to WebKit2 GTK+

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Feb 18 00:55:55 PST 2012


https://bugs.webkit.org/show_bug.cgi?id=75543





--- Comment #8 from Carlos Garcia Campos <cgarcia at igalia.com>  2012-02-18 00:55:55 PST ---
(In reply to comment #6)
> (From update of attachment 126740 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=126740&action=review
> 
> It seems that there are three things we want to return for every JavaScript invocation: a JSContextRef, a JSValueRef and a JSValueRef for exceptions. I'm not sure the cleanest way to pass all this to the user with the GIO style API.

why not?

> I'm am fairly certain though that it doesn't make sense to pass the exception as a GError. I think we should reserve GErrors for when we actually have problems executing the JavaScript. It's important that the client can distinguish between script exceptions and problems internal to WebKit. The exception must be a JSValueRef in the end anyhow.

Agree, the GError passed to webkit_web_view_run_javascript_finish() wouldn't contain the javascript exection, because the script was correctly executed, if there's an error in the script that's not an error in the async operation. 

So as I suggested before, we could just return a WebKitJavascriptResult object (or boxed type, maybe) containing the context, the value and the exception.

> > Source/WebKit2/UIProcess/API/gtk/WebKitWebView.cpp:1396
> > +    JSValueRef scriptValue = WKSerializedScriptValueDeserialize(wkSerializedScriptValue, scriptContext, 0);
> 
> Instead of throwing away the exception it would be better to pass it to the client somehow. It's a pretty important piece of the story.

Ok, I see now.

> > Source/WebKit2/UIProcess/API/gtk/tests/TestWebKitWebView.cpp:474
> > +    callbackData.expectedResult = "WebKitGTK+ Title";
> > +    test->runJavaScriptAndWaitUntilFinished("window.document.getElementById('WebKitLink').title;", testWebViewRunJavaScriptFinishedCallback, &callbackData);
> 
> Instead of writing this with the use of a callback function, why not just store the results of the operation in WebKitWebView and read them after you call runJavaScriptAndWaitUntilFinished. 
This more closely matches how LoadTrackingTest works. I think it's a little more straight-forward too.

I didn't do that because with the current code the JSValueRef is a temporary value that is no longer alive after the execution of the callback. If we use the WebKitJavascriptResult, we could just store the result. I didn't like having to use a callback either.

> > Source/WebKit2/UIProcess/API/gtk/tests/WebViewTest.h:52
> > +    void runJavaScriptAndWaitUntilFinished(const char* js, JavascriptFinishedCallback, void* userData);
> 
> Would prefer something like scriptString instead of just "js"

Ok.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list