perf(jqLite): Add passive event listeners

[alejandroSuch]

perf(jqLite): Add passive event listeners

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Changes in sqLite to add passive event listeners

What is the current behavior? (You can also link to an open issue here)
Chrome warns with lots of messages telling us to add passive event listeners

What is the new behavior (if this is a feature change)?
Warnings disappear and there are less page blockings

Does this PR introduce a breaking change?
No

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
• [] Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Other information:

[dcherman]

From the MDN:

passive: A Boolean indicating that the listener will never call preventDefault(). If it does, the user agent should ignore it and generate a console warning. See Improving scrolling performance with passive listeners to learn more.

You can't guarantee this for any listeners other than your own, so this would be a massive, gigantic breaking change to .on

[gkalpak]

Idea: Make the default (passive or not) configurable and allow overwriting the default per case (e.g. ng-click="..." ng-click-passive="true/false").
This definitely needs more thought and discussion.

[dcherman]

You wouldn't be able to do that without a corresponding change in jQuery though unless you're willing to diverge from their API.

Also FWIW, I think it would be valid to allow this option to be usable with the ng- event handlers, but it would be a nightmare for plugin authors if you couldn't guarantee how your handlers will behave. Would rather see this be an opt-in behavior rather than potentially an opt-out.

[gkalpak]

Oh, you are right. I thought this was only about the ng-<event> directives, not jqLite's .on(). So, yeah, we have no intention of deviating from the jQuery API (unless there is a significant reason), because the idea of jqLite is to remain as compatible as possible with jQuery.

Closing as won't fix. We can re-consider if/when jQuery makes a similar change.