Methods on custom objects are being called when an event with the same name is triggered on it

[timmolendijk]

I don't understand why this happens:

var customObject = { hello: function() { alert("Hello!"); } };
$(customObject).trigger('hello');  // An alert will pop up!
$(customObject).triggerHandler('hello');  // No alert will pop up.

Why is customObject.hello being called when an hello event is triggered on customObject? I wasn't expecting it and I cannot find any hint towards it in the docs. My guess is that it's an unintended side-effect of the new (explicit) support for using jQuery.fn.trigger on custom objects. Am I right?

[dmethvin]

It's meant to handle the situation where an event named X is triggered on a DOM element and there's a corresponding X method on the element. Events like change, focus, and blur for example.

So yes, in those cases it will call the correspondingly named function on the plain object if it exists. Actually it will try to call the property regardless of whether it's a function or not, because it's impossible to tell with IE.

Sounds like we should put a check into jQuery.event.trigger to see if the element is a DOM element, before someone decides this is a feature.

[jitter]

I already assessed this one yesterday but didn't come around to add my findings. Sorry Dave. I basically figured out the same thing as you (code branch in trigger() is only meant for DOM element nodes to use the browsers native event method if applicable)

This also is straightforward to fix imo. It should be fine to just change ​this line to

!isClick && target && jQuery.acceptData( target ) ) {

This is better readable, uses acceptData instead of repeating the very same thing in the conditional. It also has the nice side effect of fixing a potential other bug: that this branch gets run even when target is e.g. undefined.

So when you tackle this I guess you could do some refactoring and save us a few bytes, as there are at least two other places where a similar pattern (along elem && elem.nodeName && jQuery.noData[elem.nodeName.toLowerCase()]) is used. These can probably be switched to use acceptData() too. Maybe we even can incorporate the check if elem is defined/undefined into acceptData() too?

Replying to dmethvin:

Sounds like we should put a check into jQuery.event.trigger to see if the element is a DOM element, before someone decides this is a feature.

This "faulty" undocumented behavior is in jQuery since 1.1 (!!!!) as you can see with this ​live test case. So by now there surely are some people relying on this hidden "gem" but this should get fixed anyway.

[scottgonzalez]

Whether or not this is changed should be defined by #7818.

[Rick Waldron]

#9146 is a duplicate of this ticket.

[Rick Waldron]

#7930 is a duplicate of this ticket.

[dmethvin]

This behavior has been institutionalized and will be documented; see #7818 for the draft documentation about what is valid to call on a jQuery-wrapped plain object. Per the fix for #6170 this behavior is not allowed for window objects to avoid calling globals.

[Rick Waldron]

#10747 is a duplicate of this ticket.

[dmethvin]

#10837 is a duplicate of this ticket.