Skip to main content

Bug Tracker

Side navigation

#11310 closed bug (patchwelcome)

Opened February 08, 2012 06:57PM UTC

Closed August 10, 2012 06:00PM UTC

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:
Description

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.

Attachments (0)
Change History (10)

Changed February 08, 2012 07:00PM UTC by Endeer comment:1

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.

Changed February 09, 2012 03:24PM UTC by sindresorhus comment:2

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.

Changed February 09, 2012 04:57PM UTC by Endeer comment:3

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.

Changed February 09, 2012 05:43PM UTC by dmethvin comment:4

component: unfiledcore
priority: undecidedlow
status: newopen

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.

Changed February 09, 2012 07:37PM UTC by Endeer comment:5

_comment0: 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 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. \ 1329025619880554
_comment1: 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 all three occurences (in jQuery core) 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. \ 1329025640715838

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.

Changed February 09, 2012 07:43PM UTC by Endeer comment:6

_comment0: 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.1328816628274669

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)

Changed February 09, 2012 08:44PM UTC by dmethvin comment:7

#11314 is a duplicate of this ticket.

Changed April 20, 2012 05:23PM UTC by dmethvin comment:8

milestone: None1.8

Changed June 26, 2012 03:02AM UTC by dmethvin comment:9

keywords: → ie6 ie7 ie8 ie9

Changed August 10, 2012 06:00PM UTC by dmethvin comment:10

resolution: → patchwelcome
status: openclosed

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.