> Date: Mon, 2 Jun 2008 10:29:47 -0700
> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets
> From: diego.perini@...
> To: jquery-dev@...
>
>
> Bumping....
>
> Let see if somebody care about this patch or wish to comment.
>
> --
> Diego Perini
>
>
> On 13 Mag, 17:40, Diego Perini <diego.per...@...> wrote:
> > 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 -
> --~--~---------~--~----~------------~-------~--~----~