Allow setting of custom mouse event options

[IgorNadj]

Now you can call e.g.
$('button').simulate('click', {myCustomOption: 5}) ;
and the event object will have the myCustomOption attribute set.

Notes:
I have not updated tests for this. This only affects mouse clicks.

[jquerybot]

Thank you for your pull request. It looks like this may be your first contribution to a jQuery Foundation project, if so we need you to sign our Contributor License Agreement (CLA).

📝 Please visit http://contribute.jquery.org/CLA/ to sign.

After you signed, the PR is checked again automatically after a minute. If there's still an issue, please reply here to let us know.

---

If you've already signed our CLA, it's possible your git author information doesn't match your CLA signature (both your name and email have to match), for more information, check the status of your CLA check.

[dmethvin]

@IgorNadj I'm interested in how you might use this. For simulating browser-generated events, it is not possible to override any standards-defined property in the event object; depending on the browser, you'll either get an error message or it will be silently ignored. If you're using DOM events for some sort of general event-based signalling or pub/sub mechanism, it's better to do that outside the DOM event system which has a bunch of complex semantics that may not do what you want.

[IgorNadj]

@dmethvin we are using this library to delay a click.

A user clicks a link, we capture it and call preventDefault on the event, do our custom logic, then we simulate a click event on the same element.

To prevent capturing this new event, we have to flag it. We flag it by setting a custom attribute, e.g. isSimulated=true.

[dmethvin]

jQuery core probably set a bad example here by adding properties to its own jQuery.Event object. To some extent we had to do that so that we could deliver a normalized event object. With version 4.0 I've been experimenting with an attempt to avoid the overhead of copying or shadowing event properties and passing the native Event object directly to user event handlers. With that in mind I think it's better to treat the event object you get as read-only.

It seems like there are other solutions you could use here, for example use an event namespace or a different event name.