Bug Tracker

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#11507 closed bug (invalid)

$(document).ready() does not work with Internet Explorer 8 any more

Reported by: Umanu Owned by: Umanu
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:



Whenever you include jQuery 1.7.x into a website and call $(document).ready(), Internet Explorer 8 crashes with the following error:

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E) Timestamp: Thu, 22 Mar 2012 22:49:16 UTC Message: Object expected
Line: 5
Char: 7
Code: 0
URI: file://vboxsvr/Umanu/Info/HTML5/Bug/index.html

I tested this on a Windows Server 2003 R2. With jQuery 1.6.x the example above works fine.

Change History (11)

comment:1 Changed 11 years ago by Umanu

The error does not occur on jsFiddle, but you can use the following HTML file for testing:

    <script src="jquery.js" type="text/javascript"></script>
    <script type="text/javascript">
      $(document).ready(function() {
        // any code
    <div>Hello World!</div>

comment:2 Changed 11 years ago by Rick Waldron

Owner: set to Umanu
Status: newpending

Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket!

Additionally, be sure to test against the "jQuery (edge)" version to ensure the issue still exists. To get you started, use this boilerplate: http://jsfiddle.net/FrKyN/ Open the link and click to "Fork" (in the top menu) to begin.

comment:3 Changed 11 years ago by Olexandr

$(document).ready() does not work with Internet Explorer 9 on my side as well. I use the same 1.7 version.

comment:4 Changed 11 years ago by Rick Waldron

You realize that jsfiddle is wrapping your code, right?


$(document).ready(function() {
  // any code


In the upper left hand of the page, under "Choose Framework", the first select menu allows you to set the boilerplate code for window onload, document DOMContentLoaded or none.

comment:5 Changed 11 years ago by Umanu

Status: pendingnew

I copied the jsFiddle sample I posted in my first post into a fork of the boilerplate you provided: http://jsfiddle.net/nwdqE/1/

However, as I wrote in my first comment jsFiddle is useless for analyzing this bug because regardless of the settings in jsFiddle, the bug does not occur in jsFiddle.

I tested the standalone sample of my first comment some seconds ago using http://code.jquery.com/jquery-git.js and there the problem still exists. The latest version working correctly is http://code.jquery.com/jquery-1.6.4.min.js.

comment:6 Changed 11 years ago by mikesherov

Status: newpending

Umanu, I've tested the code you've provided, I can't reproduce.

However, the second fiddle you provide still has wrapper code... I've updated it to not have wrapper code so you can see what the settings should be: http://jsfiddle.net/nwdqE/2/

Does it still error out on that fiddle?

comment:7 Changed 11 years ago by mikesherov

Umanu, if you can still reproduce, give us the EXACT code you're using. Particularly,

<script src="jquery.js" type="text/javascript"></script>

from your first comment is not useful because I can't guarantee what jquery.js is on your local server. Try using an absolute url to the jquery CDN:

<script src="http://code.jquery.com/jquery-git.js" type="text/javascript"></script>

Also, are you using a doctype before your html tag? You should be.

comment:8 Changed 11 years ago by Umanu

Status: pendingnew

I could not reproduce the error using my reduced sample as well. However, the error still occurred in the script that was the base of it. After a while I found out that the caching mechanisms of Internet Explorer had tricked me before. I am more than sorry for this.

In fact the error was not related to $(document).ready() but to $.inArray(). The actual error is, that using jQuery 1.7.x + Internet Explorer 8, $.inArray() does not work with strings any more, although it works fine for "real" arrays.

The following line of code works fine in Firefox 11 with jQuery 1.6.x as well as with jQuery 1.7.x. In Internet Explorer 8 it only works with jQuery 1.6.x, but with jQuery 1.7.x you just get an "Object expected" error:

var x = $.inArray('-', '2012-02-27');

This is the updated jsFiddle: http://jsfiddle.net/nwdqE/3/

comment:9 Changed 11 years ago by dmethvin

Resolution: invalid
Status: newclosed
var x = $.inArray('-', '2012-02-27');

Well, inArray requires an Array, right? Not a string. Some browsers let you index a String like an Array, but not oldIE. Is there a reason you're not using String.indexOf() which is the proper method?

comment:10 Changed 11 years ago by Umanu

I agree that String.indexOf() is a good alternative for my case. However, usually I prefer using jQuery methods over "native" JavaScript methods, because I assume that the chance is higher jQuery methods behave the same in all browsers.

All common browsers implement strings as an array of characters - even Internet Explorer 8 does so. Actually this is defined in the ECMA-Standard on page 28, chapter "8.4 The String Type" (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf). The following code would let IE8 open an alert box saying "e":

  var s = 'Test';

This is why $.inArray() should work with arguments of type string as well - actually it even did so in all common browsers up to jQuery 1.6.x. This is why in my point of view it is a bug that jQuery 1.7.x behaves differently in Internet Explorer 8.

comment:11 Changed 11 years ago by dmethvin

I disagree that native methods should be used over jQuery ones when native methods are more appropriate, faster, and already consistent across browsers. The fact that it worked before isn't that relevant since it was never a valid input per the documentation. If you would like to look into it and provide a patch you're welcome to do it, but investigating the problem, creating a test case, making a patch, testing it, and changing the documentation to note that strings are now allowable and will be supported forever more is not a priority for us.

Note: See TracTickets for help on using tickets.