You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cordova.apache.org by "Joe Bowser (JIRA)" <ji...@apache.org> on 2014/09/15 19:32:34 UTC

[jira] [Commented] (CB-7197) Cordova doesn't always initialize when webview timers start in the paused state

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

Joe Bowser commented on CB-7197:
--------------------------------

You should comment about whether this functionality is going to be removed or not on the dev list.

> Cordova doesn't always initialize when webview timers start in the paused state
> -------------------------------------------------------------------------------
>
>                 Key: CB-7197
>                 URL: https://issues.apache.org/jira/browse/CB-7197
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: Android
>    Affects Versions: 3.5.0
>         Environment: Android 4.4.2
>            Reporter: David Almilli
>
> When Cordova pauses the timers before the Activity is destroyed, when you start the Activity back up, it detects it's in the startup phase and doesn't resume the timers if they are starting in the paused state.
> If you look at the javadoc for WebView.pauseTimers() it says that it's a global setting and doesn't just affect that instance of the WebView.
> http://developer.android.com/reference/android/webkit/WebView.html#pauseTimers()
> There are probably several ways to reproduce this which may seem inconsistent because it depends on what the android task manager does and whether it destroys the activities, but keeps the process running or not. I wasn't able to make a simple example though. The way I was reproducing it was by using the camera plugin to take a picture and then hit back repeatedly until it goes to the home screen.  Then I would go back to the launcher icon to start the app again.  It never receives the deviceready event and gets stuck just before it loads the plugins in the cordova.js because it's wrapped in a setTimeout().
> I even had this snipped at the top of the body that (when starting in a broken state) would print "Testing setTimeout", but would *not print* "setTimeout 0 works"
> {noformat}
> 		<script type="text/javascript">
> 			console.log("Testing setTimeout");
> 			setTimeout(function() {
> 				console.log("setTimeout 0 works");
> 			}, 0);
> 		</script>
> {noformat}
> The fix I came up with was at the end of the CordovaActivity.init(...) method add this line:
> {noformat}
>     public void init(CordovaWebView webView, CordovaWebViewClient webViewClient, CordovaChromeClient webChromeClient) {
>         ...
>         this.appView.resumeTimers();
>     }
> {noformat}
> And to be sure that the CordovaWebView doesn't break other WebViews that might be used by a developer, it should resume the timers when it is destroyed so at the end of the CordovaWebView.handleDestory() method add this line:
> {noformat}
>     public void handleDestroy() {
>         ...
>         this.resumeTimers();
>     }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)