Skip to main content

Bug Tracker

Side navigation

#10588 closed bug (fixed)

Opened October 26, 2011 06:49PM UTC

Closed October 26, 2011 09:05PM UTC

Last modified November 01, 2011 10:31AM UTC

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:
Description

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!

Attachments (0)
Change History (7)

Changed October 26, 2011 06:53PM UTC by rwaldron comment:1

component: unfiledcore
priority: undecidedlow
resolution: → invalid
status: newclosed

Changed October 26, 2011 08:51PM UTC by ajpiano comment:2

resolution: invalid
status: closedreopened

Changed October 26, 2011 08:52PM UTC by ajpiano comment:3

owner: → dmethvin
status: reopenedassigned

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

Changed October 26, 2011 08:55PM UTC by dmethvin comment:4

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.

Changed October 26, 2011 09:02PM UTC by gnarf comment:5

TODO converted into ticket #10589

Changed October 26, 2011 09:05PM UTC by Dave Methvin comment:6

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

Changed November 01, 2011 10:31AM UTC by uffefl@gmail.com comment:7

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.