IE 7 and JavaScript: what needs to be fixed?

Recently Erik Arvidsson lamented the lack of JavaScript progress in IE 7. Strictly speaking he's right, of course: there are few JavaScript bug fixes in the new release, because Microsoft has made CSS fixes its priority. Microsoft has done what it's promised, and it never promised us JavaScript fixes for this release.

That said, everybody knows there are a few things lacking in IE's JavaScript support. The point of this entry is to start creating a list with specific wishes for JavaScript improvements in IE. When it's done and when Microsoft starts thinking about the next version we can present it.

What has been done?

What needs to be done?

The purpose of this entry is to gather feedback about what still needs to be done, and to present a list of specific issues to Microsoft once IE 7.0 has been released and the next version can be considered.

Lists by Erik Arvidsson and Alex Russell are already available. I myself have a few more low-level issues, most importantly:

What's your list?
(I prefer links that point to your list, rather than a list typed directly into the comments. It's far easier to send on such links to interested parties.)

Comments

1 Posted by Tino Zijdel on 29 April 2006 | Permalink

I don't have a full list, but some things come to mind (besides the lists already mentioned):

- XMLHttpRequest cannot be considered 'native' as long as it doesn't support prototyping
- DOM Document, Element, Node etcetera should also be implemented as native objects (DOM ECMAScript bindings) (basically all of DOM level 2 should be implemented as already mentioned)
- substr(x) where x is a negative value is still broken; I just can't believe they have not found and/or bothered to fix this since it is present as of IE4 afaik
- get rid of document.all - it is the root cause of several problems and polutes the global namespace

2 Posted by Aaron Gustafson on 29 April 2006 | Permalink

I haven't played with the latest release but if they haven't fixed it yet, it'd be really nice to be able to create named elements in a standardized way ( see http://tinyurl.com/j99sh ).

3 Posted by Tino Zijdel on 29 April 2006 | Permalink

Aaron: as far as I know that has been partly fixed; at least it seems to work in my IE6, however the set name attribute does not show when alerting the innerHTML of the form.

4 Posted by Gérard Talbot on 29 April 2006 | Permalink

I fully agree with Tino Z.: get rid of document.all: it's the mother of all problems :)

My short list (because I don't want to repeat the ones you already mentioned):

1-
objSelect.add(objOption, null) is not supported by MSIE 6 nor by MSIE 7
http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/SelectAddOptionNull.html

2-
objOption.defaultSelected = true is not supported by MSIE 6 nor by MSIE 7
http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/DefaultSelectedTrueOption.html

3-
InsertRow() is not working accordingly in MSIE 6 nor MSIE 7
http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/InsertRowNotWorking.html

Gérard

5 Posted by David on 29 April 2006 | Permalink

How about allowing to extend native object prototypes (Document, Node etc.)? So we can implement missing features in javascript while they are missing in IE.
For example:
Document.prototype.createElementNS = function (){}

6 Posted by splintor on 30 April 2006 | Permalink

I'd add the inability to enumerate built-in methods:
http://blog.monstuff.com/archives/000287.html

7 Posted by minghong on 30 April 2006 | Permalink

I've recently encountered this bug:
http://support.microsoft.com/default.aspx?scid=kb;en-us;276228

I thought M$ "invented" innerHTML, right? But you can't use it on SELECT elements! What the...

My current workaround is to re-create the whole SELECT element, instead of changing its innerHTML.

8 Posted by Koen Pasman on 30 April 2006 | Permalink

I would like to see the error-reporting of JS-errors in IE less cryptical. It's not something directly related to the JS language itself, but is does increase debugging Javascript in IE.

9 Posted by Robert Nyman on 30 April 2006 | Permalink

I agree with all the points that have been mentioned so far. One thing I definitely think they have to do is to implement proper event handling, i.e. support addEventListener etc, not just having one global event object etc...

I spoke to Chris Wilson of the IE team at SXSW little over a month ago, and the way I interpreted it, JavaScript fixes are definitely the next step they're going to take. Also, that there will be much shorter release cycles between IE versions, so maybe IE 8 isn't that far away... :-)

10 Posted by Mark Wubben on 30 April 2006 | Permalink

I'd like to see a solution for the Externally Declared Global Variable Leak, http://novemberborn.net/javascript/edgvl and also this Flash loading bug: http://novemberborn.net/flash/prefetching-movies

innerHTML returning a valid value would be nice as well.

11 Posted by Lachlan Hunt on 1 May 2006 | Permalink

I think the most important thing is better support for event handling. In particular, addEventListener, with proper support for both bubbling and capture phases, and to actually pass the event object as a parameter to the function, instead of using window.event. Additionally, improved support for keyboard events (though, this one needs to be worked on significantly by all browsers)

Also, when IE finally adds support for XHTML, they need to add support for the DOM namespace methods (e.g. getElementsByTagNameNS(), etc.)

12 Posted by Milo on 1 May 2006 | Permalink

IE's Select.add() is different from the DOM's.

IE's takes an index as the second parameter:
add(oElement [, iIndex])
http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/add.asp

The DOM's takes an object as the second parameter:
add(in HTMLElement element, in HTMLElement before):
http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-14493106

13 Posted by Hristo Deshev on 1 May 2006 | Permalink

Hi Peter-Paul,

Are you sure that IE7 will fix the memory leak problem? I thought it was too much dependent on the underlying COM-based mechanism and fixing that would require a complete rewrite. See Lionel's comment on the IE blog here:

http://blogs.msdn.com/ie/archive/2005/07/29/445242.aspx

I could not find anything confirming that leaks will be fixed on the web. Can you point me to a blog post or an article? Thanks a lot!

Hristo Deshev

14 Posted by William J. Edney on 1 May 2006 | Permalink

Peter-Paul:

In addition to all of these fixes, something must be done about the JScript garbage collector. It lies at the root at most of the JScript performance problems in IE. See Eric Lippert's blog entry here: http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx
See the new post by Brendan Eich himself. Basically, the JScript garbage collector's heuristics are completely wrong for collecting garbage in large live object graphs (what M$ calls a 'large working set'). Now that folks are doing significant things in JavaScript (well, some of us have been at this a while :-) ), this is something that must be fixed in the next release. I mentioned this on a Microsoft developer chat and was told that 'JavaScript performance' was definitely at the top of the list, so maybe they're getting the message. I'd be happy if they simply bumped those heuristic numbers by a factor of 10 for IE7, which should be pretty simple to do and then put a real garbage collector (i.e. generational, compacting collector) in for IE8.

Cheers,

- Bill

15 Posted by Koranteng Ofosu-Amaah on 2 May 2006 | Permalink

It's not like the bugs haven't been written up, I submitted countless bugs in 1999 that were plainly mothballed like Internet Explorer too... but for what it's worth since I encounted some of these lately, how about The Null Hypothesis
http://koranteng.blogspot.com/2006/03/minutiae_114260124270264612.html#null

By that I mean the insertBefore conundrum and the select.add puzzle. They should really just do the right thing

16 Posted by Andrew Dupont on 2 May 2006 | Permalink

I'd like to echo the call for native treatment of DOM objects, including the ability to modify their prototypes. Next on my list would be proper event handling (addEventListener).

Third would be support for DOM Level 3 XPath. Our DIY methods for fetching elements by class name and CSS selector are handy, but they're at least an order of magnitude slower than the same queries routed through XPath (at least in Firefox). If all browsers supported XPath, it would make our lives much easier.

17 Posted by Anthony Lieuallen on 3 May 2006 | Permalink

As requested, here's a link to my post about what I'd like to see.

http://www.arantius.com/article/what-ie-javascript-needs

18 Posted by Dan Webb on 12 May 2006 | Permalink

For me the big ones are:

1. Allow DOM element prototypes to be extended (as mentioned above).

2. Use w3c standard event model.

3. speed up DOM creation / manipulation and fix setAttribute() (as you mentioned).

4. implement Array#forEach(), map() and the other iteration methods.

5. fix gzip / caching problems.

I'm really glad they've fixed the circular ref memory leak thing though.