Guard against Webkit's extraneous calls to xhr.onreadystatechange #633
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
In certain cases Webkit will call the onreadystatechange method of a single XMLHttpRequest object multiple times indicating that it is ready (readyState == 4).
This results in Zepto's 'success' or 'error' methods being called multiple times for the same AJAX request.
This is documented in this thread:
http://stackoverflow.com/questions/12761255/can-xhr-trigger-onreadystatechange-multiple-times-with-readystate-done
with a jsfiddle here:
http://jsfiddle.net/44b3P/
and confirmed here:
http://osdir.com/ml/general/2012-10/msg12396.html
To reproduce in Zepto:
Expected: you should see 1 alert with the text 'error'
Actual: the alert with the text 'error' occurs 3 times
I'm working to find a way to reproduce this and submit upstream (at least to Chrome -- maybe to Webkit? -- We think it's a Webkit bug since we first observed this issue in Safari on iOS 6).
In the meantime this patch should resolve the issue in Zepto.
[1] While this is an awkward way to reproduce (clearly a debugger statement shouldn't be in production code) we've observed similar behavior in our production code where success functions are called multiple times for the same AJAX request -- usually when there's a lot going on on the page or the page hasn't completed loading.
The 'debugger' statement was the most reliable way I've seen to approximate these conditions and reproduce the behavior.