Can script determine if window.onload has already fired?
in [JavaScript]
|
From: David Mark on 24 Nov 2009 01:02 On Nov 23, 11:12 pm, Matt Kruse <m...(a)thekrusefamily.com> 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? And, pray tell, what would have loaded it after onload? Whatever script actually does the loading by XHR/eval must set the onload listener. If you don't know how to set an onload listener before load, you've got much bigger problems. ;) > > 2) This strategy assumes you can modify the source of the second > script. Again, no kidding. You think you are going to load any old script after load and have it work like magic? How was it going to answer your question (detecting onload having fired) if you didn't modify it to do so?
From: David Mark on 24 Nov 2009 01:11 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?)
From: Stevo on 24 Nov 2009 01:31 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? Then we have the question that's being asked. Can script enquire whether the onload event has fired. Not whether someone's set a flag. There are sites that are run by multiple different departments in some very large companies. They move slowly. They have processes in place and development schedules. You don't just say "hey bill, set this flag for me will you". It's much bigger than that, and you can wait 6 months to get approval for any change. Other more localized parts of the site are flexible and are running at a different pace. They might want to load your script but have no power whatsoever when it comes to setting a flag in the parent page. If everyone could please just accept that the flag-setting option is not always available, we can get back to the original question.
From: David Mark on 24 Nov 2009 01:38 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.
From: Stevo on 24 Nov 2009 01:57
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. 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. 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. 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". 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. If the CMS were to allow such potentially site-breaking code then it would be remiss in it's duties. 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. 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 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. 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. 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. |