This project is archived and is in readonly mode.

#712 ✓resolved

IE8; domready sometimes fires too soon

Reported by Htbaa | July 16th, 2009 @ 09:42 AM | in 1.3.0 rc2 (closed)

This is a bug that is very hard to reproduce, but does happen from time to time. When I say hard, I do mean hard. It rarely happens, but sometimes just does (1/100 maybe?). Under IE8 the domready event can get fired too soon e.g. the DOM isn't ready yet. Which causes script errors when modifying elements that should be in the DOM.

All I can do is describe how I build up my documents.

  • I include the mootools scripts in
  • I include my own script in with the window.addEvent('domready', function(){...}) inside it
  • In the tag are several elements with unique ID's that are just always there
  • My own script with the domready event does several things like adding events to a number of items.

Most elements will be found and no error occurs. However, elements that appear on the end of the DOM can get overlooked and IE8 returns an error that the script is trying to access an undefined element. My only explanation for this is that the DOM isn't full loaded yet and that IE8 executes the domready event too soon. If the latter is the case then I suppose it's a bug in IE8.

Edit: Version used is mootools-1.2.3

Comments and changes to this ticket

  • Shrike

    Shrike August 1st, 2009 @ 03:57 PM

    This happens for example with the overtext plugin with an empty browser cache

  • zoftie

    zoftie August 10th, 2009 @ 01:17 PM

    Same happens in IE7, I have alot of .addEvent('click', type events, domready fires and hides 'cover' div, that protects all the links, before all the links are hooked up to the click events. I get alot of undefined function errors then, from within mootools.
    But if I wait extra 5 seconds everything works fine.

  • Scott Kyle

    Scott Kyle August 10th, 2009 @ 10:46 PM

    • Assigned user set to “Scott Kyle”

    I setup a test page with 500 unique elements, each with a unique ID. I then tried reproducing this bug in IE7 and IE8 by trying to access the last element and then reloading the page with an incremented query parameter if that element was manipulated successfully. The page reloaded successfully over 1000 times without error. So we really need somebody to post a demo page where this bug occurs because I couldn't reproduce it. Thanks.

  • Campo

    Campo August 26th, 2009 @ 02:42 PM


    I was able to reproduce this in IE8 if my page was the source in an iframe. I think IE8 may be firing the domready functions when the parent page has finished loading?

    I hope this helps, I can setup a test site for you to check out if it helps?

  • Merrick

    Merrick November 6th, 2009 @ 01:42 AM

    • Tag changed from internet explorer, domready, ie8 to internet explorer, domready, ie8, safari

    This issue breaks the OverText plugin in Safari as well. A temporary but hackety fix is changing your domready to load. Either way this is a problem.

  • iGOAT

    iGOAT November 24th, 2009 @ 07:00 PM

    When inside an iframe the domready event fires too early in IE6, IE7 and IE8 resulting in critical JS errors (my site does not work).

    Using the load event fixes this but my users have to wait for every image to load before they can use the site (sometimes this is too long).

    My best fix so far is to add my own domready2 event to the window object and fire it right before the closing body tag.

  • iGOAT

    iGOAT November 24th, 2009 @ 07:03 PM

    • Tag changed from internet explorer, domready, ie8, safari to internet explorer, domready, ie6, ie7, ie8, iframe, safari
  • Christoph Pojer

    Christoph Pojer December 18th, 2009 @ 12:33 AM

    • State changed from “new” to “open”

    As said, please provide a demo so we can actually reproduce the problem.

  • Bram Gerritsen

    Bram Gerritsen January 15th, 2010 @ 10:48 AM

    I've excactly the same problem.
    Here is a demo.
    Just click on Book now and you'll see JS errors coming up in IE8. If I change "domready" event to "load" it'll work, but as said above, it's not the right solution and I have to change hundreds of javascript files.
    Hope this helps you to reproduce the problem. If you need more info pls contact me.

  • Gabriele Perego

    Gabriele Perego January 21st, 2010 @ 12:05 PM

    • Tag changed from internet explorer, domready, ie6, ie7, ie8, iframe, safari to internet explorer, domready, ie6, ie7, iframe

    I experience the same problem in IE7 and IE6, not in IE8.
    I change the event from domready to load as a workaround.

  • Gabriele Perego

    Gabriele Perego January 21st, 2010 @ 12:06 PM

    • Tag changed from internet explorer, domready, ie6, ie7, iframe to internet explorer, domready, ie6, ie7, iframe, safari
  • Andreas Kasparek

    Andreas Kasparek January 25th, 2010 @ 08:03 AM

    • Tag changed from internet explorer, domready, ie6, ie7, iframe, safari to internet explorer, domready, ie6, ie7, ie8, iframe, safari

    The demo from Bram uses quirks mode in IE but even when changing the document mode to IE8 through the IE developer tools the domready error for the iframe occurs. Therefore this seems to be a bug in all IE versions.

  • Fábio M. Costa

    Fábio M. Costa May 9th, 2010 @ 12:42 AM

    • Milestone changed from 2.0 to 1.3.0 rc2

    is this fixed?

  • Htbaa

    Htbaa May 9th, 2010 @ 01:01 PM

    I myself haven't run into this problem anymore. But I'm not sure if it's fixed now though.

  • Fábio M. Costa
  • Crystark

    Crystark June 10th, 2010 @ 04:46 PM


    I've been able to repeat the problem on my page using an interval reloading the page every X seconds.
    It ALWAYS fails.

    If i launch the function to reload myself it actually does work.

    Here's my code :

    document.addEvent('domready',function() {
        var t = $('CLPRR');
        if(!$defined(t)) {
            top.console.log('CLPRR NOT SET');
        else {
    function logit() {

    The on body load i add an interval to reload the page using :

    document.location = my_adress_in_a_string

    Note : the div CLPRR is at the end of a document of ~1050 lines counting ~162200 chars

    I've tried to apply your fix (on 1.2.4 as i'm not using mootools 1.3) and it didn't change much. It just doesn't always happen now.

    Hope this help. For now, that means domready can't be used for prod.

  • Fábio M. Costa

    Fábio M. Costa June 10th, 2010 @ 11:39 PM

    @Crystal are you talking about my fix?

  • Crystark

    Crystark July 9th, 2010 @ 03:24 PM

    • Milestone order changed from “0” to “0”

    Yup, i was

  • Fábio M. Costa

    Fábio M. Costa July 9th, 2010 @ 03:40 PM

    • Assigned user changed from “Scott Kyle” to “Fábio M. Costa”
    • State changed from “open” to “hold”

    it works for me... do you have a test case?

  • Fábio M. Costa

    Fábio M. Costa July 9th, 2010 @ 03:40 PM

    • State changed from “hold” to “open”
  • Crystark

    Crystark July 16th, 2010 @ 09:50 AM

    Unfortunately,i've got no test case. I've tried to make one from what i observed but i failed. I, for now, will have to wait until i repeat the problem...

  • Tempest Nathan

    Tempest Nathan August 25th, 2010 @ 10:47 AM

    I was having this same problem with Moo 1.2.3, but it appears to be fixed in the current version (at least I can't recreate).

  • Htbaa

    Htbaa August 27th, 2010 @ 02:51 PM

    I haven't run into this anymore myself either. But not sure if it's really fixed though.

  • Christoph Pojer

    Christoph Pojer August 30th, 2010 @ 09:02 AM

    • State changed from “open” to “resolved”

    We have a new implementation of domready coming up in 1.3 that should fix the issues.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins