[Android WebView] Propagate Java exceptions for evaluateJavascript

[Android WebView] Propagate Java exceptions for evaluateJavascript

WebView applications can throw run-time exceptions within
WebView-callbacks. When such an exception is thrown from the callback
passed to evaluateJavascript it is not correctly propagated to Android's
feedback mechanism. This is because that callbacks is called through
JNI, and the default way (in Chromium) of handling Java exceptions
thrown on the Java-side of JNI calls is to print the stack trace for the
current exception to the logcat when the JNI call returns to native, and
then intentionally crash in native.

With this CL we avoid the problem of propagating a Java exception back
through JNI and the native stack by posting the WebView-callback (which
can cause the Java exception) as a new task to the current Java Handler.
In that way any Java exception thrown inside the WebView-callback can be
propagated directly up to the Android framework's
UncaughtExceptionHandler which then properly reports the Exception
through the framework's crash reporting mechanism.

BUG=719396
Review-Url: https://codereview.chromium.org/2900033002
Cr-Commit-Position: refs/heads/master@{#473930}
Committed: https://chromium.googlesource.com/chromium/src/+/b8b1cbadd7941505caf3cdaebfa30f019854f815

[gsennton, 2017-05-23 12:57:43]

gsennton@chromium.org changed reviewers:
+ torne@chromium.org

[gsennton, 2017-05-23 12:57:44]

PTAL :)

Note that I didn't add the fix for EvaluateJavascriptForTests.
Not sure if we should add fix that method as well - given that it won't give us
anything in the real world - and crashing through JNI shouldn't really be a
problem during tests where we have the logcat anyway. WDYT?

[Torne, 2017-05-23 15:07:32]

LGTM. I don't think we need to change the test version.

[gsennton, 2017-05-23 15:39:40]

On 2017/05/23 15:07:32, Torne wrote:
> LGTM. I don't think we need to change the test version.

Thanks, if we happen to need it in the future we can just update it at that
point anyway.

[gsennton, 2017-05-23 15:39:53]

The CQ bit was checked by gsennton@chromium.org

[commit-bot: I haz the power, 2017-05-23 15:40:31]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-23 16:22:42]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1495553993394350, "parent_rev":
"eb8d574b98adfcbd3b5ce2eb6e521b83efbb428a", "commit_rev":
"b8b1cbadd7941505caf3cdaebfa30f019854f815"}

[commit-bot: I haz the power, 2017-05-23 16:22:52]

Description was changed from

==========
[Android WebView] Propagate Java exceptions for evaluateJavascript

WebView applications can throw run-time exceptions within
WebView-callbacks. When such an exception is thrown from the callback
passed to evaluateJavascript it is not correctly propagated to Android's
feedback mechanism. This is because that callbacks is called through
JNI, and the default way (in Chromium) of handling Java exceptions
thrown on the Java-side of JNI calls is to print the stack trace for the
current exception to the logcat when the JNI call returns to native, and
then intentionally crash in native.

With this CL we avoid the problem of propagating a Java exception back
through JNI and the native stack by posting the WebView-callback (which
can cause the Java exception) as a new task to the current Java Handler.
In that way any Java exception thrown inside the WebView-callback can be
propagated directly up to the Android framework's
UncaughtExceptionHandler which then properly reports the Exception
through the framework's crash reporting mechanism.

BUG=719396
==========

to

==========
[Android WebView] Propagate Java exceptions for evaluateJavascript

WebView applications can throw run-time exceptions within
WebView-callbacks. When such an exception is thrown from the callback
passed to evaluateJavascript it is not correctly propagated to Android's
feedback mechanism. This is because that callbacks is called through
JNI, and the default way (in Chromium) of handling Java exceptions
thrown on the Java-side of JNI calls is to print the stack trace for the
current exception to the logcat when the JNI call returns to native, and
then intentionally crash in native.

With this CL we avoid the problem of propagating a Java exception back
through JNI and the native stack by posting the WebView-callback (which
can cause the Java exception) as a new task to the current Java Handler.
In that way any Java exception thrown inside the WebView-callback can be
propagated directly up to the Android framework's
UncaughtExceptionHandler which then properly reports the Exception
through the framework's crash reporting mechanism.

BUG=719396

Review-Url: https://codereview.chromium.org/2900033002
Cr-Commit-Position: refs/heads/master@{#473930}
Committed:
https://chromium.googlesource.com/chromium/src/+/b8b1cbadd7941505caf3cdaebfa3...
==========

[commit-bot: I haz the power, 2017-05-23 16:22:53]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/b8b1cbadd7941505caf3cdaebfa3...