Skip to main content

Bug Tracker

Side navigation

#11945 closed feature (wontfix)

Opened June 21, 2012 10:10AM UTC

Closed October 29, 2012 05:07PM UTC

Last modified November 27, 2012 05:43PM UTC

Event: hasEvent() and so on.

Reported by: damien Owned by: damien
Priority: low Milestone: None
Component: event Version: git
Keywords: 1.9-discuss Cc:
Blocked by: Blocking:
Description

I propose to have an interface for the undocumented .data('events') storage.

E.g.

@return {Boolean}

$elem.hasEvent('click');

@return {Boolean}

$elem.hasEvent(funcHandler);

// @return {Object} all bound events related to the parameter (undefined returns all bound events)

$elem.getEvent(undefined|String|Function);

I think a public API like that is necessary since .data('events') is not officially exposed by the docs. Furthermore these functions could be a loosely depending component to remove it within a custom build.

Attachments (0)
Change History (14)

Changed June 21, 2012 01:22PM UTC by dmethvin comment:1

owner: → damien
status: newpending

Do you have some intended use cases? How would you account for delegated events?

Changed June 21, 2012 02:02PM UTC by rwaldron comment:2

Weren't we going to provide a plugin in for this?

Changed June 21, 2012 02:05PM UTC by damien comment:3

status: pendingnew

e.g. to avoid double binding it would be possible to check if the event already has the same event bound. Or to receive all available events (which already have handlers) for a specific dom element.

Delegated events are an issue and I have no useful answer (yet) how to solve that :)

A plugin or an optional component for that would be fine.

Changed June 21, 2012 07:27PM UTC by dmethvin comment:4

status: newpending

@rwaldron yep, there was some discussion about doing that but .data("events") was undocumented so it's basically creating new functionality. I'm not convinced .hasEvents is the right solution. The other use people mentioned was debugging; that is still doable but not a supported part of the API.

Is avoiding doubled event handlers the only use case? If so it might be better to have a feature like .on("click.mybutton!", fn) with the ! saying you don't want to attach a second handler if there is already a click event with namespace mybutton.

In a large page it's really important to consider that code other than yours may need to attach events so non-namespaced events are a bad idea in general.

I'm still not clear on the scenario where you lose track of the fact that an event handler was already attached. You could always add a class name to indicate the fact, which would also allow you to select the elements that didn't already have that class to attach the event. That seems likely to be faster than either of the two proposed features.

Changed June 21, 2012 10:24PM UTC by damien comment:5

status: pendingnew

I needed that for my toe.js library where I checked if another event of a different type was bound to the given element before firing another event delayed. https://github.com/dantipa/toe.js/blob/master/src/gestures/tap.js#L40

However my major concern is that I'm worrying about the reliability of data('events') since it is undocumented and therefor not a public API. So I think a method to access (at least all) bound events is necessary. Even if jQuery doesn't provide any further processing.

Changed June 23, 2012 01:23PM UTC by dmethvin comment:6

_comment0: It doesn't look like the code is using the jQuery special events system, that might make it easier. For example, when a `doubletap` was attached you could set a data item on the element to indicate it was there. \ \ For this particular use case ("Is some other event attached? If so I'll change the behavior of this event") the only-attach-one shorthand I mentioned above isn't useful. I'll mark this ticket open for discussion in 1.9 but it would be handy to have other examples. \ \ > I think a method to access (at least all) bound events is necessary. \ \ I thought what was being proposed here I thought simple Boolean-returning method that said whether the element had a particular event (or event.namespace) attached. Something like `jQuery.event.has(elem, "click")`. \ \ 1340457829378803
component: unfiledevent
keywords: → 1.9-discuss
milestone: None1.9
priority: undecidedlow
status: newopen

It doesn't look like the code is using the jQuery special events system, that might make it easier. For example, when a doubletap was attached you could set a data item on the element to indicate it was there.

For this particular use case ("Is some other event attached? If so I'll change the behavior of this event") the only-attach-one shorthand I mentioned above isn't useful. I'll mark this ticket open for discussion in 1.9 but it would be handy to have other examples.

I think a method to access (at least all) bound events is necessary.

I thought what was being proposed here was a simple Boolean-returning method that said whether the element had a particular event (or event.namespace) attached. Something like jQuery.event.has(elem, "click").

Changed September 27, 2012 01:41PM UTC by gibson042 comment:7

-1 unless we get a clear use case, and even then we should keep it simple. Not having much insight into event listeners is a failing of both W3C DOM and jQuery, but an API we later regret would be worse.

Changed October 14, 2012 10:30PM UTC by mikesherov comment:8

-1

Changed October 14, 2012 11:29PM UTC by rwaldron comment:9

-1, Maybe an events() (as a alias for data("events")?)

Changed October 22, 2012 05:20PM UTC by gibson042 comment:10

-1

Changed October 22, 2012 05:31PM UTC by gnarf comment:11

-1, We should expose some way to peek at events, but this doesn't seem that useful.

Changed October 29, 2012 05:07PM UTC by mikesherov comment:12

resolution: → wontfix
status: openclosed

Changed November 06, 2012 01:03AM UTC by david71rj comment:13

+1 to @rwaldron idea.

I needed that one time, copy a node event to another node. So I have a use case for that. In IE we can't change attr[type] from input or button, so jQuery doesn't allow that in all browsers (http://jsfiddle.net/Aub7E/2/) but Chrome, for instance, allow that normally (http://jsfiddle.net/rgyB7/).

My solution is clone input node, but set the new type attribute and re-apply all events from original (and attrs). Currently it doesn't is possible, but can be easily implemented - and it solve the type change bug to IE.

Futhermore, I think that IE6 don't need too focus. But browsers that support can't do that because of IE6.

Changed November 27, 2012 05:43PM UTC by dmethvin comment:14

milestone: 1.9None

Just to clarify why .events() isn't the answer, the entire data structure retrieved here is undocumented. If we provide a formal documented way to get it we'd need to document the data structure. Given that we may have the opportunity to make changes in 2.0 I don't think now is the best time to do that.