[jira] [Comment Edited] (CB-3766) Introduced bug causes Android stacktrace during cleanup of CordovaWebView

["Joe Bowser (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CB-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680814#comment-13680814 ] 

Joe Bowser edited comment on CB-3766 at 6/11/13 11:38 PM:
----------------------------------------------------------

You're suspicious of a lot of things, aren't you?

Why are you calling pause before destroy? I recommend NOT doing that, since you need to send the onDestroy event and you can't do that when the timers are shut down.  In fact, the Activity should be able to mop up the mess, and you don't need to be destroying everything manually.

I have this in our test suite that uses CordovaWebView and it works without a problem.  The firing of onDestroy in JS is handled by handleDestroy():

{code}
    @Override
    /**
     * The final call you receive before your activity is destroyed.
     */
    public void onDestroy() {
        super.onDestroy();
        if (cordovaWebView != null) {
            // Send destroy event to JavaScript
            cordovaWebView.handleDestroy();
        }
    }
{code} 

We removed baseUrl because we removed our weird broken history shim and we now use the browser's history once again.
                
      was (Author: bowserj):
    You're suspicious of a lot of things, aren't you?

Why are you calling pause before destroy? I recommend NOT doing that, since you need to send the onDestroy event and you can't do that when the timers are shut down.  In fact, the Activity should be able to mop up the mess, and you don't need to be destroying everything manually.

I have this in our test suite that uses CordovaWebView and it works without a problem.  In fact, we can probably remove the call to Javascript, since that would be handled by handleDestroy():
{code}
    @Override
    /**
     * The final call you receive before your activity is destroyed.
     */
    public void onDestroy() {
        super.onDestroy();
        if (cordovaWebView != null) {
            // Send destroy event to JavaScript
            cordovaWebView.loadUrl("javascript:try{cordova.require('cordova/channel').onDestroy.fire();}catch(e){console.log('exception firing destroy event from native');};");
            cordovaWebView.handleDestroy();
        }
    }
{code} 

We removed baseUrl because we removed our weird broken history shim and we now use the browser's history once again.
                  
> Introduced bug causes Android stacktrace 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