Can script determine if window.onload has already fired?
in [JavaScript]
|
From: David Mark on 24 Nov 2009 02:29 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. > 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. ;) > 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?
From: Garrett Smith on 24 Nov 2009 02:31 Stevo wrote: > Matt Kruse wrote: >> On Nov 23, 8:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: [snip] > 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. > Overloading the existing onload property would be a mistake. > 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. > Sounds like you want a state variable for the document. 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? [1]https://developer.mozilla.org/en/DOM/document.readyState -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 24 Nov 2009 02:41 On Nov 23, 3:51 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: [snip] > Typical of this group, which is why it's become mostly irrelevant. > Typical of you, you don't know your evidence. ISTM that you have floated the posting traffic in the jQuery group(s) as an indicator of relative relevance. I will assume you still subscribe to that theory, at least up until you read the next couple of lines (then cognitive dissonance will kick in and you will find a new belief). Know what this is? 4206 4167 3792 3351 2655 2904 2895 2651 2500 2251 1866 The tallies for the last eleven months for the primary jQuery user group. Last month here was 2169. Of course, I am assuming that GG can count (probably +/-500 margin of error). :)
From: David Mark on 24 Nov 2009 02:45 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] > > 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. > > Overloading the existing onload property would be a mistake. > > > 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. > > Sounds like you want a state variable for the document. > > 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. > > [1]https://developer.mozilla.org/en/DOM/document.readyState https://developer.mozilla.org/en/DOM/window.onload https://developer.mozilla.org/en/DOM/element.addEventListener
From: Stevo on 24 Nov 2009 02:52
Garrett Smith wrote: > Stevo wrote: >> Matt Kruse wrote: >>> On Nov 23, 8:15 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > [snip] >> 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. >> > Overloading the existing onload property would be a mistake. > >> 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. >> > > Sounds like you want a state variable for the document. > > 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? > > [1]https://developer.mozilla.org/en/DOM/document.readyState Unbelievable. After 3 years they finally decided to implement document.readyState. That is the ideal solution. It would be nice if they built it into FF2 and FF3.0 and FF3.5 also. |