[jira] [Commented] (CB-5037) Cordova fails to fire deviceready on page reload
[ https://issues.apache.org/jira/browse/CB-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931212#comment-13931212 ] Nathan Smith commented on CB-5037: -- This issue also affects 2.5.0 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 Assignee: Andrew Grieve Fix For: 3.2.0 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.2#6252)
[jira] [Commented] (CB-5037) Cordova fails to fire deviceready on page reload
[ https://issues.apache.org/jira/browse/CB-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795199#comment-13795199 ] ASF subversion and git services commented on CB-5037: - Commit 18252a7463823518622ef5aafdc442eda3c796c7 in branch refs/heads/master from [~agrieve] [ https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;h=18252a7 ] CB-5037 Fix bridge sometimes not resetting properly during page transitions 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)
[jira] [Commented] (CB-5037) Cordova fails to fire deviceready on page reload
[ https://issues.apache.org/jira/browse/CB-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793989#comment-13793989 ] Luke Terry commented on CB-5037: [~agrieve] thanks for the quick response and fix - the code change you suggested works. I am conscious that it will ignore valid delayed requests. For us, we are just logging so it isn't major, but for others they may perform some session teardown and then reload. I suppose they should be waiting for any outstanding callbacks before reloading anyway, but since it will explicitly ignore such requests I feel there should be some clear documentation around this behaviour. 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)
[jira] [Commented] (CB-5037) Cordova fails to fire deviceready on page reload
[
https://issues.apache.org/jira/browse/CB-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
