I had the same problem a while ago with IE6. The problem occurred every time an DOM element was accessed before IE read its end tag.

Therefore one solution would be to add a container and put the call to your function after the end tag. For example: <div id="theContainer">some content</div><script type="...">//your function call that works inside the container</script>

In common this approach doesn't seem to be a problem. The only case where it is a bit tricky to use is when you want to work with the body. You could put your caller script tag at the end of the body and call with a little timeout but there is no guarantee of correct working in this case.

However if you can delay execution of your function util onload this is the better solution/workaround. If they simply could manage to implement the DOMContentLoaded event...

The "Operation Aborted" is probably caused by this IE 6 problem.

You might also find that doing something like this works:

YAHOO.util.Event.onDOMReady(function(setTimeout(foo, 0)));

where foo is the function that your original onDOMReady called.

This comment (and the original article) provide some information on why setTimeout can help in situations like this.

That said, there do appear to be a few weird edge cases that onDOMReady struggles with, the tricky thing has been finding test cases that demonstrate the problems clearly so that they can be described in a YUI bug report. Looks like you guys might have found one.

I use a different library, but I think that most domready-checking is based on Dean Edwards' fine work, the methodology being that when you place a script in the head with a defer="defer" property, that script isn't loaded until the DOM is closed. Then, using an onload command for that script, you infer that the DOM is closed, and you trigger your domready events. The Operation Aborted error is really a symptom, usually indicating that you're trying to add something directly to document.body or some larger container div. If domready fires early and your container isn't closed, you'll trip the Operation Aborted error. This can also cause errors on the page when you have domready events addressing elements that aren't even present on the page yet. It won't trigger Operation Aborted, but you'll get an error saying, roughly, "$('mydiv') has no properties".

I don't fully understand what causes the domready-triggering deferred script to load, but I've been looking for the trigger for some time. I work for a fairly large website on pages that have code from a number of different sources, including advertisers, so I don't have complete control over what goes into them.

What I've seen is that in some cases, document.write-ing and innerHTML=-ing to a page can cause the deferred script to load. It seems to me that something about converting raw text into DOM elements triggers the problem. I've often found that converting raw text into DOM elements before inserting them into the DOM resolves the issue. But not always.

A case I've been wrestling with today may have helped me to narrow it down, but I still need to test. An ad was document.write-ing a style element, and I think that specifically was triggering the deferred script to load. So maybe document.write-ing or innerHTML=-ing script and style tags can cause the problem. But not always.

Want a quick way to see what's probably causing IE to load the deferred script that triggers the domready events? I'm going to write this in MooTools (the library we use) syntax, but I'm sure you can easily translate it:

window.addEvent('domready', function() {
alert(document.body.innerHTML.substring(document.body.innerHTML.length-500));
});

When do you plan to fix this issue in Jira? I don't have access to view JRA-14423.

Sorry about that, JRA-14423 had an issue security set - preventing you from seeing it. It is visible now. It was not visible because it was in the code for JIRA 4.0 that has not been released yet and was fixed before it will be released.

DOMReady using defer scripts is quite buggy. Try to use this variant instead:

// Continually check to see if the document is ready
var timer = function()
{
try
{
// If IE is used, use the trick by Diego Perini
// http://javascript.nwbox.com/IEContentLoaded/
if (qx.bom.client.Engine.MSHTML || document.readyState != "loaded" && document.readyState != "complete") {
document.documentElement.doScroll("left");
}

nativeWrapper();
}
catch(error) {
setTimeout(timer, 100);
}
};

timer();

This is part of the qooxdoo project (http://qooxdoo.org) (API available under: http://demo.qooxdoo.org/devel/apiviewer/#qx.event.handler.DomReady)

The idea behind this piece is to start an "interval" which detects is the document is scrollable. This should be the better alternative and worked in all our test cases.

if you are developing application with ASP.NET then use ClientScriptManager's RegisterStartupScript method instead of YAHOO.util.Event.onDOMReady(handler);

It will inject javascript method with rendered HTML output & will be invoked after complete page rendering.

In JS file :-
onPageLoad = function() {

new MyControls({
ctrlCollection : Yahoo.util.Dom.getElementsByClassName("CSS-Class Name")
});
}

In CS file :-

Page.ClientScript.RegisterStartupScript(typeof(MyPage), "LoadPage", "onPageLoad();", true);

Please avoid to use onDOMReady event with IE

Regards
Lalit Dwivedi

i have problem in IE while using mootools lib
window.addEvent('domready', function() {

Sexy = new SexyAlertBox();
});

ERROR: Sexy is undefined in IE.
Please let me know i can write instead of 'domready'