[
https://issues.apache.org/jira/browse/CB-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793182#comment-13793182
]
Andrew Grieve commented on CB-5037:
-----------------------------------
Great analysis! Thanks for digging into this. Tricky thing with this bug is
that you're in the best position to verify a fix for it. I've taken a stab at a
fix. Would you be able to try it out?
Within CDVCommandQueue.m, change `maybeFetchCommandsFromJs:` to:
{code}
- (void)maybeFetchCommandsFromJs:(NSNumber*)requestId
{
NSInteger rid = [requestId integerValue];
// An ID of 1 is a special case because that signifies the first request of
// the page. Since resetRequestId is called from webViewDidStartLoad, and
the
// JS context at the time of webViewDidStartLoad is still that of the
previous
// page, it's possible for requests from the previous page to come in after
this
// point. We ignore these by enforcing that ID=1 be the first ID.
if ((_lastCommandQueueFlushRequestId == 0) && (rid != 1)) {
CDV_EXEC_LOG(@"Exec: Ignoring exec request from previous page.");
return;
}
// Use the request ID to determine if we've already flushed for this
request.
// This is required only because the NSURLProtocol enqueues the same request
// multiple times.
if (rid > _lastCommandQueueFlushRequestId) {
_lastCommandQueueFlushRequestId = [requestId integerValue];
[self fetchCommandsFromJs];
}
}
{code}
> Cordova fails to fire deviceready on page reload
> ------------------------------------------------
>
> Key: CB-5037
> URL: https://issues.apache.org/jira/browse/CB-5037
> Project: Apache Cordova
> Issue Type: Bug
> Components: iOS
> Affects Versions: 3.0.0
> Environment: iOS 5.
> Device or Network plugins (any plugin that adds itself as a dependency to the
> deviceready event).
> Reporter: Luke Terry
>
> Reproduction Steps:
> # Create a new cordova project for iOS
> # Add the Device and Network plugins
> # Add a logging plugin of some kind
> # Add client code that calls the logging plugin before issuing a
> window.location.reload(). In our situation we have lots of logging happening
> just before we do a reload.
> Expected Results:
> The application reloads, successfully invoking the deviceready event.
> Actual Results:
> The application reloads but is stopped waiting for deviceready.
> Cause:
> Race condition on request ID reset.
> Let the first instance of cordova be instanceA and the second instance of
> cordova be instanceB.
> # instanceA issues commands that are queued to be handled by the native
> bridge.
> # instanceA reloads the page.
> # The native bridge handles webViewDidStartLoad and resets the largest
> request ID to 0.
> # The native bridge continues to process the large queue from instanceA
> incrementing the largest request ID to X (perhaps the XHR request has come in
> after the webViewDidStartLoad is handled?)
> # instanceB starts up,
> # The Device plugin for instanceB tries to getDeviceInfo,
> # The native bridge sees the instanceB request with ID 0 and ignores it
> because it is less than request ID X.
> # The Device plugin never gets a callback and therefore prevents the
> deviceready event from firing.
> Possible Solutions:
> # Cordova should make an initial XHR request to reset the request ID on the
> native bridge. Perhaps "gap_init" instead of "gap_exec".
--
This message was sent by Atlassian JIRA
(v6.1#6144)
