This bug report is being forwarded to the author or current owner of the affected component for additional investigation and response.

Experienced the same problem, here is a potential workaround to the current issue:

// following code was added to an external file, loaded in the head after yahoo-dom-event.js is loaded (using YUI 2.5.2)
// tested on IE6/7 & FF3 on Windows XP, Safari on Mac OSX
try {
document.createElement("p").doScroll("left");
// only gets here if (isIE and isInIframe)
// override onDOMReady to use window.onload
YAHOO.util.Event.onDOMReady = function( p_fn, p_obj, p_scope ){
YAHOO.util.Event.addListener( window, "load", p_fn, p_obj, p_scope );
}
} catch (e) {
// all other conditions get here, which is good.
}

We've recently encountered this issue at my workplace. I've managed to create some testcases which reproduce this problem intermittently yet reliably enough on both IE6 and IE7.

I can get the error appearing around 50% of the time on Microsoft's IE6 testing VM (http://tinyurl.com/y64upm), and around 20% of the time on IE7 on my desktop.

The error happens for a page both hosted in a frame and in an iframe.

Here's the test pages:

http://lieschke.net/ondomreadytest/frame-test.html
http://lieschke.net/ondomreadytest/iframe-test.html

The complete tests are also available for download from http://lieschke.net/ondomreadytest/ondomreadytest.zip.

It will not fail if you use the code I suggested several months ago on the yui list.

At that time I was told that my suggestion would have been included, it has not happen up to now.

The "doScroll()" trick is known to work only on the main top window, you have to use an "onreadystatechange" event as a fall back for frames/iframes (and not only for that).

--
Diego Perini

After reading Diego's comment I had a look through some old issues to see if I could find the issue he was referring to.

I discovered issues [ 1882941 ] and [ 1883014 ] (aka [ #1778729 ]). The first issue was closed as a duplicate of the second, but both issues make the same suggested modification to the onDOMReady as it was then implemented. It appears that whoever resolved the issue did not see the comment Diego made about handling onreadystatechange, because this part of his implementation was not included in the revised onDOMReady function.

After looking at Diego's site I made the following change to a local copy of 2.6.0's event-debug.js:

if (EU.isIE) {
YAHOO.util.Event.onDOMReady(YAHOO.util.Event._tryPreloadAttach, YAHOO.util.Event, true);

if (window != window.top) {
document.onreadystatechange = function() {
if (document.readyState == 'complete') {
document.onreadystatechange = null;

clearInterval(EU._dri);
EU._dri = null;
EU._ready();
}
};
} else {
... // existing code goes here
}
} else if (EU.webkit && EU.webkit < 525) {
...

I then modified Simon's examples to use my redefined onDOMReady function and they now function as expected in both Internet Explorer and Firefox (note I have not performed exhaustive testing and this implementation could be improved).

While working on this I also uncovered issue [ 2183557 ] and note that relying on onreadystatechange even if window == window.top also avoids this issue.

Regards,
Walter

@wrumsby,
thank you for looking at it and finding my previous suggestions.

I was also looking at this same problem in ExtJS actually. This technique has already been included in Google JsApi/UDS and various other frameworks (at different stages), unfortunately some misinformation left the desk before I could even explain it, creating a bit of confusion and waste of time :-(

There have been improvements in the handling of frames/iframes which does not work with the "doScroll()" trick as does the main top window. Also it is mandatory to use attach/detach instead of the DOM0 way since in some circumstance "document.onreadystatechange" will not produce the expected behavior (either...). This is a change that will improve IE and ensure that the order of "DOMReady" and "onload" is respected on all browsers in the same way.

The latest changes have been included in this (bit old) stand-alone cross-browser helper:

http://javascript.nwbox.com/ContentLoaded/contentloaded.js

I know it is a hack and there is nothing to be proud of, but the behavior is somehow documented on the vendor documentation and while waiting for a better solution I believe this is the best we have at the moment, if we don't want to go the proprietary external HTC way on IE.

These should be the changes to "event.js" in 2.6.0:

document.attachEvent('onreadystatechange', function() {
if (document.readyState == 'complete') {
document.detachEvent('onreadystatechange', arguments.callee);
EU._ready();
}
});

if (window == window.top) {
EU._dri = setInterval(function() {
try {
// throws an error if doc is not ready
document.documentElement.doScroll('left');
} catch (ex) {
return;
}
clearInterval(EU._dri);
EU._dri = null;
EU._ready();
}, EU.POLL_INTERVAL);
}

Haven't done any test, just took the source file and modified where it seemed adequate. I will have to find some of the test case and send them, but will take some days...

In the mean time you can look at the test cases I have at my lab site above (for IE).

--
Diego Perini

This ticket was imported from Source Forge.

Orginially submitted by: kpdecker

It has been reported that this is an issue in Orbeon Forms as well, since Orbeon Forms uses onDOMReady, when Orbeon Forms is loaded within an iframe under IE. It would be great if this bug was fixed.

Cool, glad to find this report and see that this was milestoned for 2.NEXT. This seems to be impeding us from running our tests on IE which would be quite nice to do.

Trying Simon's test cases with IE8 this appears to be an issue with IE 6 & 7, but not 8.

As far as I am aware this issue also affects us on IE8. If no one else is seeing it there though, I can do some digging and make sure it is the same issue.

I tested IE 8 using a VM and there's a possibility that the VM was running too slowly to trigger the error condition, but you also can see issues with IE 8 that are not really IE 8 issues if the page renders using IE 7 rendering.

I've got IE8 installed on my desktop (not in a VM) and I can confirm it still manages to intermittently trigger the error condition for my test at http://lieschke.net/ondomreadytest/iframe-test.html

Ticket copied to: http://yuilibrary.com/projects/yui3/ticket/2528005

fixed in 285276ff9d5ce8c555789228b5e428afc8a54744

2.8.0 has been released. All "checkedin" items are available for download in the official release. Status of "checkedin" items is being set to closed.