Can script determine if window.onload has already fired?

[RobG]

Shame there was no resolution to this.

There was a resolution.

I was hoping for an answer to it
also.

There was.

Instead of focusing on the question (the second paragraph above)
all the answers disregarded it.

There were two answers that focussed specifically on the question and
provided two approaches.

I guess there is no way to find out if it's fired using regular DOM methods.

You got it, but that wasn't the question. There was no specific
mention of a DOM method, but that doesn't mean there aren't strategies
for determining if it's occurred.

 

[David Mark]

Typical of this group, which is why it's become mostly irrelevant.

Typical of your petulance and incompetence, you can't see the forest
for the trees. Clearly you came into this fact-finding mission with a
negative attitude (as usual).

It doesn't appear so.

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.

Or to phrase it differently, a script that is executing after the
firing of window.onload has no independent way of determining that it
has already fired.

No kidding. You should have put it that way to start with.

 

[Matt Kruse]

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

 

[Stevo]

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

 

[David Mark]

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?

 

[David Mark]

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?)

 

[Stevo]

And site A is running some script that can load scripts (call it
script X).


Doesn't matter as script X will set a global flag when onload fires.


Check the flag.


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.

 

[David Mark]

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.

 

[Stevo]

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?


And answered. You (and Matt Kruse) are definitely missing something.
Bad company.


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.

 

[David Mark]

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?

 

[Garrett Smith]

On Nov 23, 8:15 pm, David Mark <[email protected]> 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

 

[David Mark]

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

 

[David Mark]

On Nov 23, 8:15 pm, David Mark <[email protected]> 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

 

[Stevo]

On Nov 23, 8:15 pm, David Mark <[email protected]> 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.

 

[Stevo]

I think you are confused.


There it is. I am assuming no such thing.


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.

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.

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.


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.


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


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.


What issue?

You'll come across it one day, but until you do, it's nothing to worry
about.

 

[David Mark]

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?

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.

 

[Garrett Smith]

[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!

 

[wilq]

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);
}

})();

 

[Matt Kruse]

And, pray tell, what would have loaded it after onload?

For example, something like GreaseMonkey. Or any tool which injects
scripts. Or perhaps a bookmarklet. Use your imagination, there are a
number of cases where a script under your control is injected into a
document and you have no control over the source document or when/how
your code gets inserted.

The ajax/eval method was just an example.

Matt Kruse

 

[Matt Kruse]

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.

Indeed.

The lower signal/noise ration in here and the fewer posts is an
indicator as well.

 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.

The jQuery group is being moved away from Groups because of
unmanageable spam. The number of readers may be reflected by this.

Or perhaps jQuery is becoming so well known and documented that not as
many people need help with it. How do you like them apples?

Or perhaps jQuery popularity is fading. If that's the case, so be it.
Perhaps it will be replaced by something different as the most popular
scripting library. Doesn't matter to me.

Matt Kruse