Bug Tracker

Modify

Ticket #11310 (closed bug: patchwelcome)

Opened 2 years ago

Last modified 21 months ago

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:
Blocking: Blocked by:

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.

Change History

comment:1 Changed 2 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 2 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 2 years ago by Endeer

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.

comment:4 Changed 2 years ago by dmethvin

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

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 2 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 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.

Version 1, edited 2 years ago by Endeer (previous) (next) (diff)

comment:6 Changed 2 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 2 years ago by Endeer (previous) (diff)

comment:7 Changed 2 years ago by dmethvin

#11314 is a duplicate of this ticket.

comment:8 Changed 2 years ago by dmethvin

  • Milestone changed from None to 1.8

comment:9 Changed 22 months ago by dmethvin

  • Keywords ie6 ie7 ie8 ie9 added

comment:10 Changed 21 months ago by dmethvin

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

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.

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.