#11507 closed bug (invalid)

Opened March 22, 2012 10:53PM UTC

Closed March 30, 2012 01:41PM UTC

Last modified March 30, 2012 09:47PM UTC

$(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:

Description

http://jsfiddle.net/gzpCm/

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.

Attachments (0)

Change History (11)

Changed March 22, 2012 10:58PM UTC by Umanu comment:1

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

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

Changed March 23, 2012 02:15PM UTC by rwaldron comment:2

owner:	→ Umanu
status:	new → pending

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.

Changed March 26, 2012 01:03PM UTC by Olexandr comment:3

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

Changed March 26, 2012 01:59PM UTC by rwaldron comment:4

You realize that jsfiddle is wrapping your code, right?

Result:

$(window).load(function(){
$(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.

Changed March 29, 2012 12:10PM UTC by Umanu comment:5

status:	pending → new

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.

Changed March 29, 2012 12:50PM UTC by mikesherov comment:6

status:	new → pending

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?

Changed March 29, 2012 12:55PM UTC by mikesherov comment:7

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.

Changed March 30, 2012 01:08PM UTC by Umanu comment:8

status:	pending → new

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/

Changed March 30, 2012 01:41PM UTC by dmethvin comment:9

resolution:	→ invalid
status:	new → closed

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?

Changed March 30, 2012 09:08PM UTC by Umanu comment:10

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';
  window.alert(s[1]);

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.

Changed March 30, 2012 09:47PM UTC by dmethvin comment:11

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.

Side navigation