Bug Tracker

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#10588 closed bug (fixed)

TODO for 1.6 in source code

Reported by: anonymous Owned by: dmethvin
Priority: low Milestone: None
Component: core Version: 1.7b2
Keywords: Cc:
Blocked by: Blocking:


Extrated from the 1.7rc1 source:

TODO: This is a hack for 1.5 ONLY. It will be removed in 1.6. Users should not attempt to inspect the internal events object using jQuery.data, as this internal data object is undocumented and subject to change. if ( name === "events" && !thisCache[name] ) {

return thisCache[ internalKey ] && thisCache[ internalKey ].events;


We're moving onto 1.7, so this should be fixed by now!

Change History (7)

comment:1 Changed 11 years ago by Rick Waldron

Component: unfiledcore
Priority: undecidedlow
Resolution: invalid
Status: newclosed

comment:2 Changed 11 years ago by ajpiano

Resolution: invalid
Status: closedreopened

comment:3 Changed 11 years ago by ajpiano

Owner: set to dmethvin
Status: reopenedassigned

The comment needs to be removed or revised so that it is not woefully inaccurate and anachronistic.

comment:4 Changed 11 years ago by dmethvin

Although the part about users inspecting event data is still true. Event-data-spying lurkers beware, you are still on death row, but the governor called and said you can have another day.

comment:5 Changed 11 years ago by gnarf

TODO converted into ticket #10589

comment:6 Changed 11 years ago by Dave Methvin

Resolution: fixed
Status: assignedclosed

Fix #10588. For now, event voyeurism only merits the look of disapproval.

If you are using .data("events") we would like to know how we can provide a documented interface that satisfies the need.

Changeset: 24e416dca36df4b182a612dba37f8b6cdaa25916

comment:7 Changed 11 years ago by [email protected]

It seems to me the most common use case of inspecting the events object (apart from debugging perhaps) is the wish to reorder event execution order.

I wanted to do this for my current project, but got discouraged by the internalness of the component so in the end I wound up simply hardcoding my specific dependencies.

Somehow being able to either prioritize by number or bucket the sequence of events when you bind them would be very nice. Ideally I'd like to .bind("click", function()..., -1) to bind a handler that always got executed before other handlers or .bind("click", function()..., 1) for a handler that got executed after all other handlers. Naturally if the same priority number was used there'd be no guarantee for sequencing.

However the number of use cases are probably fairly low, so I can fully understand if you don't want to clutter the interface by supporting this.

Note: See TracTickets for help on using tickets.