Apache Cordova
  1. Apache Cordova
  2. CB-164

On location.reload(), onDeviceReady() function is not firing in Android

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3.0
    • Fix Version/s: 1.7.0
    • Component/s: Android
    • Labels:
      None

      Description

      When the page is loaded onDeviceready() function is fired ,
      when i tried to reload the page using location.reload() it is not
      fired.

      Note : It is working fine when i used PhoneGap-0.9.5.js

        Activity

        Hide
        Hayden Shaw added a comment -

        I can confirm this issue also. However after repeated clicks it sometimes works.

        Show
        Hayden Shaw added a comment - I can confirm this issue also. However after repeated clicks it sometimes works.
        Hide
        Joe Bowser added a comment -

        May be fixed with CB-190 work and change in how history is managed.

        Show
        Joe Bowser added a comment - May be fixed with CB-190 work and change in how history is managed.
        Hide
        Simon MacDonald added a comment -

        I can still reproduce this in 1.6.0rc1. However it doesn't seem to have any negative consequences as PhoneGap commands still work.

        Show
        Simon MacDonald added a comment - I can still reproduce this in 1.6.0rc1. However it doesn't seem to have any negative consequences as PhoneGap commands still work.
        Hide
        Bryce Curtis added a comment -

        The reason deviceready isn't firing is because onCordovaConnectionReady isn't firing. The problem appears to be that NetworkConnection.getInfo() isn't called from native side.

        Show
        Bryce Curtis added a comment - The reason deviceready isn't firing is because onCordovaConnectionReady isn't firing. The problem appears to be that NetworkConnection.getInfo() isn't called from native side.
        Hide
        Joe Bowser added a comment -

        That doesn't seem to be it. If I put a breakpoint on the onPageFinished, it fires. I'm thinking that there's a JS issue behind this.

        Show
        Joe Bowser added a comment - That doesn't seem to be it. If I put a breakpoint on the onPageFinished, it fires. I'm thinking that there's a JS issue behind this.
        Hide
        Joe Bowser added a comment -

        Actually, no. Here's the offending error:

        D/CordovaLog(19514): JSCallback Error: Request failed.
        D/CordovaLog(19514): file:///android_asset/www/cordova-1.6.1.js: Line 3553 : JSCallback Error: Request failed.
        I/Web Console(19514): JSCallback Error: Request failed. at file:///android_asset/www/cordova-1.6.1.js:3553
        D/dalvikvm(19514): GC_CONCURRENT freed 17K, 2% free 15147K/15303K, paused 6ms+1ms

        If we can't get the callback server, how are we going to do onDeviceReady?

        Show
        Joe Bowser added a comment - Actually, no. Here's the offending error: D/CordovaLog(19514): JSCallback Error: Request failed. D/CordovaLog(19514): file:///android_asset/www/cordova-1.6.1.js: Line 3553 : JSCallback Error: Request failed. I/Web Console(19514): JSCallback Error: Request failed. at file:///android_asset/www/cordova-1.6.1.js:3553 D/dalvikvm(19514): GC_CONCURRENT freed 17K, 2% free 15147K/15303K, paused 6ms+1ms If we can't get the callback server, how are we going to do onDeviceReady?
        Hide
        Joe Bowser added a comment -

        Looked into this. The Callback Server doesn't comeback fast enough anymore for loading multiple pages. Not sure what we should do at this point, since it seems like it's more of a Callback Server bug and a nasty one at that.

        Show
        Joe Bowser added a comment - Looked into this. The Callback Server doesn't comeback fast enough anymore for loading multiple pages. Not sure what we should do at this point, since it seems like it's more of a Callback Server bug and a nasty one at that.
        Hide
        Joe Bowser added a comment -

        Need help with JS events, The bug looks asynchronous and hard!

        Show
        Joe Bowser added a comment - Need help with JS events, The bug looks asynchronous and hard!
        Hide
        Filip Maj added a comment -

        Bryce is right. It looks like the CordovaConnectionReady Channel is not being fired during JS bootup.

        It looks like the JS is waiting for the callback server to respond to the Network Status connection info request. Eventually times out. I also see this in my logcat:

        W/webview ( 9324): java.lang.Throwable: Warning: A WebView method was called on thread 'Thread-5329'. All WebView methods must be called on the UI thread. Future versions of WebView may not support use on other threads.
        W/webview ( 9324): 	at android.webkit.WebView.checkThread(WebView.java:9355)
        W/webview ( 9324): 	at android.webkit.WebView.stopLoading(WebView.java:2198)
        W/webview ( 9324): 	at org.apache.cordova.DroidGap$1$1.run(DroidGap.java:410)
        W/webview ( 9324): 	at java.lang.Thread.run(Thread.java:856)
        E/DroidGap( 9324): DroidGap: TIMEOUT ERROR! - calling webViewClient
        D/CordovaLog( 9324): JSCallback Error: Request failed. HTTP status: 0
        D/CordovaLog( 9324): file:///android_asset/www/cordova.android.js: Line 3558 : JSCallback Error: Request failed. HTTP status: 0
        I/Web Console( 9324): JSCallback Error: Request failed. HTTP status: 0 at file:///android_asset/www/cordova.android.js:3558
        

        Will investigate tomorrow if the exec request for the network status is making its way into native, and dig deeper into the issue from there.

        Show
        Filip Maj added a comment - Bryce is right. It looks like the CordovaConnectionReady Channel is not being fired during JS bootup. It looks like the JS is waiting for the callback server to respond to the Network Status connection info request. Eventually times out. I also see this in my logcat: W/webview ( 9324): java.lang.Throwable: Warning: A WebView method was called on thread 'Thread-5329'. All WebView methods must be called on the UI thread. Future versions of WebView may not support use on other threads. W/webview ( 9324): at android.webkit.WebView.checkThread(WebView.java:9355) W/webview ( 9324): at android.webkit.WebView.stopLoading(WebView.java:2198) W/webview ( 9324): at org.apache.cordova.DroidGap$1$1.run(DroidGap.java:410) W/webview ( 9324): at java.lang.Thread.run(Thread.java:856) E/DroidGap( 9324): DroidGap: TIMEOUT ERROR! - calling webViewClient D/CordovaLog( 9324): JSCallback Error: Request failed. HTTP status: 0 D/CordovaLog( 9324): file:///android_asset/www/cordova.android.js: Line 3558 : JSCallback Error: Request failed. HTTP status: 0 I/Web Console( 9324): JSCallback Error: Request failed. HTTP status: 0 at file:///android_asset/www/cordova.android.js:3558 Will investigate tomorrow if the exec request for the network status is making its way into native, and dig deeper into the issue from there.
        Hide
        Joe Bowser added a comment - - edited

        The webview error is a red herring and is from loadUrlIntoView, which actually isn't called at all when you use location.reload(). I recommend adding logs to the callback server and seeing what is being passed out and whether it makes it. The onCordovaConnectionReady is being called, and is coming back out, but it's not actually being read it seems.

        Show
        Joe Bowser added a comment - - edited The webview error is a red herring and is from loadUrlIntoView, which actually isn't called at all when you use location.reload(). I recommend adding logs to the callback server and seeing what is being passed out and whether it makes it. The onCordovaConnectionReady is being called, and is coming back out, but it's not actually being read it seems.
        Hide
        Filip Maj added a comment -

        Changing the Network plugin to a synchronous plugin and removing setKeepCallback(true) on the PluginResult seems to fix it on my end.

        Once the back button issue is resolved I'll commit it.

        Show
        Filip Maj added a comment - Changing the Network plugin to a synchronous plugin and removing setKeepCallback(true) on the PluginResult seems to fix it on my end. Once the back button issue is resolved I'll commit it.
        Hide
        Filip Maj added a comment -

        Resolved by changing Network plugin to synchronous (from async). The actual exec flow within the plugin does not need to be async (I'm pretty sure - correct me if I'm wrong there). Some combination of using setKeepCallback(true) on a PluginResult that returns immediately + running the plugin's exec method on a different thread (async) causing the issue.

        Fixed in 31d5a9.

        Show
        Filip Maj added a comment - Resolved by changing Network plugin to synchronous (from async). The actual exec flow within the plugin does not need to be async (I'm pretty sure - correct me if I'm wrong there). Some combination of using setKeepCallback(true) on a PluginResult that returns immediately + running the plugin's exec method on a different thread (async) causing the issue. Fixed in 31d5a9 .
        Hide
        Filip Maj added a comment -

        Simon found out that changing networks isn't updating the JS side properly.

        Reopening the issue for now until I patch it properly. Sorry all!

        Show
        Filip Maj added a comment - Simon found out that changing networks isn't updating the JS side properly. Reopening the issue for now until I patch it properly. Sorry all!
        Hide
        Filip Maj added a comment -

        Fixed this properly in 81059b.

        Added back setKeepCallback(true) so that changes in network connectivity send the response back to the proper callback in JS. Left the plugin as synchronous, to fix this issue.

        Show
        Filip Maj added a comment - Fixed this properly in 81059b . Added back setKeepCallback(true) so that changes in network connectivity send the response back to the proper callback in JS. Left the plugin as synchronous, to fix this issue.
        Hide
        Simon MacDonald added a comment -

        Cool, I've tried it out on my side and everything is back to working. The on/offline events fire and navigator.network.connection.type is being set properly as you move from network type to network type. I'm not 100% sold on changing this to sync but a) it fixes the bug and b) the initial call into the NetworkManager does a:

        NetworkInfo info = sockMan.getActiveNetworkInfo();

        which should be pretty fast. This change is early enough in the 1.7.0 that we should be able to give it lots of soak time.

        Show
        Simon MacDonald added a comment - Cool, I've tried it out on my side and everything is back to working. The on/offline events fire and navigator.network.connection.type is being set properly as you move from network type to network type. I'm not 100% sold on changing this to sync but a) it fixes the bug and b) the initial call into the NetworkManager does a: NetworkInfo info = sockMan.getActiveNetworkInfo(); which should be pretty fast. This change is early enough in the 1.7.0 that we should be able to give it lots of soak time.

          People

          • Assignee:
            Filip Maj
            Reporter:
            Simon MacDonald
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development