Bug Tracker

Opened 6 years ago

Closed 6 years ago

#13864 closed feature (plugin)

Add onlyHandlers argument to trigger()

Reported by: adrian@… Owned by:
Priority: low Milestone: None
Component: event Version: 1.9.1
Keywords: Cc:
Blocked by: Blocking:


Currently there are trigger and triggerHandler. However, the latter only works on the first element contained in the jQuery object so there is no way at all (besides calling $.event.trigger manually) to trigger bound events on a bunch of objects without executing the browser's default action.

For this reason I'm suggesting to add another argument to trigger:

	trigger: function( type, data, onlyHandlers ) {
		return this.each(function() {
			jQuery.event.trigger( type, data, this, onlyHandlers );

It would not break backwards compatibility and I can't imagine any other disadvantages in having that argument.

Change History (7)

comment:1 Changed 6 years ago by scottgonzalez

...there is no way at all (besides calling $.event.trigger manually) to trigger bound events on a bunch of objects without executing the browser's default action.

There are actually multiple ways to do so, with public APIs. You can use .triggerHandler() inside .each() or you could create an event object using $.Event, call preventDefault() (and stopPropagation()), then pass that event object to .trigger().

comment:2 Changed 6 years ago by adrian@…

True, but I'm sure you agree that neither of them are as nice as having an argument for this. A good example where the argument would be useful is a script for a "check all" button:

$('.checkboxes').prop('checked', true).trigger('click', null, true);

Sure, using the click event instead of change there is stupid but legacy code is widespread so being able to trigger events on all matched objects without the default executing would be useful. And using .each for such a simple one-liner (which is even still very readable) would not make the code cleaner, more beautiful or more readable.

comment:3 Changed 6 years ago by scottgonzalez

I don't view .trigger('click', null, true); as beautiful or more readable. It's not at all clear what that does when looking at it. You need intimate knowledge of the API to be able to read that code.

comment:4 Changed 6 years ago by anonymous

Could also be a separate function - triggerHandlers maybe. But that could be confused with triggerHandler. Anyway, the name would make the difference pretty clear IMHO.

comment:5 Changed 6 years ago by timmywil

Component: unfiledevent
Priority: undecidedlow
Status: newopen

I agree there is a small hole in the API here (we've had other complaints as well), but I'm not sure the solution. There should be a simpler way to trigger all handlers in a collection without triggering default actions. Creating an event object with the default already prevented is probably the best idea so far, but not quite the same thing (see http://bugs.jquery.com/ticket/10794). And I think we can do better than recommend re-wrapping each element with jQuery to call triggerHandler.

comment:6 Changed 6 years ago by dmethvin

The OP says there is "no way at all (besides calling $.event.trigger manually) to trigger bound events on a bunch of objects without executing the browser's default action." As Scott points out that's not true. It's pretty simple to create a "plugin" to do this using .triggerHandler(), and the extra overhead isn't much compared to the cost of firing events.

$.fn.triggerHandlers = function( event, data ) {
   return this.each(function() {
      $( this ).triggerHandler( event, data );

What exactly is the use case? Does that plugin help? Given that we have rarely had anyone express the need for it over the years, is there a compelling reason to put it in core?

Note that the .triggerHandler() method returns the return value of the event handler so if you need that (or for example wanted to honor stopPropagation across the elements in the collection, which is non-standard behavior) you'd want a different implementation. These situations may be relatively specialized so I'm not sure it helps for us to assume our second try will cover all needs either.

Last edited 6 years ago by dmethvin (previous) (diff)

comment:7 Changed 6 years ago by dmethvin

Resolution: plugin
Status: openclosed

Since nobody else has expressed an interest in this, I'll close the ticket with the recommendation that it be implemented as a plugin. Adding a boolean argument to an API signature isn't generally a good idea anyway.

Note: See TracTickets for help on using tickets.