Can script determine if window.onload has already fired?
in [JavaScript]
|
From: Garrett Smith on 27 Nov 2009 14:19 Jorge wrote: > On Nov 27, 7:56 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> (...) >> A Loader adds a load callback to a script element, then appends that >> script, triggering the browser to load the script. When the script's >> onload fires, the callback calls callback function. >> > > IIRC, I've seen a couple of strange things happen when doing so. In > some browser(s) the onload may not even fire for <script>s. And in > some browsers I've seen both the <script>'s source being parsed/run > synchronously and the onload event being handled synchronously too > (when the <script> was cached and got fetched immediatly, on-the fly, > from the cache). Is it me, is it too much coke, or has somebody else > seen any of these too ? OK, you've got me. All the food got me a little euphoric yesterday. I Wrote "Solution" when I should have written: "Untested solution". Regarding the timing problems you mention with onload, I've not seen those. Then again, I've not testing dynamic script injection much. For requesting remote data, I have always used XHR or iframe. Those work fine when used sparingly with small amounts of data. Using dynamic script injection, the loader would listen for script's onreadystatechange and check the readyState: function loaderWrappedCallback() { var readyState = script.readyState; // TODO: Timeout events. if(!readyState || "complete" === readyState) { callback(); } // TODO: Error handler. } } Further testing is warranted before such experimental technique can be a recommended solution. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 27 Nov 2009 21:35 On Nov 27, 2:19 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Jorge wrote: > > On Nov 27, 7:56 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >> (...) > >> A Loader adds a load callback to a script element, then appends that > >> script, triggering the browser to load the script. When the script's > >> onload fires, the callback calls callback function. > > > IIRC, I've seen a couple of strange things happen when doing so. In > > some browser(s) the onload may not even fire for <script>s. And in > > some browsers I've seen both the <script>'s source being parsed/run > > synchronously and the onload event being handled synchronously too > > (when the <script> was cached and got fetched immediatly, on-the fly, > > from the cache). Is it me, is it too much coke, or has somebody else > > seen any of these too ? > > OK, you've got me. All the food got me a little euphoric yesterday. I > Wrote "Solution" when I should have written: "Untested solution". > > Regarding the timing problems you mention with onload, I've not seen those. > > Then again, I've not testing dynamic script injection much. For > requesting remote data, I have always used XHR or iframe. Those work > fine when used sparingly with small amounts of data. > > Using dynamic script injection, the loader would listen for script's > onreadystatechange and check the readyState: > > function loaderWrappedCallback() { > var readyState = script.readyState; > // TODO: Timeout events. > if(!readyState || "complete" === readyState) { > callback(); > } > // TODO: Error handler. > } > > } That's not a cross-browser solution either. > > Further testing is warranted before such experimental technique can be a > recommended solution. Solution for what? Knowing exactly when any random script has finished loading? That's a fantasy aspiration. And I've seen people trying to do similar things in projects where they actually have control over the loaded scripts (or define the standards for them). The only sane solution is to call the callback from the loaded script. I know that doesn't fit the proposed fantasy design, but I think it bears repeating at this point.
From: Richard Maher on 27 Nov 2009 22:15 Hi David, > Solution for what? I am also not sure what problem the proposed solution solves. I thought the OP wanted to delay till onload fired unless onload has fired in which case run now. > Knowing exactly when any random script has > finished loading? That's a fantasy aspiration. Based on available evidence I have to disagree. Depending of course on what exactly you mean by "exactly" :-) As well as the cross-browser issues I'd include that ONERROR as well or you might find your CALLBACK being a tad unreliable, but then you didn't like "onerror" either. BTW. Is the thrust of the requirements spec for this question the fact that various "libraries" have become so bloated and convoluted that they can no longer be feasibly loaded at "onload" time? So when some one says, for example, "jQuery's footprint is 120KB" then that's just the bootstarp code and oodles more will be lazily-loaded? Cheers Richard Maher "David Mark" <dmark.cinsoft(a)gmail.com> wrote in message news:69d8195b-0814-4342-bc4b-c6103f6c23ca(a)p35g2000yqh.googlegroups.com... On Nov 27, 2:19 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Jorge wrote: > > On Nov 27, 7:56 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >> (...) > >> A Loader adds a load callback to a script element, then appends that > >> script, triggering the browser to load the script. When the script's > >> onload fires, the callback calls callback function. > > > IIRC, I've seen a couple of strange things happen when doing so. In > > some browser(s) the onload may not even fire for <script>s. And in > > some browsers I've seen both the <script>'s source being parsed/run > > synchronously and the onload event being handled synchronously too > > (when the <script> was cached and got fetched immediatly, on-the fly, > > from the cache). Is it me, is it too much coke, or has somebody else > > seen any of these too ? > > OK, you've got me. All the food got me a little euphoric yesterday. I > Wrote "Solution" when I should have written: "Untested solution". > > Regarding the timing problems you mention with onload, I've not seen those. > > Then again, I've not testing dynamic script injection much. For > requesting remote data, I have always used XHR or iframe. Those work > fine when used sparingly with small amounts of data. > > Using dynamic script injection, the loader would listen for script's > onreadystatechange and check the readyState: > > function loaderWrappedCallback() { > var readyState = script.readyState; > // TODO: Timeout events. > if(!readyState || "complete" === readyState) { > callback(); > } > // TODO: Error handler. > } > > } That's not a cross-browser solution either. > > Further testing is warranted before such experimental technique can be a > recommended solution. Solution for what? Knowing exactly when any random script has finished loading? That's a fantasy aspiration. And I've seen people trying to do similar things in projects where they actually have control over the loaded scripts (or define the standards for them). The only sane solution is to call the callback from the loaded script. I know that doesn't fit the proposed fantasy design, but I think it bears repeating at this point.
From: David Mark on 28 Nov 2009 04:15 On Nov 27, 10:15 pm, "Richard Maher" <maher...(a)hotspamnotmail.com> wrote: > Hi David, > > > Solution for what? > > I am also not sure what problem the proposed solution solves. I thought the > OP wanted to delay till onload fired unless onload has fired in which case > run now. > > > Knowing exactly when any random script has > > finished loading? That's a fantasy aspiration. > > Based on available evidence I have to disagree. Depending of course on what > exactly you mean by "exactly" :-) What evidence is that? > > As well as the cross-browser issues I'd include that ONERROR as well or you > might find your CALLBACK being a tad unreliable, but then you didn't like > "onerror" either. If a script is a 404 or has a syntax error or whatever, the document that included it better be equipped to do without it. And it shouldn't need any sort of callback to tell it a script failed to load. > > BTW. Is the thrust of the requirements spec for this question the fact that > various "libraries" have become so bloated and convoluted that they can no > longer be feasibly loaded at "onload" time? So when some one says, for > example, "jQuery's footprint is 120KB" then that's just the bootstarp code > and oodles more will be lazily-loaded? God only knows what jQuery developers are thinking. The base script is too large and slow for mobile use (and full of extraneous garbage that nobody needs). It makes life "simpler" by adding tons of complexity and apps smaller by adding lots of unneeded script. Lazy loading on top of it would be slower than including the scripts normally. And they don't know how to do feature testing yet anyway, so how would they decide what to lazy load. ;)
From: Richard Maher on 28 Nov 2009 04:56
"David Mark" <dmark.cinsoft(a)gmail.com> wrote in message news:f3503614-48a8-4873-9141-9029a10bcce9(a)m3g2000yqf.googlegroups.com... > What evidence is that? Anecdotal++ With all browsers tested to date (Chrome, FF, and Safari) the onload or onerror combo fires every time. With IE 7,8 the readystate value may be a source of contention but the event(s) fire every time. Do you have any evidence to the contrary? Our cases deal only with <script> injection and specifically with JSON Callbacks. We are accessing and Application (Service-Now) in our Software Providers "cloud" and as the network/application response to The States can be woeful we desperately needed local (but cross-domain) data and business-rule access/validation. We also have an SSO product that can substitute a login page for our scripts when the session times-out. I submit to you (sorry "The Group" :-) that we have no silent failures and we can verify the completeness of the load of our scripts. So you maintain that I am living in cloud cuckoo land? Cheers Richard Maher |