- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 20 Apr 2012 13:43:32 +0300
On Tue, Jan 10, 2012 at 2:10 AM, Ian Hickson <ian at hixie.ch> wrote: > On Tue, 31 May 2011, Henri Sivonen wrote: >> >> Recently, there was discussion about changing media element state in the >> same task that fires the event about the state change so that scripts >> that probe the state can make non-racy conclusions about whether a >> certain event has fired already. >> >> Currently, there seems to be no correct non-racy way to write code that >> probes a document to determine if DOMContentLoaded or load has fired and >> runs code immediately if the event of interest has fired or adds a >> listener to wait for the event if the event hasn't fired. >> >> Are there compat or other reasons why we couldn't or shouldn't make it >> so that the same task that fires DOMContentLoaded changes the readyState >> to "interactive" and the same task that fires load changes readyState to >> "complete"? > > Fixed for 'load'. I don't see a good way to fix this for > 'DOMContentLoaded', unfortunately. It turns out that Firefox has accidentally been running defer scripts after DOMContentLoaded. I haven't seen bug reports about this. Embracing this bug might offer a way to always keep the readystatechange to "interactive" in the same task that fire DOMContentLoaded. See http://hsivonen.iki.fi/test/moz/readystate/defer-script.html -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/
Received on Friday, 20 April 2012 03:43:32 UTC