Side navigation
#14500 closed feature (wontfix)
Opened October 31, 2013 07:07AM UTC
Closed December 08, 2013 03:47PM UTC
Enable global events for cross browser requests
Reported by: | Marc-André Lafortune <jquery@marc-andre.ca> | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | unfiled | Version: | 1.10.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
The problem
To my surprise, "Global events are never fired for cross-domain script or JSONP requests, regardless of the value of global."
In my case, this surfaced when an ajaxComplete callback was not fired after a $.getScript. This only happend on my production server because I use a CDN there, but not in development.
I feel that the fact that behavior of ajaxComplete changes depending on the domain of the request is counter intuitive, counter productive and difficult to bypass.
Why?
I could not find an official reason for the current behavior. First I thought maybe security was a reason, but I can't see how executing a native callback could be less secure than executing a cross-browser script in the first place.
Second I read that error conditions can not always be detected properly when doing cross browser requests. Still, that would not make more sense than not executing .fail / .done when the request is crossbrowser. I feel that .done / complete/ ajaxComplete should go hand in hand, same with errors and always.
Circumvention
Finally, it is cumbersome to circumvent this misaligned "feature". One must use the low-level interface call to ajaxPrefilter.
First, I first tried to add .done and .fail handlers to the xhr object in ajaxPrefilter, but that doesn't work perfectly because the order in which they fire compared to the callbacks specified just after the point of call changes.
It turns out that resetting the global flag to true works. Still, you have to be careful to set it if need be, but without overriding the original option global: false if it was given.
Solution?
There are different ways to improve the situation.
Ideally, I'd say not to clear the global flag for cross-browser requests. The API would be intuitive and consistent with local callbacks.
If incompatibilities are feared (even though I can't see who would need the current behavior), then a global option can be created, or simply the 'ajaxComplete' & al. events can be namespaced in case of crossbrowser requests:
$(document).on('ajaxComplete', ...) // Callback only for same origin requests $(document).on('ajaxComplete.crossBrowser', ...) // Callback only for all requests, even cross browser ones
Hope I didn't ramble on too much.
Thanks
Attachments (0)
Change History (3)
Changed October 31, 2013 07:10AM UTC by comment:1
Changed November 10, 2013 07:21PM UTC by comment:2
When used cross-domain the script is retrieved/executed using a <script>
tag. When a local request is made it uses XHR and has more control available for events. In retrospect there's a bit too much opaque magic going on here but there isn't much we can do about history. Longer term we are looking to change the API to make it clearer when XHR vs JSONP/<script>
are being used.
I think more special cases here will just tend to break old code and make things worse.
Changed December 08, 2013 03:47PM UTC by comment:3
resolution: | → wontfix |
---|---|
status: | new → closed |
PS: The fact that resetting global to true works is contrary to the doc, so the circumvention I'm using is not even guaranteed in the future!