Bug Tracker

Opened 12 years ago

Closed 10 years ago

Last modified 8 years ago

#3781 closed enhancement

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: jeresig@…
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

Change History (7)

comment:1 Changed 12 years ago by dmethvin

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.

comment:2 Changed 12 years ago by lukebrookhart

Dave, 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

comment:3 Changed 11 years ago by brandon

Component: coreevent
need: PatchTest Case
Owner: set to 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.

comment:4 Changed 10 years ago by snover

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!

comment:5 Changed 10 years ago by trac-o-bot

Status: pendingclosed

Automatically closed due to 14 days of inactivity.

comment:14 Changed 10 years ago by dmethvin

#7548 is a duplicate of this ticket.

comment:15 Changed 9 years ago by Rick Waldron

#8748 is a duplicate of this ticket.

Note: See TracTickets for help on using tickets.