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.

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?

Examples:

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

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.

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!

Automatically closed due to 14 days of inactivity.

#7548 is a duplicate of this ticket.

#8748 is a duplicate of this ticket.