When is onload fired

A similar question was asked on codingforums a while back regarding the usage of window. The result seemed to be that you should use window. The general idea is that window. Contrarily, window. This means you can "emulate" window. Misread the question. Yes, it is entirely possible that the window. Scripts added using the DOM document. It then writes the value again a second later. Even with the script being cached, the first write to the console returns undefined , meaning the onload even has fired before the jQuery script has been downloaded and parsed.

Tested in IE and Chrome. Re: the comments, if you want to check if the onload event has already fired, you can set the value of a global variable inside the onload handler:. Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. When is window. Ask Question. Asked 11 years, 2 months ago. Active 2 years, 6 months ago. Viewed 36k times. I'm using window. From what I read this is the Any suggestions? I know there are some ways to get notified when the page body has loaded before all the images and 3rd party resources load which fires the window.

Can anyone tell me why the following page doesn't trigger an alert when it loads? If I use window. Why is there this Login using GitHub. And neither does business, but it takes a while for ideas to percolate to that level. And, as mentioned, there is no magic property to determine if the document has loaded. End of story for those examples. I think that this problem might be more complicated than you think ; Please consider all cases - together with lazy load :.

Realize that lazy loading of scripts is often indicative of lazy programmers trying to hide that they are using much too general and therefore bloated scripts. Or it may be Ajax-itis the compelling need to cram every app into one document. There is a compelling case to be made to a web user experience that resembles a stand-alone application.

Users generally get nervous when they are directed off the home page. Even web 2. Now, Ajax in it's current state may not be the way to get to the one-page application but the trend is to get there. The YUI Loader component is an attempt unsuccessful in my opinion to implement the component approach of application development.

In the end, the suggestion of testing a global variable is exactly what the OP is going to have to do. Every single script he downloads is going to have to know of this variable or function. That IS the current state of browser script load notification. I don't believe saying that the need for such an approach shows bad design is correct. And incompetence like this makes the Web even more of an accessibility nightmare, in a medium that should be open to as many people as possible.

Or the property of an object referred to by a global variable. There is no need if you use the modular approach properly. It's been done. I know. I've been writing such applications since IE4. The key word is "resembles" though. The user doesn't know or care how how much navigation is involved unless the design is so bad or the implementation so bloated as to make navigation a problem. I have no idea what that means. What home page?

The average user won't even notice moving from one page to the other if the two pages are similar. Don't know what that means either. Users are more used to navigating from one document to the next than to single-page docs that try to work like apps sporadically failing, which they do notice.

What trend? I've seen a lot of blithering about single page apps out there, but no explanation as to why Web developers think that is a general goal. Depends on what those scripts have to do. Context is king with this stuff. Making broad generalizations usually leads to failure. I don't follow. Show me a single-page "app" that is too slow to load ostensibly requiring a hare-brain scheme to make it usable and I'll show you a more appropriate multi-page design that isn't.

Lately it's becoming a career. Solution: The loaded script must not listen to any window load or readystatechange events and must not call document. 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. Decoupling the loaded scripts from the loader avoids the tight coupling and allows flexibility in loading.

In contrast, if the callbacks get attached in a hidden-in-module-scope onload, they fire only on load. This is a problem when innerHTML changes, and in your case where the onload may have already fired.

A dynamically loaded script must be designed in a way that it can be loaded at any time without problems. It must not call document.

Does this make sense? IIRC, I've seen a couple of strange things happen when doing so. Is it me, is it too much coke, or has somebody else seen any of these too? That's something to avoid, even in fantasy designs. I can't believe I'm saying this, but have a look at his response.

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. 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.

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. Based on available evidence I have to disagree. 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 KB" then that's just the bootstarp code and oodles more will be lazily-loaded? Seeing as some in this thread are seeking to draw the battle lines between: - a Single-Page applications and b a love afair with back-button optimation and browser history let me add my 2cents and introduce a 3rd option: - c Multi-Tab, Single-Browser-Instance applications with JAVA Applets, singletons and static class variables providing the inter-tab communication and application-global memory.

Regardless of the concerted attempts of Microsoft and Google, and the not insignificant prejudices of many here, I can't help seeing such a feature-rich development and deployment environment growing exponentially!

Especially since 6. Now if we only had a reliable mechanism come API for guaranteeing a page would be opened in a new tab in the same browser instance then that would really help me out a lot! Is it there and I just can't find it? With the amount of absolute bollocks to emerge from HTML5 surely something as useful as TAB-management syntax could have got a guernsey? And how the hell could they outlaw Frames??? Let's consign that back-button optimization to history Nobody is drawing those lines and if I understand you, they are not mutually exclusive either.

Context is what matters. Some apps make sense as a single document and there is no reason for any app to foul up navigation. I see GG recently figured out the latter point. Reason ii It really trashes the normal lifecycle of Applets So to all xenophobic, nervous-Nellies, clinging to the perceived security of yesteryear, I say "Burn your bridges, your boats and anything else that detracts from the now!

Who told you to do that? I know it is popular to try to make single pages look like multiple by screwing around with the hash, which must confuse the users who are used to single page apps. I wasn't saying there was. I was referring to one side of your drawn lines, not your Java idea. If a script is a 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. 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. 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? 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. I'm not sure.