> Brandon,
> don't forget this patch...it is important too for IE.
>
> The test case I added in the message above shows
> how the firing order is wrong in 1.2.2 / 1.2.3.
>
> The "onload" event may fire before the "ready()" method.
>
> With this patch in-place the poll interval can be made higher,
> so the browser is not kept so busy and can refresh/repaint
> faster.
>
> If you think part of the patch is not applicable or dangerous
> (having bindReady to always fire) tell me so I can remove
> that part.
>
> --
> Diego Perini
>
> On 30 Mar, 00:32, Diego Perini <diego.per...@...> wrote:
>
> > David, what you say is logical, and yes the "onreadystatechange"
> > is a valid hook for iframes too. Remember that this event normally
> > fires just few milliseconds before the "onload" event, so it is not
> > a real gain in early page enlivenment, but it is a good fall back.
>
> > About being restricted to the top window only is a big limitation.
> > In effect my original IEContentLoaded provides for a parameter,
> > which is the "window" we should listen on, so we can listen to any
> > open window or iframe window.
>
> > However, instead of this being the only place where this is taken
> > care of, we should see if in future versions of jQuery this logic
> > could be applied through all the code.
>
> > The point is, we shouldn't have direct references to "document",
> > instead it should be a parameter passed wherever is needed.
>
> > Hope I have correctly understand your concerns.
>
> > DiegoPerini
>
> > On 29 Mar, 19:35, David Serduke <davidserd...@...> wrote:
>
> > > Is there any reason the onreadystatechange event handler has to be
> > > restricted to window == top?  I'm really not very familiar with the
> > > details
> > > of that event in IE.  But if it is firing before onload then it would
> > > be a
> > > great thing to allow in frames to improve .ready() in those cases.
>
> > > David
>
> > > On Mar 29, 5:06 am,DiegoPerini<diego.per...@...> wrote:
>
> > > > I have filed a ticket for this bug, it is #2614.
>
> > > > This bug can introduce a possible different order of execution
> > > > between IE and the other browsers, since "onload" on IE can
> > > > fire before the ".ready()" method, while in other browsers this
> > > > is assured not to be the case and "ready" will always fire
> > > > before "onload".
>
> > > > It seems it is not only when no assets are present in the page,
> > > > I have tested with small images and the problem is still there.
>
> > > >DiegoPerini
>
> > > > On 21 Mar, 13:33,DiegoPerini<diego.per...@...> wrote:
>
> > > > > Here is a small test that should output this sequence:
>
> > > > > * readystatechange
> > > > > * iecontentloaded
> > > > > * load
>
> > > > > both in the body and in the window status bar (if enabled).
>
> > > > > The results with current jQuery and no assets is instead:
>
> > > > > * readystatechange
> > > > > * load
> > > > > * iecontentloaded
>
> > > > > thus the "onload" function fires before the ".ready()" method.
>
> > > > > Substitute square brackets with angle brackets in this code:
>
> > > > > [script type="text/javascript" src="jquery-1.2.3.js.orig"][/script]
> > > > > [script type="text/javascript"]
> > > > > /* IEContentLoaded test (jQuery implementation) */
> > > > > $(document).ready(function () {
> > > > >     document.body.innerHTML += ' * iecontentloaded[br /]';
> > > > >     status += ' * iecontentloaded';});
>
> > > > > /* Event "onready..." still available to applications */
> > > > > document.onreadystatechange = function () {
> > > > >     if (this.readyState == 'complete') {
> > > > >         document.body.innerHTML += ' * ' + event.type + '[br /]';
> > > > >         status += ' * ' + event.type;
> > > > >     }};
>
> > > > > /* Event "onload" still available to applications */
> > > > > window.onload = function () {
> > > > >     document.body.innerHTML += ' * ' + event.type + '[br /]';
> > > > >     status += ' * ' + event.type;};
>
> > > > > [/script]
>
> > > > > I already know where the problem lies, I only have to setup
> > > > > a patch for current code, hopefully including also the other
> > > > > expected behavior of ".ready()" being called by default
> > > > > at startup. This is for the "Lazy Loading" approach to
> > > > > work consistently (want to use "isReady()" later on).
>
> > > > >DiegoPerini
>
> > > > > On 20 Mar, 19:35,DiegoPerini<diego.per...@...> wrote:
>
> > > > > > This is only an IE problem.
>
> > > > > > The "onload" event always fire before the "ready()" method in IE
> > > > > > when there are no assets (images/objects/styles) in the page.
>
> > > > > > I already new the implementation of IEContentLoaded in jQuery
> > > > > > was not complete, but I was told that the "onload" fall back will
> > > > > > always be a last resort solution so there would not have been
> > > > > > problems, the correct firing would have taken care of anyway.
>
> > > > > > I need to setup some more test to show the exact problem,
> > > > > > then I will submit the needed patch for this eventuality.
>
> > > > > > This may be somehow related to the problem posted in this group
> > > > > > about lazy loading jQuery. If the user does not setup a "ready()"
> > > > > > wrapped function, isReady will never become true.
> > > > > > I should reread that post though.
>
> > > > > >DiegoPerini- Hide quoted text -
>
> > > > - Show quoted text -