Bug 145900 – -[WKWebView evaluateJavaScript] provides a misleading error when the return cannot be serialized

• Component: WebKit API
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

-[WKWebView evaluateJavaScript] can't return nodes, because they cannot be sent to UI process. But we currently claim that there was a JavaScript exception, which is super misleading.

[Alexey Proskuryakov]

Created attachment 254765 [details]
proposed fix

[WebKit Commit Bot]

Attachment 254765 [details] did not pass style-queue:


ERROR: Source/WebKit2/UIProcess/WebPageProxy.cpp:2574:  Extra space before ( in function call  [whitespace/parens] [4]
ERROR: Tools/TestWebKitAPI/Tests/WebKit2Cocoa/WKWebViewEvaluateJavaScript.mm:70:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
ERROR: Tools/TestWebKitAPI/Tests/WebKit2Cocoa/WKWebViewEvaluateJavaScript.mm:81:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
ERROR: Source/WebKit2/UIProcess/WebPageProxy.h:762:  Extra space before ( in function call  [whitespace/parens] [4]
Total errors found: 4 in 13 files


If any of these errors are false positives, please file a bug against check-webkit-style.

The new API needs an availability macro.

[Alexey Proskuryakov]

> The new API needs an availability macro.

Why?

[Anders Carlsson]

(In reply to comment #4)
> > The new API needs an availability macro.
> 
> Why?

So people who deploy against older versions of OS X and iOS get the right compiler warnings/errors.

[Anders Carlsson]

This also needs to go through internal API review.

[Alexey Proskuryakov]

> So people who deploy against older versions of OS X and iOS get the right compiler warnings/errors.

Can you please be more specific? I know what an availability macro is, but don't know what situation you have in mind.

Perhaps a code snippet where a warning would be helpful.

[Anders Carlsson]

(In reply to comment #7)
> > So people who deploy against older versions of OS X and iOS get the right compiler warnings/errors.
> 
> Can you please be more specific? I know what an availability macro is, but
> don't know what situation you have in mind.
> 
> Perhaps a code snippet where a warning would be helpful.

Imagine someone writing an iOS app using the latest SDK but deploying back to 10.10 and iOS 8. In that case, this API is not available so attempting to use it should be an error.

I'm sure Dan could be more specific if I we asked him nicely :)

[Alexey Proskuryakov]

I don't think that there is any helpful way to express a change like this via availability macros. For someone who already looks at the error values, no longer reporting the condition as WKErrorJavaScriptExceptionOccurred would be quite harmful too.

In person, Anders told me that he would prefer to have an availability macro just for consistency, which is OK with me, but I don't think that there is a true need for it here.

Anders is right, the compiler is not going to emit a warning or generate different code, but the availability information is still useful to developers ("why am I not getting this error when doing this thing on this platform, but I do get it on that platform?") and to WebKit contributors. It is also the convention across all Cocoa API.

[Alexey Proskuryakov]

Committed r185554 with Gtk build fixes and with the still questionable availability macro.