Can script determine if window.onload has already fired?
in [JavaScript]
|
From: Stevo on 24 Nov 2009 02:56 David Mark wrote: > On Nov 24, 1:57 am, Stevo <n...(a)mail.invalid> wrote: >> David Mark wrote: >>> On Nov 24, 1:31 am, Stevo <n...(a)mail.invalid> wrote: >>>> David Mark wrote: >>>>> On Nov 24, 12:38 am, Stevo <n...(a)mail.invalid> wrote: >>>>>> Matt Kruse wrote: >>>>>>> On Nov 23, 8:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>>>>>> Then you are blind. There must be some script that downloads the >>>>>>>> secondary code. So that script sets an onload listener that sets a >>>>>>>> "loaded" flag. The other scripts refer to that flag. End of story. >>>>>>> 1) That depends on the first script setting an onload listener. What >>>>>>> if it is loaded after window.onload? >>>>>>> 2) This strategy assumes you can modify the source of the second >>>>>>> script. >>>>>>> Matt Kruse >>>>>> All it would take is for the browser to set window.onload = true after >>>>>> it's called all registered onload handlers, and those of us who want to >>>>>> know if it's already happened can check if(window.onload === true). I >>>>>> wish one of them would take the lead. >>>>>> The DOMContentLoaded event was a start in a related direction, but still >>>>>> we have no simple properties that let script determine whether onload >>>>>> has triggered, and/or whether the DOM is ready for full scripting. >>>>>> To further explain what Matt and I are both looking for, here's an example. >>>>>> Site A decides to load library script B at some point during the viewing >>>>> And site A is running some script that can load scripts (call it >>>>> script X). >>>>>> of a page. It's completely unknown when this might be. They might be >>>>>> doing it in the head section, in the body section, or on-demand well >>>>>> after the onload event has fired because of some user action. >>>>> Doesn't matter as script X will set a global flag when onload fires. >>>>>> Script B wants to know into which page state it's being loaded. Whether >>>>>> or not the event has fired already. >>>>> Check the flag. >>>>>> Question: How can script B know if onload has fired without putting >>>>>> demands on site A to have to set flags (because the browser itself >>>>>> doesn't seem to want to). >>>>> Demands to set flags? If you are writing a script delivery mechanism, >>>>> setting a flag is not a big concern. And how would script B check >>>>> anything, browser set or otherwise (unless you modified it to do so?) >>>> Why can't you simply acknowledge that there are situations where asking >>>> site A to change their page simply isn't an option? >>> I didn't say change site A any more than you are already changing it >>> by adding script X. Set the load listener in script X. Get it? If >>> they don't add this magic loader script to site A, you are SOL anyway, >>> right? >>>> Then we have the >>>> question that's being asked. >>> And answered. You (and Matt Kruse) are definitely missing something. >>> Bad company. >>>> Can script enquire whether the onload event >>>> has fired. Not whether someone's set a flag. >>> You've been told repeatedly that is not the case, but it doesn't >>> matter. You have to change site A (by adding your loader script) and >>> you would have to change any script that relied on it to check >>> property Z (non-existent) in the browser. So, instead of checking for >>> something you know is not there, check for the flag. >> David, I think you're viewing this from too simplistic a level. > > I think you are confused. > >> You're >> assuming a simple site under the control of one person who has the power >> to change any line of code anywhere at any time. In the real world that >> just doesn't happen. > > There it is. I am assuming no such thing. > >> I hear what you're saying, I really do, but there's no way of setting a >> load listener in the case I'm thinking of. > > What case is that? I'd really like to know how your loader script > will be unable to set a load listener. I don't have a loader script, that's how. >> There is no "script X" that's >> being hand-written by somebody and "while they're at it, why don't they >> set a load listener". > > Huh? Script X is the hypothetical script that you (and Matt Kruse) > are trying to design. It loads scripts, not with SCRIPT elements, but > with XHR and eval. Or perhaps it will inject a SCRIPT element. > Regardless, you will need a script to pull this off. ;) No. Neither of us is designing a loader script. We are working on "the loaded script" (the script that gets loaded by a script loading mechanism out of our control). When we load, we're loading into an unknown situation and we're trying to assess what that situation is. Have we been loaded into a fully complete page (in which case window.onload has fired already), or are we being loaded before window.onload has been fired. The script that does the loading is nothing to do with us at all. It belongs to the site and doesn't set any flags. >> We're talking about convoluted content management >> systems that can be set to load an external library (Script B) but >> there's no control over Site A or the code that's loading the library or >> any access to onload listeners. > > Is that what we are talking about? Never mind if it is convoluted or > a CMS. There are two possibilities: > > 1. SCRIPT element is included in the markup. No problem there. > 2. Some script somewhere in your document(s) will have to be executed > to load Script B. That's the script that must set the load listener > which sets the flag so that Script B will know whether the document is > loaded. > >> If the CMS were to allow such >> potentially site-breaking code then it would be remiss in it's duties. > > What? The CMS would be responsible for generating or including the > loader "bootstrap" script (or just including the required external > scripts in the markup). You said the CMS would be "set to load an > external library." If the CMS is set to do that, it will have to do > it. ;) > >> Script B is assumed to be able to deal with all it's own requirements >> and doesn't place any external demands on the site. > > So, if I gave you a magic property to check to see if the document is > loaded, how is it that script B would check it (unless you modified it > or there was a prior agreement with the author). > >> There are many examples of such cases where a site will one day decide >> to load an external script file and then the next day they stop it. > > That's as easy as adding and then removing a SCRIPT element. Or if > you use a "convoluted CMS", perhaps it can do this for you. > >> That >> script file might do some user tracking, ask if the user wants to >> complete a survey, put a short-term item onto the page. Any number of >> things. > > So? > >> One thing they share in common is that they're loaded up by a >> simple script tag and expected to perform with no requirement or ability >> to have the hosting page changed in any way to support it. > > And? > >> This is an issue I've wanted to know the answer to for a long time and >> I'm just jumping on Matt's bandwagon to see if I can get the answer too. > > What issue? You'll come across it one day, but until you do, it's nothing to worry about.
From: David Mark on 24 Nov 2009 03:39 On Nov 24, 2:56 am, Stevo <n...(a)mail.invalid> wrote: > David Mark wrote: > > On Nov 24, 1:57 am, Stevo <n...(a)mail.invalid> wrote: > >> David Mark wrote: > >>> On Nov 24, 1:31 am, Stevo <n...(a)mail.invalid> wrote: > >>>> David Mark wrote: > >>>>> On Nov 24, 12:38 am, Stevo <n...(a)mail.invalid> wrote: > >>>>>> Matt Kruse wrote: > >>>>>>> On Nov 23, 8:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > >>>>>>>> Then you are blind. There must be some script that downloads the > >>>>>>>> secondary code. So that script sets an onload listener that sets a > >>>>>>>> "loaded" flag. The other scripts refer to that flag. End of story. > >>>>>>> 1) That depends on the first script setting an onload listener. What > >>>>>>> if it is loaded after window.onload? > >>>>>>> 2) This strategy assumes you can modify the source of the second > >>>>>>> script. > >>>>>>> Matt Kruse > >>>>>> All it would take is for the browser to set window.onload = true after > >>>>>> it's called all registered onload handlers, and those of us who want to > >>>>>> know if it's already happened can check if(window.onload === true). I > >>>>>> wish one of them would take the lead. > >>>>>> The DOMContentLoaded event was a start in a related direction, but still > >>>>>> we have no simple properties that let script determine whether onload > >>>>>> has triggered, and/or whether the DOM is ready for full scripting. > >>>>>> To further explain what Matt and I are both looking for, here's an example. > >>>>>> Site A decides to load library script B at some point during the viewing > >>>>> And site A is running some script that can load scripts (call it > >>>>> script X). > >>>>>> of a page. It's completely unknown when this might be. They might be > >>>>>> doing it in the head section, in the body section, or on-demand well > >>>>>> after the onload event has fired because of some user action. > >>>>> Doesn't matter as script X will set a global flag when onload fires.. > >>>>>> Script B wants to know into which page state it's being loaded. Whether > >>>>>> or not the event has fired already. > >>>>> Check the flag. > >>>>>> Question: How can script B know if onload has fired without putting > >>>>>> demands on site A to have to set flags (because the browser itself > >>>>>> doesn't seem to want to). > >>>>> Demands to set flags? If you are writing a script delivery mechanism, > >>>>> setting a flag is not a big concern. And how would script B check > >>>>> anything, browser set or otherwise (unless you modified it to do so?) > >>>> Why can't you simply acknowledge that there are situations where asking > >>>> site A to change their page simply isn't an option? > >>> I didn't say change site A any more than you are already changing it > >>> by adding script X. Set the load listener in script X. Get it? If > >>> they don't add this magic loader script to site A, you are SOL anyway, > >>> right? > >>>> Then we have the > >>>> question that's being asked. > >>> And answered. You (and Matt Kruse) are definitely missing something. > >>> Bad company. > >>>> Can script enquire whether the onload event > >>>> has fired. Not whether someone's set a flag. > >>> You've been told repeatedly that is not the case, but it doesn't > >>> matter. You have to change site A (by adding your loader script) and > >>> you would have to change any script that relied on it to check > >>> property Z (non-existent) in the browser. So, instead of checking for > >>> something you know is not there, check for the flag. > >> David, I think you're viewing this from too simplistic a level. > > > I think you are confused. > > >> You're > >> assuming a simple site under the control of one person who has the power > >> to change any line of code anywhere at any time. In the real world that > >> just doesn't happen. > > > There it is. I am assuming no such thing. > > >> I hear what you're saying, I really do, but there's no way of setting a > >> load listener in the case I'm thinking of. > > > What case is that? I'd really like to know how your loader script > > will be unable to set a load listener. > > I don't have a loader script, that's how. But Matt Kruse was asking about a hypothetical loader script that uses XHR/eval to load scripts. Are you off his bandwagon now? > > >> There is no "script X" that's > >> being hand-written by somebody and "while they're at it, why don't they > >> set a load listener". > > > Huh? Script X is the hypothetical script that you (and Matt Kruse) > > are trying to design. It loads scripts, not with SCRIPT elements, but > > with XHR and eval. Or perhaps it will inject a SCRIPT element. > > Regardless, you will need a script to pull this off. ;) > > No. Neither of us is designing a loader script. > > We are working on "the loaded script" (the script that gets loaded by a > script loading mechanism out of our control). Well, Matt said in an earlier "rebuttal":- "2) This strategy assumes you can modify the source of the second script." So now I know you fell off the wagon. :) > > When we load, we're loading into an unknown situation and we're trying > to assess what that situation is. Have we been loaded into a fully > complete page (in which case window.onload has fired already), or are we > being loaded before window.onload has been fired. As mentioned. No good. And, as it sits, document.readyState can't help you either (maybe in five years). So design accordingly if you site is scheduled for launch prior to 2015. ;) [snip] > > You'll come across it one day, but until you do, it's nothing to worry > about. I know "it" is nothing to worry about. You just can't worry about fantasy scenarios.
From: Garrett Smith on 24 Nov 2009 03:50 David Mark wrote: > On Nov 24, 2:31 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> Stevo wrote: >>> Matt Kruse wrote: >>>> On Nov 23, 8:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: [snip] >> >> document.readyState == "complete" ? >> >> In Firefox 3.6[1]. >> >> Already in IE, Safari, and Opera. >> >>> To further explain what Matt and I are both looking for, here's an example. >>> Site A decides to load library script B at some point during the viewing >>> of a page. It's completely unknown when this might be. They might be >>> doing it in the head section, in the body section, or on-demand well >>> after the onload event has fired because of some user action. >>> Script B wants to know into which page state it's being loaded. Whether >>> or not the event has fired already. >>> Question: How can script B know if onload has fired without putting >>> demands on site A to have to set flags (because the browser itself >>> doesn't seem to want to). >> The loader script can determine what the state of the document is in and >> set the flag. What's wrong with that? > > It isn't a cross-browser solution and that property is available to > the loaded script, so it doesn't need to be mirrored in a flag. The > loader script can set a load listener. The load listener sets a > flag. That's the only way to know for sure if the document is loaded. > I think we are discussing the exact same thing here. I should have stated that document.readyState is not widely enough implemented; it is not even implemented in official Firefox release yet. Sounds like Matt wants to have a user-defined Loader object to load the scripts. SOmething like: Loader.loadScripts(srcArray, scriptLoaded); ? 1) loader script adds to window.onload "loaderWindowOnload" (that sets loader.complete=true). 2) loader loads script(s). 3) when a script is loaded, that script checks the loader's complete flag. 4) if the complete flag is false, the loaded script may add a callback to window.onload. Otherwise, it just calls whatever function it needed. This solves the problem where loader.loadScripts loads 10 scripts, the first five are loaded before window.onload fires, then the next five are loaded after onload, but the last five want to know about onload. If the loaded scripts are designed so that they listen for window.onload, they will be waiting forever. This approach solves that. The problem with the "loader sets a flag" approach is that the loaded scripts are necessarily coupled to the loader. The loaded scripts should be able to be run and tested without knowing about how they were loaded, or some global "loader.complete" flag. Loader could steal window.onload is refire it after all scripts have loaded, however that can still fail easily, in many cases, such as: loaded script listens for "load" using addEventListener or attachEvent, loaded script checks document.readyState, loaded script uses document.write. If the loaded script is only allowed to check a flag, complications are eliminated. Its ;ate here; hope that makes good enough sense! -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: wilq on 24 Nov 2009 09:22 From what I know there is no simple way to check that. You could try to extend MooTools idea of having DomReady to something that you ask for. Cant tell you if this works, code looks quite hacky here. (function(){ var domready = function(){ if (Browser.loaded) return; Browser.loaded = true; window.fireEvent('domready'); document.fireEvent('domready'); }; window.addEvent('load', domready); if (Browser.Engine.trident){ var temp = document.createElement('div'); (function(){ ($try(function(){ temp.doScroll(); // Technique by Diego Perini return document.id(temp).inject(document.body).set('html', 'temp').dispose(); })) ? domready() : arguments.callee.delay(50); })(); } else if (Browser.Engine.webkit && Browser.Engine.version < 525){ (function(){ (['loaded', 'complete'].contains(document.readyState)) ? domready () : arguments.callee.delay(50); })(); } else { document.addEvent('DOMContentLoaded', domready); } })();
From: Evertjan. on 24 Nov 2009 09:48
wilq wrote on 24 nov 2009 in comp.lang.javascript: > From what I know there is no simple way to check that. check what? [please always quote on usenet] > Re: Can script determine if window.onload has already fired? Sure, just start the onload function with var onloading = true; ans check that in your script. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress) |