#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: | [email protected]… |
Blocked by: | Blocking: |
Description
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 14 years ago by
comment:2 Changed 14 years ago by
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:
- Assigning a value to an existing variable overwrites the previous value.
- CSS values later in a CSS document overwrite the preceding values.
Luke Brookhart
comment:3 Changed 14 years ago by
Component: | core → event |
---|---|
need: | Patch → Test Case |
Owner: | set to brandon |
Priority: | major → minor |
Type: | bug → enhancement |
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 12 years ago by
Status: | new → pending |
---|
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 12 years ago by
Status: | pending → closed |
---|
Automatically closed due to 14 days of inactivity.
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.