-[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.
Created attachment 254765 [details] proposed fix
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.
> The new API needs an availability macro. Why?
(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.
This also needs to go through internal API review.
> 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.
(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 :)
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.
Committed r185554 with Gtk build fixes and with the still questionable availability macro.