Bug Tracker

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#12807 closed bug (notabug)

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.

Change History (7)

comment:1 Changed 7 years ago by dmethvin

Resolution: notabug
Status: newclosed

If the DOM is ready, you should expect the code to run. Do not depend on the order of execution.

comment:2 Changed 7 years ago by gu_ludo

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."

comment:3 in reply to:  1 Changed 7 years ago by gu_udo

Replying to 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."

comment:4 Changed 7 years ago by 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)

Last edited 7 years ago by jaubourg (previous) (diff)

comment:5 in reply to:  4 ; Changed 7 years ago by gu_ludo

Replying to 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.

comment:6 in reply to:  5 ; Changed 7 years ago by 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.

comment:7 in reply to:  6 Changed 7 years ago by gu_ludo

Replying to 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!

Note: See TracTickets for help on using tickets.