...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().

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.

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.

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.

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.

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.

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.