Upon further review, it seems the bug affects only the 'click' event and applies only to checkbox input elements, so it's most likely related to the changes in

http://jquery.com/upgrade-guide/1.9/#checkbox-radio-state-in-a-trigger-ed-click-event

Excellent diagnosis! Yes, so it seems like if we want to fix this you can get your data but will have to live with the fact that the checkbox state would not be correct. Choose your poison.

I should point out that if you just wanted to call your click handler(s) and pass the data but not have it call the DOM .click() method you could use .triggerHandler("click", data) as a workaround.

This is actually fixable, but at a whopping +124 bytes by my count. I'll leave the diff here for posterity (or possible pluginization), but note that it relies on undocumented functionality.

jquery:d79bf351...gibson042:13353

Not by a long shot do I see us landing this, though.

Replying to [comment:4 gibson042]:

This is actually fixable, but at a whopping +124 bytes by my count. I'll leave the diff here for posterity (or possible pluginization), but note that it relies on undocumented functionality. jquery:d79bf351...gibson042:13353 Not by a long shot do I see us landing this, though.

I don't understand if you're being sarcastic or not (guessing not). What does the "patch welcome" status mean? Will it be fixed in the coming jquery update or do I have to modify my code to live with it? Thanks

My apologies. We value a small library, and in some cases balance that desire against failing on things like invalid inputs and edge cases. In this instance, the presence of a .triggerHandler workaround, the issues with our old implementation presenting the wrong checked state, and the massive size cost of the best identified fix combine to support a decision for excluding it. I marked it patchwelcome because we ''would'' land a small enough fix if one were discovered.

In the meantime, you can either use a workaround or (if you are willing to accept the size increase) import the code from my repository.

Replying to [comment:6 gibson042]:

My apologies. We value a small library, and in some cases balance that desire against failing on things like invalid inputs and edge cases. In this instance, the presence of a .triggerHandler workaround, the issues with our old implementation presenting the wrong checked state, and the massive size cost of the best identified fix combine to support a decision for excluding it. I marked it patchwelcome because we ''would'' land a small enough fix if one were discovered. In the meantime, you can either use a workaround or (if you are willing to accept the size increase) import the code from my repository.

Thanks a lot for the explanation. I'm surprised there would be bugs left-over just for the sake of reducing the library size, hopefully the docs will be updated to reflect the issue in case the problem is never fixed.

I'm surprised there would be bugs left-over just for the sake of reducing the library size

Adding more code is a sure-fire way to add more bugs.

(In #13428) This is exactly analogous to #13353... I'm starting to think we should generalize and incorporate that solution after all.

Ref #13353, gh-1183: Capture onlyHandlers in jQuery.Event.isTrigger.

Changeset: 3f05afbd8d9bbc75d30b68e720324d1ed984a315

The solution should be more generic, since it's not only click event, but also focus, blur, etc..

#13769 is a duplicate of this ticket.