Is it loading too late, or is it failing to load? What exactly do you mean by scripts being aborted? Is this something new, or the same old stuff from the last 2-3 months?

Does clearing IE's cache entirely resolve or change the results?

Any consistent way to reproduce the error?

What actual visible errors are there?

Are JS errors happening during load/initialization? (I see none on a quick login in IE6 on en.wikipedia.org)

Are JS errors happening only when activating something, such as an ajax watch/unwatch request? (No problem with a quick watch attempt on en.wikipedia.org)

Do presence of certain gadgets exacerbate the problem?

Roan changed the bug title from "IE6 and Javascript: continue or drop support" to "mw.util loads too late in IE6".

The first load with an empty cache loads OK, but any subsequent (re)load or pageclick result in javascript errors (the little yellow triangle) as described above. Simply hit F5 on any page to reproduce. Only CTRL-F5 is error free. This is with all gadgets and such disabled.

I have no way of knowing if mw.util loads too late, or just too slow. Is it allowed to be cached by the browser?

In IE Tester, I get the following error:

Line: 15569
Char: 3
Error: Type mismatch.
Code: 0
URL: http://en.wikipedia.org/wiki/Main_Page

I'll try disabling gadgets and see which one (if any) causes this.

Gadget causing the trouble looked like the UTC clock gadget.

If you know a reason why any JS problems aren't specific to a gadget that you're using, please reopen this bug with a some concrete steps to reproduce the bug. Otherwise, this sounds like a gadget problem and WORKSFORME.

(In reply to comment #5)

Gadget causing the trouble looked like the UTC clock gadget.

If you know a reason why any JS problems aren't specific to a gadget that
you're using, please reopen this bug with a some concrete steps to reproduce
the bug. Otherwise, this sounds like a gadget problem and WORKSFORME.

I have no steps to reproduce, but it isn't a gadget problem.

For some reason there's a bug several people are reporting (although I cannot reproduce it in WinXP IE6 virtual machine) of which the root cause is in the load order of a cached request. Which finds it's visibility by plugging in mediawiki.util too late.

This becomes critical (for IE6) if and as soon as a call to mw.util is made. This could be in the site's or user's common.js, a gadget or a core module – IE6 would report that that module is doing something wrong (calling an inexisting method).

I may have to add that my problem occurs on three different machines, all W2K. On an XP machine, I discovered that it does not show this problem. Do other reporters say which OS they are using? This may be important becuase W2K has not gotten any updates in nearly a year now, and this may cause issues while XP remains unaffected. If this is the case, then it is an OS issue which cannot be resolved.

I may have to add that my problem occurs on three different machines, all W2K.
On an XP machine, I discovered that it does not show this problem.

Is the XP machine using IE6? If so, then this is really interesting.

Is the XP machine using IE6? If so, then this is really interesting.

Yes, the XP machine is running IE6.

Lowering priority since this is IE6 which not many people use. Except those who do.

With the recent talk about mandatory dependency declarations in 1.19, I cannot help thinking this may be related. My old W2K boxes are pretty antique, and the lack of dependency declaration in 1.17/1.18 may well cause modules not yet being loaded when called upon.

If you can set the clockspeed in a VM, you may be able to reproduce this error by turning it down to below 500 MHz.

Marking WORKSFORME. Code that depends on mw.util (or anything else for that matter) needs to declare it as a dependency.