Fixes #8744 #804

wants to merge 2 commits into


None yet

6 participants

jQuery Foundation member

I think its very irritating issue, and with all appearances it will not go away, especially when this error now happening in Chrome too, as said @bzbarsky in here
">. This says to run the script, period. No provisions for it not being in the DOM."

Until spec is changed, browsers free to execute any actions they like, judging by comments (along with solutions for it) in bug tracker, many people irritated about this too, its especially worse in ie.

Yeah, you already said no. But if this pull will be accepted, than you can properly address this issue with "throws" option (or whatever).

btw, with this commit, you partially fixed this "bug", like, is it inconsistent or what?

jQuery Foundation member


jQuery Foundation member

cc @jaubourg can you review this?

jQuery Foundation member

First, using an option to deal with two, unrelated, things is a no-go.

Second, I stand by what was said in the comments: it's a problem with the browsers. Whether the spec is precise enough or not, fact is FF is doing something stupid and the change of behaviour in Chrome is a regression. Let's be clear here: if browser vendors keep on going that way (executing scripts that were removed from the DOM), they just decided to kill JSONP, if not dynamic script loading altogether, whether they realize it or not.

It seems obvious browser vendors are pushing for CORS, a "solution" that necessitates changes server-side, as an alternative to script tag injection. Problem is the use case is not the same at all (ie. requesting from a third-party server you have no tie with to begin with). When will standard body look at what's happening in the wild? If they cannot make script tag injection at the very least practical, then why not provide some other means to load a script?

As a matter of fact, Orkel just reminded me the fix for the global namespace pollution will make matters worse (as a JSONP request will be able to call the callback of another, future, JSONP request).


The spec is quite precise, and Firefox is doing exactly what the spec requires. So if you want some other sort of behavior here you need to get out there and get the spec changed.

jQuery Foundation member

A reading from the spec is always appreciated, @bzbarsky. Even if the spec is an ass it seems like an ass we have to handle for the moment. This job requires excellent ass-handling skills.

I agree with @jaubourg that it seems inappropriate to use .throws here as well since it's about whether we throw an error on a cross-domain script request encountered while parsing HTML. That is unrelated to this issue about JSONP.

And yes since we're trying to reuse jsonp callbacks now to reduce memory "leaks", this patch is going to cause problems since it will allow inadvertent reuse of callbacks. @orkel would you agree that problem prevents us from landing this pull request as-is?


A reading from the spec is always appreciated

It's linked to in the very first comment of this discussion....

jQuery Foundation member


The script is only loaded & executed if the script tag is added to the DOM, on that the spec is precise (as it should be given it's all a question of execution order being DOM order). On what happens if the script is not in the DOM when it has been loaded, the spec says nothing (unless I missed something). It seems all browsers except Firefox (until very recently at least) will apply some parallelism and not execute the script. I don't remember older versions of Firefox exhibiting this behaviour (and by older I mean from 2 years ago when I was working quite heavily on jQuery-JSONP) but I could be wrong.

So, I never said Firefox didn't comply with the spec, I just said complying with a spec is sometimes not enough, especially when backward compatibility and common sense are involved.

For instance, Opera does comply with the spec by respecting script execution order even if they were not added to the DOM in the same order (I actually use that in jQuery-JSONP) yet will not execute the script if the corresponding script tag is not in the DOM anymore (last I checked at least).

Please, try and consider the incessant juggling we have to do on a daily basis between all vendors implementations, current-spec-compliant, future-spec-compliant and others. We cannot possibly survey all the specs beforehand. What we have then are separate bug trackers, one for each vendor if not each version of each browser. I can understand when bugs are closed with a laconic "we're spec compliant", but could we, sometimes, get to the gist of things: how can I time out a script loaded through script tag injection ? I can't ? I could before. Doesn't that sound like a regression to you ? Shouldn't spec compliance and correcting regressions be considered both (especially when they don't contradict one another like in the current case)?


On what happens if the script is not in the DOM when it has been loaded, the spec says nothing

Indeed. So there is no special handling. The spec editor has been very insistent about that for this spec: no reading between the lines should ever be needed or performed. If the spec says to do something, you do it. If it says to not do something, you don't do it. In this case, the spec says to execute the script, with no mention of whether it's in the DOM at the time or not.

don't remember older versions of Firefox exhibiting this behaviour

There were a lot of changes in the details of script handling involved in switching to the HTML5 parser, yes. This may have been one of them.

I just said complying with a spec is sometimes not enough

If it's not, then by definition the spec is wrong and needs to be changed. The whole point of having a spec is that complying with the spec needs to be enough. That's why specs exist!

how can I time out a script loaded through script tag injection

As the spec is written right now, you can't.

especially when they don't contradict one another

The problem is that in this case they do. The spec says the script needs to run. Not running it would be a spec violation.

Note that I did raise this issue on the relevant mailing list back when. There seemed to be not much interest from anyone else, so it went nowhere. If there is interest, I suggest people find that thread in the archives and follow up....

jQuery Foundation member

@bzbarsky Do you recall if this was in one of the massive (about 100 message) threads that spanned several months? I think there were two of them. If so, those should be relatively easy to find.


Hmm. Actually, looks like sicking was the one who started the thread. It's at and following.

jQuery Foundation member
@orkel would you agree that problem prevents us from landing this pull request as-is?

Thanks for asking before closing and sorry for the late response.

First, using an option to deal with two, unrelated, things is a no-go.

Yeah, they not related and it's inappropriate, this is what i'm trying to do here – make it related and appropriate.
I was hoping throws can have two purposes, it's matter of definition isn't it?

By my opinion – for developers that care about its app and for their owners, unexpected exception is red flag.

I hate to see when users (myself included) trying to workaround this issue, often using erroneous workaround
(just like me one time), this workarounds might generate more serious problems then uncatchable exception and it makes jsonp module (in most cases) unpreferred to use as-is, especially, when problem exist in modern browsers.

So i know – this fix is not a fix, it just makes this problem hidden, nothing more, although, solution that i suggest, is the same solution that was proposed many times before, but in different forms

Keep spec as it is. Pages can simply ignore the JSONP callback when it happens.

I trying to make jQuery ignore it, i don't like that browsers can't abort requests (Chrome can, but only for the same domain, for some reason), and there is no way to prevent script execution (Gecko can, as per spec, with beforescriptexecute event, but only in Gecko).
But what i really don't like – that damn exception, that i can't catch.

I can't see another way to fix it (actually i can, but it more radical than this) and i don't believe that browsers and spec will show us, in near future, more usable behavior, users (myself included) have a problem right now and i think it should be addressed right now, until more acceptable solution will come along.

Anyway, this is what i think, i was fine with decision for previous PR and i will be fine with you closing this one.

jQuery Foundation member


No, you cannot use the same option for two different things especially given they concern the same transport in the end (script). Again, it's a no go.

I share your frustration here, but the only acceptable fix is to make it impossible to abort jsonp/script requests for cross-domain (which means making it impossible to timeout). No matter how we look at things, it simply cannot be done in a proper and reliable fashion.

This is a nasty regression from within the spec and I'm really saddened that:
1. it didn't get to the jQuery AJAX maintainer's ears in time
2. no one involved in the spec discussions seemed to entertain checking js library code (Dojo, Prototype, jQuery, ...)

Now, we have to make do with this mess and the only sensible solution is to propagate the regression to our end users. Any trick we can use will only hinder problems in end-user code and be the root of nasty bugs.

jQuery Foundation member

Okay I think we agreed that there are too many issues with this one, perhaps we can revisit later.

@dmethvin dmethvin closed this Jun 16, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment