We have spent some time racking our heads why $(document).ready()
wasn't always firing and we finally found it.
The ready() function checks jQuery.isReady. If true, it fires straight
away, if false, it gets queued and fired once the document is ready.
This is fine if you have a page which registers a ready function on
the initial load of the page. At this point jQuery hooks itself up to
capture the documents ready event, fires your function and also sets
jQuery.isReady to true.
However, if you have a page with jQuery on it and don't register
anything on the first load, then jQuery.isReady is left to be false.
Then you load a script via ajax which calls $
(document).ready(functrion(){/*do stuff*/}) but it won't fire. Why?
because, the page is already loaded, so the document ready event
doesn't fire and hence doesn't set jQuery.isReady to true. Registering
a function at this point get's added to jQuery.readyList but it is
never run.
For now I have fixed this by appending this line to the end of the
jQuery file which registers a dummy function.
This function does nothing other than make sure jQuery hooked up the
ready event in the case that no ready function was externally queued
on jQuery.readyList on the initial page load. There may be a better
fix for this by a jQuery guru, buth this does the trick for now.
Ok, I understand what you're shooting for - could you file a bug? http://dev.jquery.com/
I'm a little bit confused, though. In which situation are you loading jQuery before the document is ready - NOT using a document ready handler on load - but using document ready handler at some later point?
On Thu, Mar 13, 2008 at 1:40 PM, Giulio <giulio.l.d...@gmail.com> wrote:
> Hi,
> We have spent some time racking our heads why $(document).ready() > wasn't always firing and we finally found it.
> The ready() function checks jQuery.isReady. If true, it fires straight > away, if false, it gets queued and fired once the document is ready.
> This is fine if you have a page which registers a ready function on > the initial load of the page. At this point jQuery hooks itself up to > capture the documents ready event, fires your function and also sets > jQuery.isReady to true.
> However, if you have a page with jQuery on it and don't register > anything on the first load, then jQuery.isReady is left to be false. > Then you load a script via ajax which calls $ > (document).ready(functrion(){/*do stuff*/}) but it won't fire. Why? > because, the page is already loaded, so the document ready event > doesn't fire and hence doesn't set jQuery.isReady to true. Registering > a function at this point get's added to jQuery.readyList but it is > never run.
> For now I have fixed this by appending this line to the end of the > jQuery file which registers a dummy function.
> This function does nothing other than make sure jQuery hooked up the > ready event in the case that no ready function was externally queued > on jQuery.readyList on the initial page load. There may be a better > fix for this by a jQuery guru, buth this does the trick for now.
John Resig wrote: > I'm a little bit confused, though. In which situation are you loading > jQuery before the document is ready - NOT using a document ready > handler on load - but using document ready handler at some later > point?
He has a race condition. I think he's loading a script via AJAX that may or may not be executed by the time the original page is ready. If this is the case, there's a simple solution:
The thing is that the bindReady function is lazy (if I'm not
mistaken), so it doesn't run until the first call to document.ready.
if your first call comes after the document is ready, it doesn't run.
Right ?
> John Resig wrote:
> > I'm a little bit confused, though. In which situation are you loading
> > jQuery before the document is ready - NOT using a document ready
> > handler on load - but using document ready handler at some later
> > point?
> He has a race condition. I think he's loading a script via AJAX that may
> or may not be executed by the time the original page is ready. If this
> is the case, there's a simple solution:
On Mar 13, 6:51 pm, "John Resig" <jere...@gmail.com> wrote:
> Ok, I understand what you're shooting for - could you file a bug?http://dev.jquery.com/
> I'm a little bit confused, though. In which situation are you loading
> jQuery before the document is ready - NOT using a document ready
> handler on load - but using document ready handler at some later
> point?
I ran into the same problem the other day but didn't fully understand
what was wrong until now.
We are using a bottom script approach without ever using the DOM ready
event. Some datepicker stuff is loaded via Ajax later on, but because
the UI datepicker uses the ready event at some point to add some
required elements it'll never get properly initialized. I filed a
separate ticket for this already.
There may be other plugins relying on the ready event as well. I think
if at all possible that should be avoided in plugins.
Klaus, using the datepicker is exactly how we found the bug. We have a
page which loads and doesn't register any $(document).ready()
functions. Then via ajax we load a calander if necessary but it wasn't
being initialised because of the reasons discussed above. I think it
is perfectly valid for any plugin / control developer to register a
ready function and expect it to fire no matter how it got there.
Giulio
On Mar 13, 11:39 pm, Klaus Hartl <klaus.ha...@googlemail.com> wrote:
> On Mar 13, 6:51 pm, "John Resig" <jere...@gmail.com> wrote:
> > Ok, I understand what you're shooting for - could you file a bug?http://dev.jquery.com/
> > I'm a little bit confused, though. In which situation are you loading
> > jQuery before the document is ready - NOT using a document ready
> > handler on load - but using document ready handler at some later
> > point?
> I ran into the same problem the other day but didn't fully understand
> what was wrong until now.
> We are using a bottom script approach without ever using the DOM ready
> event. Some datepicker stuff is loaded via Ajax later on, but because
> the UI datepicker uses the ready event at some point to add some
> required elements it'll never get properly initialized. I filed a
> separate ticket for this already.
> There may be other plugins relying on the ready event as well. I think
> if at all possible that should be avoided in plugins.
Giulio wrote: > is perfectly valid for any plugin / control developer to register a > ready function and expect it to fire no matter how it got there.
I think there are two ways to think about this:
1. If users consider ready() a replacement for window.onload (as the docs say), then jQuery isn't broken; after all, if you assign functions to window.onload after the event has occurred they'll never be called either!
2. With minor mods we could make ready() so that it's a reliable way to call a function as soon as possible. *Any* time you call it, that function is guaranteed to fire.
#1 appeals to the strictness nerd in me; the user should recognize that they're creating a race condition by calling code via AJAX and manually prepare for it.
But if the modification was small and wouldn't have a performance hit, I think #2 would make ready() more useful and eliminate hours of user frustration in cases like this.
Interesting because number 2 is technically already there and hence
assumed IF and only IF something first registers with the ready event.
jQuery checks for isReady and if it is it gets fired immediately. So,
why not always do this?
Froma control developers point of view they need something to happen
when the page is ready to (usually) initialise things. In the case of
a blank page with the control already there, you do want to wait for
the browser load event. If the control is loaded later, it still needs
to fire, so why have every control developer code the what if scenario
and not just have jQuery handle it? Especially considreing it was
coded to do it this way in the first place assuming something is
registered with ready.
On Mar 14, 3:31 pm, Steve Clay <st...@mrclay.org> wrote:
> Giulio wrote:
> > is perfectly valid for any plugin / control developer to register a
> > ready function and expect it to fire no matter how it got there.
> I think there are two ways to think about this:
> 1. If users consider ready() a replacement for window.onload (as the
> docs say), then jQuery isn't broken; after all, if you assign functions
> to window.onload after the event has occurred they'll never be called
> either!
> 2. With minor mods we could make ready() so that it's a reliable way to
> call a function as soon as possible. *Any* time you call it, that
> function is guaranteed to fire.
> #1 appeals to the strictness nerd in me; the user should recognize that
> they're creating a race condition by calling code via AJAX and manually
> prepare for it.
> But if the modification was small and wouldn't have a performance hit, I
> think #2 would make ready() more useful and eliminate hours of user
> frustration in cases like this.
Giulio,
effectively the "doScroll('left')" trick implemented in jQuery
provisions for that too...
Look at this for example, and use this meanwhile if it solves:
// use the name that best fits you
function isDOMReady() {
try {
document.documentElement.doScroll('left');
} catch (e) {
return false;
}
return true;
}
You are probably right in assuming that jQuery should, in any case,
write/save somewhere that the loading process was completed,
even if nobody asked for it.
Diego Perini
On 14 Mar, 17:37, Giulio <giulio.l.d...@gmail.com> wrote:
> Interesting because number 2 is technically already there and hence
> assumed IF and only IF something first registers with the ready event.
> jQuery checks for isReady and if it is it gets fired immediately. So,
> why not always do this?
> Froma control developers point of view they need something to happen
> when the page is ready to (usually) initialise things. In the case of
> a blank page with the control already there, you do want to wait for
> the browser load event. If the control is loaded later, it still needs
> to fire, so why have every control developer code the what if scenario
> and not just have jQuery handle it? Especially considreing it was
> coded to do it this way in the first place assuming something is
> registered with ready.
> On Mar 14, 3:31 pm, Steve Clay <st...@mrclay.org> wrote:
> > Giulio wrote:
> > > is perfectly valid for any plugin / control developer to register a
> > > ready function and expect it to fire no matter how it got there.
> > I think there are two ways to think about this:
> > 1. If users consider ready() a replacement for window.onload (as the
> > docs say), then jQuery isn't broken; after all, if you assign functions
> > to window.onload after the event has occurred they'll never be called
> > either!
> > 2. With minor mods we could make ready() so that it's a reliable way to
> > call a function as soon as possible. *Any* time you call it, that
> > function is guaranteed to fire.
> > #1 appeals to the strictness nerd in me; the user should recognize that
> > they're creating a race condition by calling code via AJAX and manually
> > prepare for it.
> > But if the modification was small and wouldn't have a performance hit, I
> > think #2 would make ready() more useful and eliminate hours of user
> > frustration in cases like this.
> Giulio,
> effectively the "doScroll('left')" trick implemented in jQuery
> provisions for that too...
> Look at this for example, and use this meanwhile if it solves:
> // use the name that best fits you
> function isDOMReady() {
> try {
> document.documentElement.doScroll('left');
> } catch (e) {
> return false;
> }
> return true;
> }
> You are probably right in assuming that jQuery should, in any case,
> write/save somewhere that the loading process was completed,
> even if nobody asked for it.
> Diego Perini
> On 14 Mar, 17:37, Giulio <giulio.l.d...@gmail.com> wrote:
> > Interesting because number 2 is technically already there and hence
> > assumed IF and only IF something first registers with the ready event.
> > jQuery checks for isReady and if it is it gets fired immediately. So,
> > why not always do this?
> > Froma control developers point of view they need something to happen
> > when the page is ready to (usually) initialise things. In the case of
> > a blank page with the control already there, you do want to wait for
> > the browser load event. If the control is loaded later, it still needs
> > to fire, so why have every control developer code the what if scenario
> > and not just have jQuery handle it? Especially considreing it was
> > coded to do it this way in the first place assuming something is
> > registered with ready.
> > On Mar 14, 3:31 pm, Steve Clay <st...@mrclay.org> wrote:
> > > Giulio wrote:
> > > > is perfectly valid for any plugin / control developer to register a
> > > > ready function and expect it to fire no matter how it got there.
> > > I think there are two ways to think about this:
> > > 1. If users consider ready() a replacement for window.onload (as the
> > > docs say), then jQuery isn't broken; after all, if you assign functions
> > > to window.onload after the event has occurred they'll never be called
> > > either!
> > > 2. With minor mods we could make ready() so that it's a reliable way to
> > > call a function as soon as possible. *Any* time you call it, that
> > > function is guaranteed to fire.
> > > #1 appeals to the strictness nerd in me; the user should recognize that
> > > they're creating a race condition by calling code via AJAX and manually
> > > prepare for it.
> > > But if the modification was small and wouldn't have a performance hit, I
> > > think #2 would make ready() more useful and eliminate hours of user
> > > frustration in cases like this.
|
