I would also like to point out, that I had to register to post this, because even after passing captcha, the bug tracker said "maximum number of posts from this IP per hour exceeded". This is my first post, and I even tried using IP which is not used by anyone. The error message is thus misleading.

Thanks for taking the time to contribute to the jQuery project! I'm sorry you're having problems with the bug tracker, we know about the problem.

The "defer" attribute is very quirky on <=IE9. jQuery might be triggering it, but it such a new issue that it's not thoroughly defined yet. The consensus seems to be:

don't use defer for external scripts that can depend on eachother if you need IE <= 9 support

A good discussion about it here.

Hello,

thanks for reply. The issue is that if the bug is triggered, the content of the "defer" script doesn't get loaded at all, ever. If I define a function in the deferred .js file, and try to call it after clicking a button, it will still not be defined, it's not a timing or onready/onload issue.

The reason I'm trying to use "defer" is that I'm making a script which will provide some data to other websites, but is not crucial for them, so I would like to avoid that should our server have an outage, those other websites would block loading.

I won't have control over where they place the script, so I can't dictate it should be right before </body>, so I thought I might solve this by using <script async defer src=...>

I'm also aware I could create the <script> tag dynamically, but that would make the original simple <script ...></script> into a few lines of JS code, which I'd be a bit uneasy pasting into wysiwyg editors, and it's gonna happen.

Still I think this should be fixed. I might try to have a look into what changed between 1.7.0. and 1.7.1, if I could perhaps contribute a fix, but can't promise anything now.

I suspect it has something to do with the changes in our feature detection in support.js but that is just a guess. If you are interested in investigating that would be great.

You were right, I also noticed some talk about "fake body" when trying to google anything on the defer issue.

The problems occurs in the support check, specifically in the section "Run tests that need a body at doc ready". A <div> is created for the testing purposes and the issue described in this bug report is triggered by assigning non-blank string to test element's innerHTML (div.innerHTML in the code).

The bug can be avoided by changing (in jQuery core) all three occurences of

div.innerHTML = something_not_blank;

to

container.removeChild(div);

div.innerHTML = something;

container.appendChild(div);

Though I'm not very sure that's the proper solution, even though the support test results seemed the same. Tested with 1.7.2b1.

Also noticed that the bug occurs ~99% of the time in IE6-7 and only ~20% of the time in IE8 (don't have IE9 at hand right now), so if anyone's trying to reproduce it, I recommend IE6-7.

(sorry for double post, noticed the Edit too late)

#11314 is a duplicate of this ticket.

I don't see how we can fix this. See this thread for details:

https://github.com/paulirish/lazyweb-requests/issues/42

Even if our support.js code could avoid touching the document by making feature detects as lazy as possible, that would just turn it into a non-deterministic race that depended on user code calling jQuery features that triggered the lazy feature detects, or their own code doing a manipulation.

If anyone has a suggestion, please let us know. Fortunately, the best practice of CSS at the top and scripts at the bottom will generally prevent this from being a problem.