Okay, so it wasn't jsFiddle. I did find the line of code in the addthis_widget.js that is causing the issue.
var h,t=navigator.userAgent.toLowerCase(),o=Math.floor(Math.random()*1000);
if(/msie/.test(t)&&!(/opera/.test(t))){
n.innerHTML="<iframe id=\"_atssh"+o+"\" width=\"1\" height=\"1\" title=\"AddThis utility frame\" name=\"_atssh"+o+"\" src=\"\">";
h=document.getElementById("_atssh"+o);
}For some reason adding the iframe like the above is causing document[0] to be populated with the window object. Why? I have no idea and it's only happening if the browser is IE because it is browser sniffing.
Either, this library can update it's code so it doesn't inadvertently update the document or jQuery 1.8 can be more defensive in it's check inside of buildFragment... so, instead of this
// Set context from what may come in as undefined or a jQuery collection or a node
context = context || document;
context = (context[0] || context).ownerDocument || context[0] || context;we can change 1.8 to have something like this instead...
// Set context from what may come in as undefined or a jQuery collection or a node
context = context || document;
context = context instanceof jQuery ? context[0] : context;
context = context.ownerDocument || context;I'll work on getting some unit tests put together and make a pull request with the above change if you all think that is a good thing.
After some trial and error I've found a way to recreate this issue reliably in IE9/10. It was difficult to recreate under normal circumstances, so I used the testIframeWithCallback function and made an test/data/manipulation/iframe-denied.html file to assist in the testing process.
The trick is to create an iframe with a cross-domain source before DOM Ready. The interesting thing about IE9/10 is that anytime you add an iframe or an object to the DOM it will alias it's window object onto the document. For example, after adding an iframe to the DOM you can access that iframe's window object off of document[0].
Yes, that is weird and that is why buildFragment was throwing an exception because it was trying to access context[0], which was the window object from a cross-domain iframe.
I testing this new Unit Test in IE6/7/8/9/10 before I applied the fix and it failed in IE9 & IE10. After applying the following fix the Unit Test passed in IE6/7/8/9/10 as well as all the other unit tests in the manipulation module.
jQuery.buildFragment = function( args, context, scripts ) {
var fragment, cacheable, cachehit,
first = args[ 0 ];
// Set context from what may come in as undefined or a jQuery collection or a node
+ // Updated to fix #12266 where accessing context[0] could throw an exception in IE9/10 &
+ // also doubles as fix for #8950 where plain objects caused createDocumentFragment exception
context = context || document;
- context = (context[0] || context).ownerDocument || context[0] || context;
+ context = context instanceof jQuery ? context[0] : context;
+ context = context.ownerDocument || context;
- // Ensure that an attr object doesn't incorrectly stand in as a document object
- // Chrome and Firefox seem to allow this to occur and will throw exception
- // Fixes #8950
- if ( typeof context.createDocumentFragment === "undefined" ) {
- context = document;
- }
...
};The above change also accounts for the bug fix that was made for #8950 where plain objects caused a createDocumentFragment exception. The above fix passes the unit test added for #8950 which is still present in the manipulation test module. Therefore, we can safely take out the patch for #8950 since the above code accounts for that scenario.
By fixing the security concern related to this issue and removing the fix for #8950, which is no longer needed, it reduces the overall size of jQuery!
Running "compare_size:files" (compare_size) task
Sizes - compared to master
258224 (-51) dist/jquery.js
92551 (-42) dist/jquery.min.js
33117 (-5) dist/jquery.min.js.gz