cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joe Bowser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CB-7197) Cordova doesn't always initialize when webview timers start in the paused state
Date Fri, 25 Jul 2014 17:19:39 GMT

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

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

I lowered the priority because there's not a solid repro case, if there was, I would have
left it as a blocker.

> 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.2#6252)

Mime
View raw message