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.
/* 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).
Diego Perini
On 20 Mar, 19:35, Diego Perini <diego.per...@gmail.com> wrote:
> 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.
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.
Diego Perini
On 21 Mar, 13:33, Diego Perini <diego.per...@gmail.com> wrote:
> /* 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).
> Diego Perini
> On 20 Mar, 19:35, Diego Perini <diego.per...@gmail.com> 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.
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, Diego Perini <diego.per...@gmail.com> 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.
> Diego Perini
> On 21 Mar, 13:33, Diego Perini <diego.per...@gmail.com> wrote:
> > Here is a small test that should output this sequence:
> > /* 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).
> > Diego Perini
> > On 20 Mar, 19:35, Diego Perini <diego.per...@gmail.com> 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.
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.
Diego Perini
On 29 Mar, 19:35, David Serduke <davidserd...@gmail.com> 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, Diego Perini <diego.per...@gmail.com> 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.
> > Diego Perini
> > On 21 Mar, 13:33, Diego Perini <diego.per...@gmail.com> wrote:
> > > Here is a small test that should output this sequence:
> > > /* 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).
> > > Diego Perini
> > > On 20 Mar, 19:35, Diego Perini <diego.per...@gmail.com> 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.
> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> wrote:
> > > > Here is a small test that should output this sequence:
> > > > /* 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...@gmail.com> 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.
> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> wrote:
> > > > > Here is a small test that should output this sequence:
> > > > > /* 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...@gmail.com> 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.
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...@hotmail.com> Date: Mon, 2 Jun 2008 10:29:47 -0700> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets> From: diego.per...@gmail.com> To: jquery-dev@googlegroups.com> > > Bumping....> > Let see if somebody care about this patch or wish to comment.> > --> Diego Perini> > > On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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 -> _________________________________________________________________
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:
> 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...@hotmail.com> Date: Mon, 2 Jun 2008 10:29:47 -0700> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets> From: diego.per...@gmail.com> To: jquery-dev@googlegroups.com> > > Bumping....> > Let see if somebody care about this patch or wish to comment.> > --> Diego Perini> > > On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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 -> _________________________________________________________________
The problem is best described here.http://dean.edwards.name/weblog/2005/09/busted/I was using $(ready) to call an AJAX function that inserts html into a div.The problem being that sometimes (in IE7) the browser would hang. The status bar would say something like 'downloading image http://blah.blah.gif" The browser would then just hang in this state.It did not happen everytime but it did happen enough times for me to seek an alternative.The link above was that alternative and so far no problems but it does rely on external .js fileWould be nice if I could use $(ready)dag...@hotmail.com> Date: Mon, 2 Jun 2008 13:09:37 -0700> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets> From: diego.per...@gmail.com> To: jquery-dev@googlegroups.com> > > 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...@hotmail.com> 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...@hotmail.com> Date: Mon, 2 Jun 2008 10:29:47 -0700> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets> From: diego.per...@gmail.com> To: jquery-dev@googlegroups.com> > > Bumping....> > Let see if somebody care about this patch or wish to comment.> > --> Diego Perini> > > On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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/> _________________________________________________________________
Paul,
everybody knows the problem and that thread very well,
Dean HTC solution with an external file is still the best
and most standard way of doing that detection on IE.
It is well supported and documented by Microsoft.
The trick I sent you was written to avoid the same problems
described there it just don't use the same "document.write"
method and still rely on some Microsoft comment about
the doScroll() behavior related to the ondocumentready.-
So try the function in the link I posted above and tell...
--
Diego Perini
On 2 Giu, 22:59, Paul Cowan <dag...@hotmail.com> wrote:
> The problem is best described here.http://dean.edwards.name/weblog/2005/09/busted/Iwas using $(ready) to call an AJAX function that inserts html into a div.The problem being that sometimes (in IE7) the browser would hang. The status bar would say something like 'downloading imagehttp://blah.blah.gif"
> The browser would then just hang in this state.It did not happen everytime but it did happen enough times for me to seek an alternative.The link above was that alternative and so far no problems but it does rely on external .js fileWould be nice if I could use $(ready)dag...@hotmail.com> Date: Mon, 2 Jun 2008 13:09:37 -0700> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets> From: diego.per...@gmail.com> To: jquery-dev@googlegroups.com> > > 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...@hotmail.com> 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...@hotmail.com> Date: Mon, 2 Jun 2008 10:29:47 -0700> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets> From: diego.per...@gmail.com> To: jquery-dev@googlegroups.com> > > Bumping....> > Let see if somebody care about this patch or wish to comment.> > --> Diego Perini> > > On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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/> _________________________________________________________________
I've read your code, both IEContentLoaded & ContentLoaded, when I was digging on how to detect DOM ready under IE. It's great and help me a lot because defer script effect earlier when someone modified the DOM.
But my question is, is there any method to detect DOM ready in a frame? I saw your code using onreadystatechange to detect it when current window is not a top window. -- With best regards! Sincerely, Wenjie(Jay) Xie
> 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:
> 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...@hotmail.com> 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...@hotmail.com> Date: Mon, 2 Jun 2008 10:29:47 -0700> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets> From: diego.per...@gmail.com> To: jquery-dev@googlegroups.com> > > Bumping....> > Let see if somebody care about this patch or wish to comment.> > --> Diego Perini> > > On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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) tel
l me so I can remove> > that part.> >> > --> > Diego Perini> >> > On 30 Mar, 00:32, Diego Perini <diego.per...@gmail.com> 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 n eeded.> >> > > Hope I have correctly understand your concerns.> >> > > DiegoPerini> >> > > On 29 Mar, 19:35, David Serduke <davidserd...@gmail.com> 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...@gmail.com> 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 ass ets 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...@gmail.com> 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...@gmail.com> 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 thoug
h.> >> > > > > > >DiegoPerini- Hide quoted text -> >> > > > > - Show quoted text -> _________________________________________________________________
JayXie,
unfortunately a solution for IFRAMEs is not readily available for IE
yet.
In other browsers you can attach a "DOMFrameContentLoaded" on
the primary document, and that will work like the "DOMContentLoaded"
does on the main document. Remember on the primary document,
not on the IFRAME itself.
A cross-browser solution will be to use event delegation so you will
not need an "onload" or similar method for most things and your script
will be able to start as soon as they are loaded without the need to
wait
for all the page to be loaded. This requires advanced tools to wrap
the
pain of setting up a decent system so if you need a jQuery solution
your alternative is to use Ariel Flesler Listen plugin for jQuery.
Ariel has somehow documented his work and is maintaining it.
If you want to look at a standalone code that does exactly that
have a look here:
> I've read your code, both IEContentLoaded & ContentLoaded, when I was
> digging on how to detect DOM ready under IE. It's great and help me a
> lot because defer script effect earlier when someone modified the DOM.
> But my question is, is there any method to detect DOM ready in a frame?
> I saw your code using onreadystatechange to detect it when current
> window is not a top window.
> --
> With best regards!
> Sincerely,
> Wenjie(Jay) Xie
> > 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:
> > 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...@hotmail.com> 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...@hotmail.com> Date: Mon, 2 Jun 2008 10:29:47 -0700> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets> From: diego.per...@gmail.com> To: jquery-dev@googlegroups.com> > > Bumping....> > Let see if somebody care about this patch or wish to comment.> > --> Diego Perini> > > On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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) tel
> l me so I can remove> > that part.> >> > --> > Diego Perini> >> > On 30 Mar, 00:32, Diego Perini <diego.per...@gmail.com> 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 n
> eeded.> >> > > Hope I have correctly understand your concerns.> >> > > DiegoPerini> >> > > On 29 Mar, 19:35, David Serduke <davidserd...@gmail.com> 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...@gmail.com> 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 ass
> ets 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...@gmail.com> 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...@gmail.com> 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 thoug
> h.> >> > > > > > >DiegoPerini- Hide quoted text -> >> > > > > - Show quoted text -> _________________________________________________________________
If I haven't got the wrong understanding, the event delegation mechanism seems is to solve the event handling problem, but cannot solve the DOM modifying problem such as insert an element at the beginning of the body element.
Although many solutions can be used to avoid it, one is to put the script at the top level of the body element which is documented in http://support.microsoft.com/default.aspx/kb/927917 . But these are just avoid not really solving it. For many cases you can not insure you script is put at the top level or even in the body element.
May be this cannot be solved, but thank you all the same for your reply! -- With best regards! Sincerely, Wenjie(Jay) Xie
> JayXie, > unfortunately a solution for IFRAMEs is not readily available for IE > yet.
> In other browsers you can attach a "DOMFrameContentLoaded" on > the primary document, and that will work like the "DOMContentLoaded" > does on the main document. Remember on the primary document, > not on the IFRAME itself.
> A cross-browser solution will be to use event delegation so you will > not need an "onload" or similar method for most things and your script > will be able to start as soon as they are loaded without the need to > wait > for all the page to be loaded. This requires advanced tools to wrap > the > pain of setting up a decent system so if you need a jQuery solution > your alternative is to use Ariel Flesler Listen plugin for jQuery.
> Ariel has somehow documented his work and is maintaining it.
> If you want to look at a standalone code that does exactly that > have a look here:
> no documentation and no help yet, but you may get an idea of > what I am talking about and probably be able to do your own > stuff with it.
> -- > Diego Perini
> On 3 Giu, 04:49, JayXie <jay.w....@gmail.com> wrote: >> I've read your code, both IEContentLoaded & ContentLoaded, when I was >> digging on how to detect DOM ready under IE. It's great and help me a >> lot because defer script effect earlier when someone modified the DOM.
>> But my question is, is there any method to detect DOM ready in a frame? >> I saw your code using onreadystatechange to detect it when current >> window is not a top window. >> -- >> With best regards! >> Sincerely, >> Wenjie(Jay) Xie
>>> 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...@hotmail.com> 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...@hotmail.com> Date: Mon, 2 Jun 2008 10:29:47 -0700> Subject: [jquery-dev] Re: Implementation of DOMContentLoaded failing when no assets> From: diego.per...@gmail.com> To: jquery-dev@googlegroups.com> > > Bumping....> > Let see if somebody care about this patch or wish to comment.> > --> Diego Perini> > > On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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) t el >> l me so I can remove> > that part.> >> > --> > Diego Perini> >> > On 30 Mar, 00:32, Diego Perini <diego.per...@gmail.com> 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 i s n >> eeded.> >> > > Hope I have correctly understand your concerns.> >> > > DiegoPerini> >> > > On 29 Mar, 19:35, David Serduke <davidserd...@gmail.com> 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...@gmail.com> 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 ass >> ets 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...@gmail.com> 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.innerHTM L + >> = ' * 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...@gmail.com> 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 th oug
>> h.> >> > > > > > >DiegoPerini- Hide quoted text -> >> > > > > - Show quoted text -> _________________________________________________________________
you can always achieve that task you described, though you must ensure
the "document,body" is already present in the DOM, so for a cross-
browser solution a loop waiting for the "BODY" element will be enough,
then use the above method to add your element/s...
--
Diego Perini
On 4 Giu, 05:53, JayXie <jay.w....@gmail.com> wrote:
> If I haven't got the wrong understanding, the event delegation mechanism
> seems is to solve the event handling problem, but cannot solve the DOM
> modifying problem such as insert an element at the beginning of the body
> element.
> Although many solutions can be used to avoid it, one is to put the
> script at the top level of the body element which is documented inhttp://support.microsoft.com/default.aspx/kb/927917. But these are just
> avoid not really solving it. For many cases you can not insure you
> script is put at the top level or even in the body element.
> May be this cannot be solved, but thank you all the same for your reply!
> --
> With best regards!
> Sincerely,
> Wenjie(Jay) Xie
> > JayXie,
> > unfortunately a solution for IFRAMEs is not readily available for IE
> > yet.
> > In other browsers you can attach a "DOMFrameContentLoaded" on
> > the primary document, and that will work like the "DOMContentLoaded"
> > does on the main document. Remember on the primary document,
> > not on the IFRAME itself.
> > A cross-browser solution will be to use event delegation so you will
> > not need an "onload" or similar method for most things and your script
> > will be able to start as soon as they are loaded without the need to
> > wait
> > for all the page to be loaded. This requires advanced tools to wrap
> > the
> > pain of setting up a decent system so if you need a jQuery solution
> > your alternative is to use Ariel Flesler Listen plugin for jQuery.
> > Ariel has somehow documented his work and is maintaining it.
> > If you want to look at a standalone code that does exactly that
> > have a look here:
> > no documentation and no help yet, but you may get an idea of
> > what I am talking about and probably be able to do your own
> > stuff with it.
> > --
> > Diego Perini
> > On 3 Giu, 04:49, JayXie <jay.w....@gmail.com> wrote:
> >> I've read your code, both IEContentLoaded & ContentLoaded, when I was
> >> digging on how to detect DOM ready under IE. It's great and help me a
> >> lot because defer script effect earlier when someone modified the DOM.
> >> But my question is, is there any method to detect DOM ready in a frame?
> >> I saw your code using onreadystatechange to detect it when current
> >> window is not a top window.
> >> --
> >> With best regards!
> >> Sincerely,
> >> Wenjie(Jay) Xie
> >>> 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...@hotmail.com> 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...@hotmail.com> Date: Mon, 2 Jun 2008 10:29:47 -0700> Subject: [jquery-dev] Re: Implementation ofDOMContentLoadedfailing when no assets> From: diego.per...@gmail.com> To: jquery-dev@googlegroups.com> > > Bumping....> > Let see if somebody care about this patch or wish to comment.> > --> Diego Perini> > > On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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) t
> el
> >> l me so I can remove> > that part.> >> > --> > Diego Perini> >> > On 30 Mar, 00:32, Diego Perini <diego.per...@gmail.com> 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 i
> s n
> >> eeded.> >> > > Hope I have correctly understand your concerns.> >> > > DiegoPerini> >> > > On 29 Mar, 19:35, David Serduke <davidserd...@gmail.com> 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...@gmail.com> 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
> ass
> >> ets 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...@gmail.com> 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.innerHTM
> L +
> >> = ' * 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...@gmail.com> 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
Brandon,
I suspect something must be wrong with how this ticket (#2614) was
submitted, or just missed it.
It seems to me nothing has changed for this from 1.2.2 to 1.2.6, could
you please comment about it so I can adjust the patch just in case.
Both Prototype and Google already adopted the full IEContentLoaded
method as described, it correct the firing order that is now wrong on
IE.
This is admittedly hard to reproduce in general usage but is
documented to break in different situations, probably also unrelated
to assets as the title of the thread may state.
The small test case in this same thread is just an example showing the
order in which load events fire is currently wrong.
Probably the most obvious side effect is that on Internet Explorer
some code may execute in a different order than on the other browsers,
producing inconsistent behaviors hard to track as a problem.
And as David noticed above, it could also be improved for iframes
using the same "onreadystatechange" event, just another late fall
back, but still keeping the order correct (an important part).... :-)
So...re-bumping...
--
Diego Perini
On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> wrote:
> > > > > Here is a small test that should output this sequence:
> > > > > /* 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...@gmail.com> 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.
Tested with IE 5.5, 6, 7, 8 beta, works with 5 if you want, using concat instead of splice.
Supports multiple documents, multiple events, respects events queue, and using interval instead of timeout, could be a bit ( really a little bit ) faster thanks to its unpredictable execution ( as you know, timeout is always the expected one, or more )
Kind Regards
On Sat, Jul 12, 2008 at 12:20 PM, Diego Perini <diego.per...@gmail.com> wrote:
> Brandon, > I suspect something must be wrong with how this ticket (#2614) was > submitted, or just missed it.
> It seems to me nothing has changed for this from 1.2.2 to 1.2.6, could > you please comment about it so I can adjust the patch just in case.
> Both Prototype and Google already adopted the full IEContentLoaded > method as described, it correct the firing order that is now wrong on > IE.
> This is admittedly hard to reproduce in general usage but is > documented to break in different situations, probably also unrelated > to assets as the title of the thread may state.
> The small test case in this same thread is just an example showing the > order in which load events fire is currently wrong.
> Probably the most obvious side effect is that on Internet Explorer > some code may execute in a different order than on the other browsers, > producing inconsistent behaviors hard to track as a problem.
> And as David noticed above, it could also be improved for iframes > using the same "onreadystatechange" event, just another late fall > back, but still keeping the order correct (an important part).... :-)
> So...re-bumping...
> -- > Diego Perini
> On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> wrote:
> > > > > > Here is a small test that should output this sequence:
> > > > > > 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...@gmail.com> 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.
> Tested with IE 5.5, 6, 7, 8 beta, works with 5 if you want, using concat > instead of splice.
> Supports multiple documents, multiple events, respects events queue, and > using interval instead of timeout, could be a bit ( really a little bit ) > faster thanks to its unpredictable execution ( as you know, timeout is > always the expected one, or more )
> Kind Regards
> On Sat, Jul 12, 2008 at 12:20 PM, Diego Perini <diego.per...@gmail.com> > wrote:
>> Brandon, >> I suspect something must be wrong with how this ticket (#2614) was >> submitted, or just missed it.
>> It seems to me nothing has changed for this from 1.2.2 to 1.2.6, could >> you please comment about it so I can adjust the patch just in case.
>> Both Prototype and Google already adopted the full IEContentLoaded >> method as described, it correct the firing order that is now wrong on >> IE.
>> This is admittedly hard to reproduce in general usage but is >> documented to break in different situations, probably also unrelated >> to assets as the title of the thread may state.
>> The small test case in this same thread is just an example showing the >> order in which load events fire is currently wrong.
>> Probably the most obvious side effect is that on Internet Explorer >> some code may execute in a different order than on the other browsers, >> producing inconsistent behaviors hard to track as a problem.
>> And as David noticed above, it could also be improved for iframes >> using the same "onreadystatechange" event, just another late fall >> back, but still keeping the order correct (an important part).... :-)
>> So...re-bumping...
>> -- >> Diego Perini
>> On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> wrote:
>> > > > > > Here is a small test that should output this sequence:
>> > > > > > 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...@gmail.com> 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.
>> Tested with IE 5.5, 6, 7, 8 beta, works with 5 if you want, using concat >> instead of splice.
>> Supports multiple documents, multiple events, respects events queue, and >> using interval instead of timeout, could be a bit ( really a little bit ) >> faster thanks to its unpredictable execution ( as you know, timeout is >> always the expected one, or more )
>> Kind Regards
>> On Sat, Jul 12, 2008 at 12:20 PM, Diego Perini <diego.per...@gmail.com> >> wrote:
>>> Brandon, >>> I suspect something must be wrong with how this ticket (#2614) was >>> submitted, or just missed it.
>>> It seems to me nothing has changed for this from 1.2.2 to 1.2.6, could >>> you please comment about it so I can adjust the patch just in case.
>>> Both Prototype and Google already adopted the full IEContentLoaded >>> method as described, it correct the firing order that is now wrong on >>> IE.
>>> This is admittedly hard to reproduce in general usage but is >>> documented to break in different situations, probably also unrelated >>> to assets as the title of the thread may state.
>>> The small test case in this same thread is just an example showing the >>> order in which load events fire is currently wrong.
>>> Probably the most obvious side effect is that on Internet Explorer >>> some code may execute in a different order than on the other browsers, >>> producing inconsistent behaviors hard to track as a problem.
>>> And as David noticed above, it could also be improved for iframes >>> using the same "onreadystatechange" event, just another late fall >>> back, but still keeping the order correct (an important part).... :-)
>>> So...re-bumping...
>>> -- >>> Diego Perini
>>> On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> wrote:
>>> > > > > > Here is a small test that should output this sequence:
>>> > > > > > 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...@gmail.com> wrote:
>>> > > > > > > This is only an IE problem.
>>> > > > > > > The "onload" event always fire before the "ready()" method in >>> IE
Andrea,
also it may be OK your code resumes a standalone version specific for
IE, jQuery need a patch (addition) in the detection logic and having a
better fall back support for iframes.
The collections of handlers are already handled for all browsers, not
just IE, in another piece of code in jQuery.ready(), and it seems
there are no problem in that part.
One tip I want you to remember about your code above, the "init()"
should be called outside the try/catch block to avoid hiding useful
informations to developers.
I believe this is applicable to Mootools too if you dare to convince
them about it... :-)
--
Diego Perini
On 12 Lug, 14:39, "Andrea Giammarchi" <andrea.giammar...@gmail.com>
wrote:
> > Tested with IE 5.5, 6, 7, 8 beta, works with 5 if you want, using concat
> > instead of splice.
> > Supports multiple documents, multiple events, respects events queue, and
> > using interval instead of timeout, could be a bit ( really a little bit )
> > faster thanks to its unpredictable execution ( as you know, timeout is
> > always the expected one, or more )
> > Kind Regards
> > On Sat, Jul 12, 2008 at 12:20 PM, Diego Perini <diego.per...@gmail.com>
> > wrote:
> >> Brandon,
> >> I suspect something must be wrong with how this ticket (#2614) was
> >> submitted, or just missed it.
> >> It seems to me nothing has changed for this from 1.2.2 to 1.2.6, could
> >> you please comment about it so I can adjust the patch just in case.
> >> Both Prototype and Google already adopted the full IEContentLoaded
> >> method as described, it correct the firing order that is now wrong on
> >> IE.
> >> This is admittedly hard to reproduce in general usage but is
> >> documented to break in different situations, probably also unrelated
> >> to assets as the title of the thread may state.
> >> The small test case in this same thread is just an example showing the
> >> order in which load events fire is currently wrong.
> >> Probably the most obvious side effect is that on Internet Explorer
> >> some code may execute in a different order than on the other browsers,
> >> producing inconsistent behaviors hard to track as a problem.
> >> And as David noticed above, it could also be improved for iframes
> >> using the same "onreadystatechange" event, just another late fall
> >> back, but still keeping the order correct (an important part).... :-)
> >> So...re-bumping...
> >> --
> >> Diego Perini
> >> On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> wrote:
> >> > > > > > Here is a small test that should output this sequence:
> >> > > > > > 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...@gmail.com> 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
> Andrea, > also it may be OK your code resumes a standalone version specific for > IE, jQuery need a patch (addition) in the detection logic and having a > better fall back support for iframes.
> The collections of handlers are already handled for all browsers, not > just IE, in another piece of code in jQuery.ready(), and it seems > there are no problem in that part.
> One tip I want you to remember about your code above, the "init()" > should be called outside the try/catch block to avoid hiding useful > informations to developers.
> I believe this is applicable to Mootools too if you dare to convince > them about it... :-)
> -- > Diego Perini
> On 12 Lug, 14:39, "Andrea Giammarchi" <andrea.giammar...@gmail.com> > wrote: > > Ops, Sorry ... again .... Hi Diego :D
> > On Sat, Jul 12, 2008 at 1:38 PM, Andrea Giammarchi <
> > andrea.giammar...@gmail.com> wrote: > > > Hi Piero, as posted on the ticket too, what do you think about this > > > revision?
> > > Tested with IE 5.5, 6, 7, 8 beta, works with 5 if you want, using > concat > > > instead of splice.
> > > Supports multiple documents, multiple events, respects events queue, > and > > > using interval instead of timeout, could be a bit ( really a little bit > ) > > > faster thanks to its unpredictable execution ( as you know, timeout is > > > always the expected one, or more )
> > > Kind Regards
> > > On Sat, Jul 12, 2008 at 12:20 PM, Diego Perini <diego.per...@gmail.com
> > > wrote:
> > >> Brandon, > > >> I suspect something must be wrong with how this ticket (#2614) was > > >> submitted, or just missed it.
> > >> It seems to me nothing has changed for this from 1.2.2 to 1.2.6, could > > >> you please comment about it so I can adjust the patch just in case.
> > >> Both Prototype and Google already adopted the full IEContentLoaded > > >> method as described, it correct the firing order that is now wrong on > > >> IE.
> > >> This is admittedly hard to reproduce in general usage but is > > >> documented to break in different situations, probably also unrelated > > >> to assets as the title of the thread may state.
> > >> The small test case in this same thread is just an example showing the > > >> order in which load events fire is currently wrong.
> > >> Probably the most obvious side effect is that on Internet Explorer > > >> some code may execute in a different order than on the other browsers, > > >> producing inconsistent behaviors hard to track as a problem.
> > >> And as David noticed above, it could also be improved for iframes > > >> using the same "onreadystatechange" event, just another late fall > > >> back, but still keeping the order correct (an important part).... :-)
> > >> So...re-bumping...
> > >> -- > > >> Diego Perini
> > >> On 13 Mag, 17:40, Diego Perini <diego.per...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> 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...@gmail.com> wrote:
> > >> > > > > > Here is a small test that should output this sequence:
For those interested about my Diego alternative IE stand alone function, I was not able to obtain a better size: IEContentLoaded=function(E){function I(i){for(var j=0,l=E[i].f[L];j<l;j++)E[i].f[j]();E[i].f=[]};var L="length",D="document",i;return function(w,f){for(var e="onreadystatechange",d=w[D],j=0,l=E[L];j<l;j++)if(E[j].w===w)break;if(j== l){j=E.push({w:w,f:[f]})-1;d.attachEvent(e,function(){if(d.readyState=="com plete")I(d.detachEvent(e,arguments.callee)||j);})}else E[j].f.push(f);if(!i)i=setInterval(function(){for(var j=0,l=E[L],q=[];j<l;j++)try{E[j].w[D].documentElement.doScroll("left");q.pu sh(j)}catch(e){};for(j=0,l=q[L];j<l;j++)I(q[j]);for(j=0,l=E[L],q=[];j<l;j++ )if(!E[j].f[L])q.push(1);if(q[L]===l)clearInterval(i);},10);}}([]);
632 bytes, but with deflate, based on packed.it information, should be 366. Probably even less with gz
Regards
On Sat, Jul 12, 2008 at 3:21 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote: > For those interested about my Diego alternative IE stand alone function, I > was not able to obtain a better size: > IEContentLoaded=function(E){function I(i){for(var > j=0,l=E[i].f[L];j<l;j++)E[i].f[j]();E[i].f=[]};var > L="length",D="document",i;return function(w,f){for(var > e="onreadystatechange",d=w[D],j=0,l=E[L];j<l;j++)if(E[j].w===w)break;if(j== l){j=E.push({w:w,f:[f]})-1;d.attachEvent(e,function(){if(d.readyState=="com plete")I(d.detachEvent(e,arguments.callee)||j);})}else > E[j].f.push(f);if(!i)i=setInterval(function(){for(var > j=0,l=E[L],q=[];j<l;j++)try{E[j].w[D].documentElement.doScroll("left");q.pu sh(j)}catch(e){};for(j=0,l=q[L];j<l;j++)I(q[j]);for(j=0,l=E[L],q=[];j<l;j++ )if(!E[j].f[L])q.push(1);if(q[L]===l)clearInterval(i);},10);}}([]);
> 632 bytes, but with deflate, based on packed.it information, should be > 366. Probably even less with gz
> Regards
> On Sat, Jul 12, 2008 at 3:21 PM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote:
>> OMG!!! I need a red bull as well, coffee didn't work ... bloody hell, my >> brain is completely crap today!
|
