Also, I could not find the documentation part that talk about the weird (but needed I guess) ?51651321 added to every <script> inserted in AJAX.

Sorry, I can't repro on your jsbin test case with IE9. http://i.imgur.com/EhJOv.png

Can you try with the current code and see if the problem is still there for you? http://code.jquery.com/jquery-git.js

In general, it's **not a good idea** to design pages that load scripts this way. Use $.getScript() or use a script loader rather than injecting HTML that happens to have script tags.

Thanks for answering so fast.

First, using latest jquery as you provided does not solves it: http://www.webpagetest.org/result/121213_4J_60683a5c9b7256e109b54801a1b9390a/1/details/.

Second,

All I can say is that you should try harder (sorry really).

As I said and prove (see WPT links for IE8 working well sometimes), this is not happening everytime so this must be based on a timer or something.

Here's another catch using HTTPWatch on IE9, http://i.imgur.com/e4IHa.png

And using IE9 developper tools http://i.imm.io/OZpq.png

Yes its not a good idea but this is a regression since it should work as the docs says:

"html": Returns HTML as plain text; included script tags are evaluated when inserted in the DOM.

from http://api.jquery.com/jQuery.ajax/

Using jQuery.load this way is perfectly fine, I mean I never stumbled accross a "jQuery best practice" saying that we should not do that.

The docs of jQuery.ajax even says that if there's a <script> in it it will work fine since it will be evaluating it so why not doing it? (I'm trying to find justification why some people are doing it)

Yes this is a bad practice but a lot of people are doing this in production.

All I can say is that you should try harder (sorry really).

I can see that it occurred from the webpagetest traces. I can mark this open but since I can't repro it the ticket will probably not get any action. If you can repro it consistently you could trace through jQuery and see where the problem is occurring.

Replying to [comment:4 dmethvin]:

> All I can say is that you should try harder (sorry really). I can see that it occurred from the webpagetest traces. I can mark this open but since I can't repro it the ticket will probably not get any action. If you can repro it consistently you could trace through jQuery and see where the problem is occurring.

I'll try to do that yes. It seems very strange that you could NEVER reproduce it even after many reloads (and cache busting) ?

@vvo, still waiting on further analysis from you. I tried doing some debugging but the test case is using the compressed jquery and when I tried switching it to the uncompressed version on the jQuery CDN I was getting errors from jsbin.

As far as *why* it's requested twice, you can see the reason in the webpagetest.org traces:

http://cdnjs.cloudflare.com/ajax/libs/jquery-cookie/1.2/jquery.cookie.min.js
http://cdnjs.cloudflare.com/ajax/libs/jquery-cookie/1.2/jquery.cookie.min.js?_=1355420580018

Since the two requested URLs have different query strings the browser doesn't use the previously requested version.

Hello, so I did a lot of digging.

First you'll find a jquery fork with an simple example to reproduce the bug here: https://github.com/vvo/jquery/tree/double_script_bug.

Here I copy paste my commit log:

What I have found:

The double script bug is easily reproductible.

• Clear your browser cache
• Use any network observer
• cd jquery, launch http-server . -p 80 (npm install http-server)
• browse with IE9 and network observer to http://ip:80
• see double script loading. One for script.js, other for

script.js?timestamp

The javascript is not executed two times, only once.

But still it is loaded twice!

I used "blind man debugging" (putting returns and reloading the page

untill no more script/only one script loads)

I tracked down the first javascript load (script.js) to be done by:

https://github.com/vvo/jquery/blob/double_script_bug/src/manipulation.js#L284:

fragment = jQuery.buildFragment( args, this[ 0

].ownerDocument, false, this );

This function will create a new dom fragment element using the ajax

request response text. If you return; just before this call, of course

your page will fail but you'll see that there's no more script loaded.

Then if you return just after, you'll see that there's the script.js

loaded.

The second load of scirpt.js?timestamp is done by the append function:

https://github.com/vvo/jquery/blob/double_script_bug/src/manipulation.js#L111

this.appendChild( elem );

So, creating a fragment with a <script src> in it will download the

script once, then appending will download the script again (with a

timestamp added, the timestamp is not a problem, this is the standard

jQuery procedure of loading <scripts> in ajax calls)

What we should do I guess is replace() just before creating the fragment

to pre-add the timestamp to the script.

As I just discovered jQuery core, I need some advice here.

[[Image(http://dl.dropbox.com/u/3508235/7IE9%20test%20%5BRunning%5D%20-%20Oracle%20VM%20VirtualBox_006.png)]]

In IE, script loading starts right after script element became a DOM-node, execution however, happens only after it's attached to the document – http://jsfiddle.net/YR5ar/, that's what happens in

jQuery.buildFragment

, fixing that, would require manipulation of the argument string, which seems as overkill for that case.