Paul,
I still haven't had a chance to look at an example
excerpt of your code. If you can extract a few lines
showing the problem, maybe I can dig at it.

Anyway this patch is currently only for a very weird
problem in IE in particular occasion, namely when
the Back/Forward button are used and the page
is already cached, or when navigating through
a link to a page that is already cached, or
when no assets are present in the page,
or when other scripts in the BODY are
tricking the parser in to thing the page
is complete.

If any of the above seems the problem you have, you can try the
trick in a standalone function found here:

http://javascript.nwbox.com/IEContentLoaded/iecontentloaded.js

It is for IE only, call it by passing the window and the function
you want to execute. Hope it helps finding the problem.

Let us know your results.

--
Diego Perini



On 2 Giu, 20:33, Paul Cowan <dag...@...> wrote:
> Where is the patch?This is a problem I have had great problems with.Does this now mean I can reliably call document.ready()?dag...@...> Date: Mon, 2 Jun 2008 10:29:47 -0700> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets> From: diego.per...@...> 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 -> _________________________________________________________________
>
> http://clk.atdmt.com/UKM/go/msnnkmgl0010000002ukm/direct/01/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jQuery Development" group.
To post to this group, send email to jquery-dev@...
To unsubscribe from this group, send email to jquery-dev-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---