Skip to main content

Bug Tracker

Side navigation

#3781 closed enhancement ()

Opened January 05, 2009 12:07AM UTC

Closed November 11, 2010 11:09PM UTC

Last modified March 14, 2012 12:36PM UTC

bound events execution order

Reported by: lukebrookhart Owned by: brandon
Priority: minor Milestone: 1.3
Component: event Version: 1.2.6
Keywords: bind execution order Cc:
Blocked by: Blocking:

I was talking to John Resig about how bound events are ordered. He explained that they are executed in the order that they are added.

There should be method to assign the order when you're binding to an event

Here's an example:

I want to bind $('#please_wait').show() to the window unload event. Since there are other scripts already bound to the unload event, the Please Wait object is not shown until these are finished, which is not the desired effect.

Luke Brookhart

Attachments (0)
Change History (7)

Changed January 08, 2009 04:56AM UTC by dmethvin comment:1

Both IE's attachEvent and the W3C addEventListener say delivery order is not guaranteed (although jQuery doesn't generally use either). If events are being dynamically added and removed on DOM objects by multiple plugins, it would seem practically impossible for any particular event handler to know where it stood even if jQuery did guarantee FIFO.

For example, a plugin might add an event to the "front" of the window.unload list but what is to stop another plugin from out-fronting that one? Any assumption that it made about being first would be wrong at that point.

Changed January 08, 2009 05:17AM UTC by lukebrookhart comment:2


I understand what you're saying, but I'm not talking about just a plugin. An inline script should be able to add an event to the front of the window.unload event. This is like unshifting an array.

I do understand that future additions added to the front of the event could also supersede (or out-front) the previous one. But isn't this how most programming logic works?


1. Assigning a value to an existing variable overwrites the previous value.

2. CSS values later in a CSS document overwrite the preceding values.

Luke Brookhart

Changed January 20, 2009 03:44AM UTC by brandon comment:3

component: coreevent
need: PatchTest Case
owner: → brandon
priority: majorminor
type: bugenhancement

Adjusting event order might sound like a good idea at first but I believe it could cause some pretty unpredictable and unmaintainable results.

The problem with your examples, lukebrokhart, is that you are talking about values being overwritten. If an event took the first place it would not overwrite the previous event handler and that previous event handler was expecting to be first.

Having event order control adds complication and overhead to the core as well as to the event handler itself. Will the event handler then have to know what position it actually received even though it requested a different position?

I believe this is best solved by maintaing your own queue of event handlers to be run by a "master" event handler. This way it does not interfere with other event handlers. This could even be made into a plugin without much fuss.

Changed October 14, 2010 03:14AM UTC by snover comment:4

status: newpending

This ticket has been marked as missing a test case. In an effort to reduce the number of outstanding tickets in the bug tracker, it will be closed automatically in 30 days. In order to prevent this from happening, please provide a working test case. If a test case has already been provided and our records are wrong, please respond to the ticket so that it can be fixed. Thank you!

Changed November 11, 2010 11:09PM UTC by trac-o-bot comment:5

status: pendingclosed

Automatically closed due to 14 days of inactivity.

Changed November 18, 2010 02:30AM UTC by dmethvin comment:6

#7548 is a duplicate of this ticket.

Changed April 02, 2011 04:16PM UTC by rwaldron comment:7

#8748 is a duplicate of this ticket.