Peter created CB-3766:
-------------------------
Summary: Introduced bug causes Android stacktrace occurs during
cleanup of CordovaWebView
Key: CB-3766
URL: https://issues.apache.org/jira/browse/CB-3766
Project: Apache Cordova
Issue Type: Bug
Components: Android
Affects Versions: 2.7.0
Reporter: Peter
Assignee: Joe Bowser
This was already reprted on the PG Forum, where it was confirmed as a Cordova
bug.
https://groups.google.com/forum/?fromgroups#!topic/phonegap/NXRvkE8Euls
I am using Cordova v2.7.0.
My Main Android Activity looks like this:
{code}
public class MainActivity extends Activity implements CordovaInterface {
CordovaWebView cwv;
...
//Destruction code is as follows
@Override
public void onDestroy() {
if (cwv != null) {
cwv.handlePause(true);
cwv.handleDestroy();
cwv.removeAllViews();
cwv.destroy();
cwv = null;
}
super.onDestroy();
}
{code}
After 1st page is rendered, I cause the destroy event by pressing the device
BACK button.
This is always resulting in a stacktrace:
{code}
06-11 00:49:57.446: I/Web Console(823): onPause() called at
file:///android_asset/app1/index.html:11
06-11 00:49:58.762: W/IInputConnectionWrapper(823): showStatusIcon on inactive
InputConnection
06-11 00:50:02.222: D/webviewglue(823): nativeDestroy view: 0x2a24bdb0
06-11 00:50:22.292: D/AndroidRuntime(823): Shutting down VM
06-11 00:50:22.292: W/dalvikvm(823): threadid=1: thread exiting with uncaught
exception (group=0x40a71930)
06-11 00:50:22.334: E/AndroidRuntime(823): FATAL EXCEPTION: main
06-11 00:50:22.334: E/AndroidRuntime(823): java.lang.NullPointerException
06-11 00:50:22.334: E/AndroidRuntime(823): at
android.webkit.WebViewClassic.stopLoading(WebViewClassic.java:2645)
06-11 00:50:22.334: E/AndroidRuntime(823): at
android.webkit.WebView.stopLoading(WebView.java:895)
06-11 00:50:22.334: E/AndroidRuntime(823): at
org.apache.cordova.CordovaWebView$2.run(CordovaWebView.java:421)
06-11 00:50:22.334: E/AndroidRuntime(823): at
android.os.Handler.handleCallback(Handler.java:725)
06-11 00:50:22.334: E/AndroidRuntime(823): at
android.os.Handler.dispatchMessage(Handler.java:92)
06-11 00:50:22.334: E/AndroidRuntime(823): at
android.os.Looper.loop(Looper.java:137)
06-11 00:50:22.334: E/AndroidRuntime(823): at
android.app.ActivityThread.main(ActivityThread.java:5041)
06-11 00:50:22.334: E/AndroidRuntime(823): at
java.lang.reflect.Method.invokeNative(Native Method)
06-11 00:50:22.334: E/AndroidRuntime(823): at
java.lang.reflect.Method.invoke(Method.java:511)
06-11 00:50:22.334: E/AndroidRuntime(823): at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
06-11 00:50:22.334: E/AndroidRuntime(823): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
06-11 00:50:22.334: E/AndroidRuntime(823): at
dalvik.system.NativeStart.main(Native Method)
{code}
It appears CordovaWebView.handleDestroy() is calling loadUrlIntoView(url) which
reinitialises plugins and spawns a thread to handle potential timeouts.
My stacktrace seems caused by the timeout thread (in CordovaWebView) thinking
that a timeout has occurred (because the flag loadUrlTimeout does not indicate
otherwise)
---
I believe my cleanup code onDestroy() is implemented correctly. If not, then
how should I do it?
BTW, This same problem did not occur in Cordova v2.4
More notes:
* I am suspicious that the problem is introduced by the fix for CB-2458. To
deliberately cause plugin initialization during destruction seems strange.
* I am suspicious that the removal of baseUrl in CB-2534, means the CB-2458 is
maybe not even needed anymore, so perhaps original code can be re-instated.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
