Bug Tracker

Opened 4 years ago

Closed 3 years ago

#11310 closed bug (patchwelcome)

Script tag with defer not processed in Explorer

Reported by: Endeer Owned by:
Priority: low Milestone: 1.8
Component: core Version: 1.7.1
Keywords: ie6 ie7 ie8 ie9 Cc:
Blocked by: Blocking:


I've stumbled upon an issue which manifests in IE6,7,8,9 for me (other versions not tested).

Including <script defer src="something.js"> after including jQuery will cause the content of something.js not to be processed - defined functions will not be available, direct code will not be executed.

This happens only most of the time - e.g. after the page is loaded once, you click on location bar and press enter, the bug will probably not occur, but F5/Ctrl-F5 triggered it about every time for me.

Example is available here: http://www.endeer.cz/iebug/2/ It should alert("X").

This occurs only with 1.7.1, and not in 1.7.0 or 1.4.2 which I tested. Replacing the included jQuery with any of these other version will cause the alert() to pop up every time.

Change History (10)

comment:1 Changed 4 years ago by Endeer

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.

comment:2 Changed 4 years ago by sindresorhus

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.

comment:3 Changed 4 years ago by Endeer


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.

comment:4 Changed 4 years ago by dmethvin

  • Component changed from unfiled to core
  • Priority changed from undecided to low
  • Status changed from new to open

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.

comment:5 Changed 4 years ago by Endeer

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;


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.

Last edited 4 years ago by Endeer (previous) (diff)

comment:6 Changed 4 years ago by Endeer

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)

Last edited 4 years ago by Endeer (previous) (diff)

comment:7 Changed 4 years ago by dmethvin

#11314 is a duplicate of this ticket.

comment:8 Changed 4 years ago by dmethvin

  • Milestone changed from None to 1.8

comment:9 Changed 3 years ago by dmethvin

  • Keywords ie6 ie7 ie8 ie9 added

comment:10 Changed 3 years ago by dmethvin

  • Resolution set to patchwelcome
  • Status changed from open to closed

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


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.

Note: See TracTickets for help on using tickets.