Apache Cordova
  1. Apache Cordova
  2. CB-1296

deviceready event is never fired on iOS 4.2.1

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.1.0
    • Fix Version/s: 2.1.0
    • Component/s: CordovaJS, iOS
    • Labels:
      None
    • Environment:

      iOS 4.2.1 (iPod Touch 2nd Gen)

      Description

      deviceready event is never fired on iOS 4.2.1.

      Debugging this, I found that the problem is onCordovaConnectionReady is never fired, the deviceready channel is waiting for this event before it fires.

        Activity

        Hide
        Shazron Abdullah added a comment - - edited

        The onCordovaConnectionReady event is dependent on the getInfo call, which in turns calls the NetworkStatus plugin's "getConnectionInfo" method. The event is not fired if the method never returns - which is the source of the bug.

        The calls are relayed to the exec method, which uses the xhr bridge mode. I verified that the xhrs are sent, then I logged the corresponding response in CDVURLProtocol. No JavaScript exceptions are thrown regarding the xhrs.

        For iOS 5, these calls are sent in succession and are received in the native side:

        1. [["NetworkStatus0","NetworkStatus","getConnectionInfo",[]]]
        2. [["Device1","Device","getDeviceInfo",[]]]

        For iOS 4.2.1, the same calls are sent in succession, BUT only this message is received in the native side:

        1. [["Device1","Device","getDeviceInfo",[]]]

        Somehow the NetworkStatus call just disappears without a trace. I will try querying the xhr status next to see what's going on.

        Show
        Shazron Abdullah added a comment - - edited The onCordovaConnectionReady event is dependent on the getInfo call, which in turns calls the NetworkStatus plugin's "getConnectionInfo" method. The event is not fired if the method never returns - which is the source of the bug. The calls are relayed to the exec method, which uses the xhr bridge mode. I verified that the xhrs are sent, then I logged the corresponding response in CDVURLProtocol. No JavaScript exceptions are thrown regarding the xhrs. For iOS 5, these calls are sent in succession and are received in the native side: [["NetworkStatus0","NetworkStatus","getConnectionInfo",[]]] [["Device1","Device","getDeviceInfo",[]]] For iOS 4.2.1, the same calls are sent in succession, BUT only this message is received in the native side: [["Device1","Device","getDeviceInfo",[]]] Somehow the NetworkStatus call just disappears without a trace. I will try querying the xhr status next to see what's going on.
        Hide
        Shazron Abdullah added a comment -

        I confirmed by setting the bridge mode back to IFRAME_NAV, everything works fine:
        exec.setJsToNativeBridgeMode(exec.jsToNativeModes.IFRAME_NAV);

        Show
        Shazron Abdullah added a comment - I confirmed by setting the bridge mode back to IFRAME_NAV, everything works fine: exec.setJsToNativeBridgeMode(exec.jsToNativeModes.IFRAME_NAV);
        Hide
        Andrew Grieve added a comment -

        Fixed it by just setting the default bridge mode to IFRAME for 4.x devices.

        commit: https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commit;h=b17e8cdf69b067f9fc7326164b5dbdea307ae85f

        I updated the pre-built JS in the ios repo as well.

        While debugging this, I did find that changing the XHR from a HEAD request to a GET made the request show up in the URIProtocol. It then properly made its way over to the UI thread to execute the plugin. It would go into deadlock at that point though, so I stopped pursuing it. IFRAME bridge mode is faster anyway and doesn't have any bugs that it triggers on 4.x

        Show
        Andrew Grieve added a comment - Fixed it by just setting the default bridge mode to IFRAME for 4.x devices. commit: https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commit;h=b17e8cdf69b067f9fc7326164b5dbdea307ae85f I updated the pre-built JS in the ios repo as well. While debugging this, I did find that changing the XHR from a HEAD request to a GET made the request show up in the URIProtocol. It then properly made its way over to the UI thread to execute the plugin. It would go into deadlock at that point though, so I stopped pursuing it. IFRAME bridge mode is faster anyway and doesn't have any bugs that it triggers on 4.x

          People

          • Assignee:
            Shazron Abdullah
            Reporter:
            Shazron Abdullah
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development