Side navigation
#12807 closed bug (notabug)
Opened October 29, 2012 07:52PM UTC
Closed October 30, 2012 10:49PM UTC
Last modified November 05, 2012 11:34AM UTC
Strange (maybe wrong) behaviour of jQuery.fn.ready function
| Reported by: | gu_ludo | Owned by: | |
|---|---|---|---|
| Priority: | undecided | Milestone: | None |
| Component: | unfiled | Version: | 1.8.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Hello, I think jQuery has a strange, also wrong, behaviour in jQuery.fn.ready function.
<!DOCTYPE html>
<html>
<head>
<title>Teste jQuery.fn.ready</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<script type="text/javascript" src="http://code.jquery.com/jquery-1.8.2.min.js"></script>
<script type="text/javascript">
$(document).ready(function(){
alert('first alert');
$(document).ready(function(){
alert('second alert');
});
}).ready(function(){
alert('third alert');
});
</script>
<body>
</body>
</html>
Well, since $.fn.ready callbacks get triggered when the document is ready, I think the output's order should be as follows:
"first alert"
"second alert"
"third alert"
The reason is that "second alert"'s function is registered when the DOM is already ready, which means that it wouldn't need to be queued, but evaluated.
I'm a Brazilian guy, so I want to apologize myself for something wrong with my English.
Attachments (0)
Change History (7)
Changed October 30, 2012 10:49PM UTC by comment:1
| resolution: | → notabug |
|---|---|
| status: | new → closed |
Changed October 31, 2012 05:49PM UTC by comment:2
Well, I still think the order of execution should be taken in account. However my point is: The "first alert"'s callback is being performed, and that means the document is already ready. Thus the "second alert" must be performed right after the "first alert".
The following was extracted from http://api.jquery.com/ready/
"If .ready() is called after the DOM has been initialized, the new handler passed in will be executed immediately."
Changed October 31, 2012 05:50PM UTC by comment:3
Replying to [comment:1 dmethvin]:
If the DOM is ready, you should expect the code to run. Do not depend on the order of execution.
Well, I still think the order of execution should be taken in account. However my point is: The "first alert"'s callback is being performed, and that means the document is already ready. Thus the "second alert" must be performed right after the "first alert".
The following was extracted from http://api.jquery.com/ready/ "If .ready() is called after the DOM has been initialized, the new handler passed in will be executed immediately."
Changed October 31, 2012 11:52PM UTC by comment:4
| _comment0: | Ready handlers are executed in the order they were added. That's a property of our Deferred implementation. You *can* rely on the order of execution of the callbacks, it's just not the order you were expecting. The documentation is probably not clear enough here. → 1351727600137830 |
|---|
Ready handlers are executed in the order they were added. That's a property of our Deferred implementation. You *can* rely on the order of execution of the callbacks, it's just not the order you were expecting. The documentation is probably not clear enough here. (jaubourg speaking)
Changed November 04, 2012 05:56PM UTC by comment:5
Replying to [comment:4 anonymous]:
Ready handlers are executed in the order they were added. That's a property of our Deferred implementation. You *can* rely on the order of execution of the callbacks, it's just not the order you were expecting. The documentation is probably not clear enough here. (jaubourg speaking)
I know I can rely on it. But, in this case, according to the documentation, which was so clear for me on this point, the "second alert"'s callback should be performed when it was registered, because the DOM is already initialized.
What I mean is: '''The order of execution is right, but jQuery is queuing something when it shouldn't'''.
Changed November 04, 2012 06:36PM UTC by comment:6
I know I can rely on it. But, in this case, according to the documentation, which was so clear for me on this point, the "second alert"'s callback should be performed when it was registered, because the DOM is already initialized. What I mean is: '''The order of execution is right, but jQuery is queuing something when it shouldn't.
No, the order of execution is right because''' jQuery is queueing. ''Ready handlers are executed in the order they were added''. The handler alerting "second alert" is added last (third) and is executed last. It's simply impossible to ensure the behaviour without queueing because you need to let the second handler execute before you execute the third one.
Please note that this is all done synchronously. So the handler is effectively called "immediately" (no asynchronous delay), just after all other currently bound handlers so that order of execution is consistent.
Then again, ''it's just not the order you were expecting'' but it is expected behaviour.
The documentation is just not clear enough.
Changed November 05, 2012 11:34AM UTC by comment:7
Replying to [comment:6 jaubourg]:
> I know I can rely on it. But, in this case, according to the documentation, which was so clear for me on this point, the "second alert"'s callback should be performed when it was registered, because the DOM is already initialized. > > What I mean is: '''The order of execution is right, but jQuery is queuing something when it shouldn't. No, the order of execution is right because''' jQuery is queueing. ''Ready handlers are executed in the order they were added''. The handler alerting "second alert" is added last (third) and is executed last. It's simply impossible to ensure the behaviour without queueing because you need to let the second handler execute before you execute the third one. Please note that this is all done synchronously. So the handler is effectively called "immediately" (no asynchronous delay), just after all other currently bound handlers so that order of execution is consistent. Then again, ''it's just not the order you were expecting'' but it is expected behaviour. The documentation is just not clear enough.
Well, I got your point. Here in Brazil we are used to say "for each case, one case", which means that each situation is different from another.
I think this current behaviour is useful for several situations. But sometimes the other is needed, for example, for me. In my case, I needed the callback to be performed immediately (without queueing), and my code didn't know that it was already in a "ready block".
So, we could think of allowing the developer to configure this behaviour, that is, immediate calls with or without queueing.
Best regards!
If the DOM is ready, you should expect the code to run. Do not depend on the order of execution.