Can script determine if window.onload has already fired?

Discussion in 'Javascript' started by Matt Kruse, Nov 19, 2009.

  1. Matt Kruse

    Matt Kruse Guest

    There is a discussion going on in the jquery-dev mailing list that
    piqued my curiosity. I'm interested to know if the smart people here
    have a good answer.

    Is there a cross-browser way, in script, to determine if window.onload
    has already fired?

    If a script is lazy loaded and needs the DOM to be ready, it can
    attach to the window's load event. But if that has already fired, then
    the script's code will never run. Alternatively, it can just fire its
    code inline, but the DOM may not be ready.

    Thoughts?

    Matt Kruse
     
    Matt Kruse, Nov 19, 2009
    #1
    1. Advertising

  2. Matt Kruse wrote:

    > There is a discussion going on in the jquery-dev mailing list that
    > piqued my curiosity. I'm interested to know if the smart people here
    > have a good answer.
    >
    > Is there a cross-browser way, in script, to determine if window.onload
    > has already fired?
    >
    > If a script is lazy loaded and needs the DOM to be ready, it can
    > attach to the window's load event.


    But it should not. The loading state of the window has nothing to do with
    the loading state of the document. We've been over this.

    > But if that has already fired, then the script's code will never run.
    > Alternatively, it can just fire its code inline, but the DOM may not be
    > ready.
    >
    > Thoughts?


    Smart people use the standards-compliant `onload' attribute instead.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
     
    Thomas 'PointedEars' Lahn, Nov 19, 2009
    #2
    1. Advertising

  3. Matt Kruse

    Matt Kruse Guest

    On Nov 19, 12:30 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > But it should not.  The loading state of the window has nothing to do with
    > the loading state of the document.  We've been over this.


    Fine then, substitute in any other method you prefer.

    > Smart people use the standards-compliant `onload' attribute instead.


    Could you be more specific?

    Matt Kruse
     
    Matt Kruse, Nov 19, 2009
    #3
  4. Matt Kruse wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> Smart people use the standards-compliant `onload' attribute instead.

    >
    > Could you be more specific?


    <body onload="...">


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Nov 19, 2009
    #4
  5. Matt Kruse

    Matt Kruse Guest

    On Nov 19, 1:06 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    >   <body onload="...">


    Script cannot add itself to this attribute, though.

    You're steering away from the real question, anyway. Regardless of
    whether you feel it should be used, is there any cross-browser way to
    detect if window.onload has already fired?

    Matt Kruse
     
    Matt Kruse, Nov 19, 2009
    #5
  6. Matt Kruse

    David Mark Guest

    On Nov 19, 3:07 pm, Matt Kruse <> wrote:
    > On Nov 19, 1:06 pm, Thomas 'PointedEars' Lahn <>
    > wrote:
    >
    > >   <body onload="...">

    >
    > Script cannot add itself to this attribute, though.


    Groan. Script doesn't have to "add itself" to this attribute.

    >
    > You're steering away from the real question, anyway.


    Yes.

    > Regardless of
    > whether you feel it should be used, is there any cross-browser way to
    > detect if window.onload has already fired?


    Of course. Attach a load listener (or use the standard onload
    attribute). They both do the same thing. One is proprietary and one
    is not.

    The proprietary window.onload property likely came about so that
    scripts in the HEAD could set a load listener to the BODY before the
    body is ready.

    Now, how to know if the BODY load event has fired? Set a flag, of
    course.
     
    David Mark, Nov 19, 2009
    #6
  7. Matt Kruse

    David Mark Guest

    On Nov 19, 12:55 pm, Matt Kruse <> wrote:

    [...]

    >
    > If a script is lazy loaded and needs the DOM to be ready, it can
    > attach to the window's load event. But if that has already fired, then
    > the script's code will never run. Alternatively, it can just fire its
    > code inline, but the DOM may not be ready.
    >


    And what sort of scheme are they working on where their scripts are
    unclear about whether the load event has fired? Sounds like a recipe
    for disaster to me.

    <body onload="loaded = true;">

    Or, as mentioned, set window.onload if you think that is a cooler,
    more "unobtrusive" solution (despite the inherent drawbacks).
     
    David Mark, Nov 19, 2009
    #7
  8. David Mark wrote:

    > On Nov 19, 3:07 pm, Matt Kruse <> wrote:
    >> On Nov 19, 1:06 pm, Thomas 'PointedEars' Lahn <>
    >> wrote:
    >> > <body onload="...">

    >>
    >> Script cannot add itself to this attribute, though.

    >
    > Groan. Script doesn't have to "add itself" to this attribute.


    See below.

    >> You're steering away from the real question, anyway.

    >
    > Yes.


    No. I was just closing at it at a slower pace :)

    >> Regardless of
    >> whether you feel it should be used, is there any cross-browser way to
    >> detect if window.onload has already fired?

    >
    > Of course. Attach a load listener (or use the standard onload
    > attribute). They both do the same thing. One is proprietary and one
    > is not.


    But if we assume that, due to the flawed concept, there are only "lazy-
    loaded" scripts, there is a chicken-and-the-egg problem with adding a load
    listener with scripting. Hence my recommendation to use the `onload'
    attribute of the `body' element in the first place.

    > The proprietary window.onload property likely came about so that
    > scripts in the HEAD could set a load listener to the BODY before the
    > body is ready.


    Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>

    > Now, how to know if the BODY load event has fired? Set a flag, of
    > course.


    That is what I was aiming at. But some people apparently need it to be
    spelt to them, so thank you for that.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
     
    Thomas 'PointedEars' Lahn, Nov 19, 2009
    #8
  9. Matt Kruse

    David Mark Guest

    On Nov 19, 5:34 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > David Mark wrote:
    > > On Nov 19, 3:07 pm, Matt Kruse <> wrote:
    > >> On Nov 19, 1:06 pm, Thomas 'PointedEars' Lahn <>
    > >> wrote:
    > >> > <body onload="...">

    >
    > >> Script cannot add itself to this attribute, though.

    >
    > > Groan.  Script doesn't have to "add itself" to this attribute.

    >
    > See below.
    >
    > >> You're steering away from the real question, anyway.

    >
    > > Yes.

    >
    > No.  I was just closing at it at a slower pace :)


    I figured. I'd just as soon be done with the discussion.

    >
    > >> Regardless of
    > >> whether you feel it should be used, is there any cross-browser way to
    > >> detect if window.onload has already fired?

    >
    > > Of course.  Attach a load listener (or use the standard onload
    > > attribute).  They both do the same thing.  One is proprietary and one
    > > is not.

    >
    > But if we assume that, due to the flawed concept, there are only "lazy-
    > loaded" scripts, there is a chicken-and-the-egg problem with adding a load
    > listener with scripting.  Hence my recommendation to use the `onload'
    > attribute of the `body' element in the first place.


    Right. The whole question is silly.

    >
    > > The proprietary window.onload property likely came about so that
    > > scripts in the HEAD could set a load listener to the BODY before the
    > > body is ready.

    >
    > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>


    I don't follow.
     
    David Mark, Nov 19, 2009
    #9
  10. Matt Kruse

    Jorge Guest

    On Nov 19, 11:34 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    >
    > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>


    If you specify an onLoad event handler for an Image object that
    displays a looping GIF animation (multi-image GIF), each loop of the
    animation triggers the onLoad event, and the event handler executes
    once for each loop.

    Is this true ?
    --
    Jorge.
     
    Jorge, Nov 19, 2009
    #10
  11. Matt Kruse

    David Mark Guest

    On Nov 19, 5:54 pm, Jorge <> wrote:
    > On Nov 19, 11:34 pm, Thomas 'PointedEars' Lahn <>
    > wrote:
    >
    >
    >
    > > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>

    >
    > If you specify an onLoad event handler for an Image object that
    > displays a looping GIF animation (multi-image GIF), each loop of the
    > animation triggers the onLoad event, and the event handler executes
    > once for each loop.
    >
    > Is this true ?


    It was. Not a concern today as nobody (sane) uses animated GIF's on
    the Web.
     
    David Mark, Nov 19, 2009
    #11
  12. Matt Kruse

    Jorge Guest

    On Nov 20, 12:01 am, David Mark <> wrote:
    > On Nov 19, 5:54 pm, Jorge <> wrote:
    >
    > > On Nov 19, 11:34 pm, Thomas 'PointedEars' Lahn <>
    > > wrote:

    >
    > > > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>

    >
    > > If you specify an onLoad event handler for an Image object that
    > > displays a looping GIF animation (multi-image GIF), each loop of the
    > > animation triggers the onLoad event, and the event handler executes
    > > once for each loop.

    >
    > > Is this true ?

    >
    > It was.  Not a concern today as nobody (sane) uses animated GIF's on
    > the Web.


    Not even spinners ?
    --
    Jorge.
     
    Jorge, Nov 19, 2009
    #12
  13. David Mark wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> David Mark wrote:
    >> > The proprietary window.onload property likely came about so that
    >> > scripts in the HEAD could set a load listener to the BODY before the
    >> > body is ready.

    >>
    >> Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>

    >
    > I don't follow.


    There is no mentioning of setting a listener to the BODY with window.onload
    there.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
     
    Thomas 'PointedEars' Lahn, Nov 19, 2009
    #13
  14. Jorge meinte:
    > On Nov 20, 12:01 am, David Mark <> wrote:


    >> It was. Not a concern today as nobody (sane) uses animated GIF's on
    >> the Web.

    >
    > Not even spinners ?


    An onload listener for spinners which indicate loading processes? Sound
    pretty recursive...

    Gregor


    --
    http://www.gregorkofler.com
     
    Gregor Kofler, Nov 19, 2009
    #14
  15. Matt Kruse

    Jorge Guest

    On Nov 20, 12:23 am, Gregor Kofler <> wrote:
    > Jorge meinte:
    >
    > > On Nov 20, 12:01 am, David Mark <> wrote:
    > >> It was.  Not a concern today as nobody (sane) uses animated GIF's on
    > >> the Web.

    >
    > > Not even spinners ?

    >
    > An onload listener for spinners which indicate loading processes? Sound
    > pretty recursive...


    LOL, yes. I've tested it and doesn't work in any (current) browser, as
    Mark said.
    --
    Jorge.
     
    Jorge, Nov 19, 2009
    #15
  16. Matt Kruse

    David Mark Guest

    On Nov 19, 6:09 pm, Jorge <> wrote:
    > On Nov 20, 12:01 am, David Mark <> wrote:
    >
    >
    >
    > > On Nov 19, 5:54 pm, Jorge <> wrote:

    >
    > > > On Nov 19, 11:34 pm, Thomas 'PointedEars' Lahn <>
    > > > wrote:

    >
    > > > > Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>

    >
    > > > If you specify an onLoad event handler for an Image object that
    > > > displays a looping GIF animation (multi-image GIF), each loop of the
    > > > animation triggers the onLoad event, and the event handler executes
    > > > once for each loop.

    >
    > > > Is this true ?

    >
    > > It was.  Not a concern today as nobody (sane) uses animated GIF's on
    > > the Web.

    >
    > Not even spinners ?


    Certainly not paired with an onload listener. ;) And I think the
    onload firing on-loop issue is only in ancient browsers.
     
    David Mark, Nov 19, 2009
    #16
  17. Matt Kruse

    Matt Kruse Guest

    On Nov 19, 4:00 pm, David Mark <> wrote:
    > And what sort of scheme are they working on where their scripts are
    > unclear about whether the load event has fired?  Sounds like a recipe
    > for disaster to me.


    Apparently some people want to lazy-load scripts (libraries, etc) that
    are not needed immediately for page rendering, so they don't block and
    slow down the page load. As a way of getting the UI to the user faster
    and then add script for when they interact.

    I'm not a big fan of doing things onload of the page, especially not
    attaching critical functionality. A common jQuery recommendation is to
    wrap code in $(document).ready() so it fires when the DOM is ready, at
    which point you can attach event handlers, etc. I always recommend
    against this approach for a number of reasons, and I rarely (if ever)
    use this approach.

    Nevertheless, there are many plugins and 3rd-party components that use
    this approach, and if you lazy-load jQuery after window.onload has
    fired then these scripts will try to attach to the event and it will
    never fire.

    I thought it was an interesting question, as to whether or not the
    condition could be checked in script.

    > <body onload="loaded = true;">


    And this is not possible by a lazy-loaded script, which was the point
    of the original question. A script retrieved and eval'd via ajax will
    obviously not be able to add code to a static html tag.

    > Or, as mentioned, set window.onload if you think that is a cooler,
    > more "unobtrusive" solution (despite the inherent drawbacks).


    Solve the problem by turning a blind eye? :)

    Matt Kruse
     
    Matt Kruse, Nov 20, 2009
    #17
  18. Matt Kruse

    David Mark Guest

    On Nov 19, 9:05 pm, Matt Kruse <> wrote:
    > On Nov 19, 4:00 pm, David Mark <> wrote:
    >
    > > And what sort of scheme are they working on where their scripts are
    > > unclear about whether the load event has fired?  Sounds like a recipe
    > > for disaster to me.

    >
    > Apparently some people want to lazy-load scripts (libraries, etc) that
    > are not needed immediately for page rendering, so they don't block and
    > slow down the page load. As a way of getting the UI to the user faster
    > and then add script for when they interact.


    Some people use jQuery, which is a huge hit to start with. It's a
    crazy world.

    >
    > I'm not a big fan of doing things onload of the page, especially not
    > attaching critical functionality. A common jQuery recommendation is to
    > wrap code in $(document).ready() so it fires when the DOM is ready, at
    > which point you can attach event handlers, etc. I always recommend
    > against this approach for a number of reasons, and I rarely (if ever)
    > use this approach.


    Seems sensible given they've been fretting that function for years and
    it is known to be a bunch of hacks strung together by observation. I
    read the recent exchanges and they are going down the same road to
    "solve" this case.

    >
    > Nevertheless, there are many plugins and 3rd-party components that use
    > this approach, and if you lazy-load jQuery after window.onload has
    > fired then these scripts will try to attach to the event and it will
    > never fire.


    Load the entire _library_ after load? The idea is completely absurd.
    But a flag still works. All jQuery has to do is check the flag and
    act accordingly.

    >
    > I thought it was an interesting question, as to whether or not the
    > condition could be checked in script.
    >
    > > <body onload="loaded = true;">

    >
    > And this is not possible by a lazy-loaded script, which was the point
    > of the original question.


    You just don't get it. The flag is for the lazy loaded script.
    That's how it knows that the load event for the body has fired. You
    could also use window.onload or attach a load listener to the body
    (assuming your script is not in the head).

    > A script retrieved and eval'd via ajax will
    > obviously not be able to add code to a static html tag.


    A script retrieved and eval'd via Ajax? There go all of your
    perceived speed benefits. Doing that with a script like jQuery is
    absurd.

    And of course it could set that attribute, but that's not the point.
    The point is that it won't do anything. Neither will window.onload,
    which could also be set by the evaluated script. But if the evaluated
    script checked a flag first or called a predetermined global function
    to add "ready listeners". Last line of the loaded script would "fire"
    all of them in turn if the flag is set (or call a function to do the
    same thing).

    >
    > > Or, as mentioned, set window.onload if you think that is a cooler,
    > > more "unobtrusive" solution (despite the inherent drawbacks).

    >
    > Solve the problem by turning a blind eye? :)


    No.
     
    David Mark, Nov 20, 2009
    #18
  19. Matt Kruse

    Stevo Guest

    Matt Kruse wrote:
    > There is a discussion going on in the jquery-dev mailing list that
    > piqued my curiosity. I'm interested to know if the smart people here
    > have a good answer.
    >
    > Is there a cross-browser way, in script, to determine if window.onload
    > has already fired?
    >
    > If a script is lazy loaded and needs the DOM to be ready, it can
    > attach to the window's load event. But if that has already fired, then
    > the script's code will never run. Alternatively, it can just fire its
    > code inline, but the DOM may not be ready.
    >
    > Thoughts?
    >
    > Matt Kruse


    Shame there was no resolution to this. I was hoping for an answer to it
    also. Instead of focusing on the question (the second paragraph above)
    all the answers disregarded it.

    I guess there is no way to find out if it's fired using regular DOM methods.
     
    Stevo, Nov 23, 2009
    #19
  20. Matt Kruse

    Matt Kruse Guest

    On Nov 23, 1:46 pm, Stevo <> wrote:
    > Shame there was no resolution to this. I was hoping for an answer to it
    > also. Instead of focusing on the question (the second paragraph above)
    > all the answers disregarded it.


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

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


    It doesn't appear so.

    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.

    Matt Kruse
     
    Matt Kruse, Nov 23, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Patrick Olurotimi Ige
    Replies:
    6
    Views:
    540
    =?Utf-8?B?TmljZW1hbg==?=
    Mar 11, 2005
  2. datactrl
    Replies:
    3
    Views:
    160
    Thomas 'PointedEars' Lahn
    May 29, 2004
  3. Brian
    Replies:
    6
    Views:
    173
  4. David Otton

    window.onload and body.onload differences

    David Otton, Nov 4, 2004, in forum: Javascript
    Replies:
    2
    Views:
    615
    Martin Honnen
    Nov 4, 2004
  5. Replies:
    5
    Views:
    316
    Thomas 'PointedEars' Lahn
    May 15, 2005
Loading...

Share This Page