Ember.js: Passive Listener Violation In Chrome

[stefanpenner]

[Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive.

Our event dispatcher always attaches this events, regardless if they are used or not: https://github.com/emberjs/ember.js/blob/master/packages/ember-views/lib/system/event_dispatcher.js#L62-L65

We should most likely lazily install them as they are required.

[evanaj]

I faced the same issue. How can I solve it?

[wellington1993]

I have the same problem:

[Violation] Added non-passive event listener to a scroll-blocking 'mousewheel' event. Consider marking event handler as 'passive' to make the page more responsive.
16:29:39.142

[wellington1993]

Is it a related question: https://github.com/emberjs/ember.js/issues/12783 ???

[krisselden]

@wellington1993 you can remove events via https://emberjs.com/api/classes/Ember.Application.html#property_customEvents and if your app needs these events use passive listeners for mousewheel, touchstart, touchmove (only events that can block scroll via preventDefault matter for passive listening), you add on didInsertElement and remove on willDestroyElement of a component.

[pixelhandler]

@evanaj @krisselden @stefanpenner @wellington1993 is this still an issue, perhaps we should close; what do you think?

[btecu]

@pixelhandler this is still an issue with the latest version:

[st-h]

It seems that ember >= 3.11 now provides a way to add passive event listeners via the on modifier: https://blog.emberjs.com/2019/07/15/ember-3-11-released.html

[rwjblue]

Confirm, though it doesn't yet avoid adding the non-passive listener to body (really the rootElement).

[filipe-torres]

My approach to solve this problem was add event on didInsertElement and remove them on willDestroyElement lifecycle functions, setting {passive: true} as last parameter when adding the event listener:

export default Component({

  didInsertElement() {
    this._super(...arguments);
    this.functionName = () => { 
        // function body
    };
    this.element.addEventListener('wheel', this.functionName, {passive: true});
  },

  willDestroyElement() {
    this._super(...arguments);
    this.element.removeEventListener('wheel', this.functionName);
  }
});

[pzuraq]

@filipe-torres this is essentially what {{on}} does, and we highly recommend you use the modifier over component lifecycle hooks, since those no longer exist in the Octane programming model.

[rwjblue]

We need to figure out the canonical list of events that issue this warning.

Some additional references:

• https://github.com/WICG/EventListenerOptions/blob/gh-pages/explainer.md
• https://medium.com/@devlucky/about-passive-event-listeners-224ff620e68c

What we need is an RFC that is exactly like emberjs/rfcs#486 but for these events. For reference, I think that the work that @simonihmig did implementation wise in https://github.com/emberjs/ember.js/pull/18214 is exactly what we need to do...

[simonihmig]

What we need is an RFC that is exactly like emberjs/rfcs#486 but for these events

The events in that RFC were a bit tricky as they were non-bubbling events that as such don't play well with EventDispatcher's event delegation approach and as such were harder to support. But touchstart, touchmove and whatever other events might be related to this issue don't have this problem. Rather the issue here is that (non-passive) event listeners are attached eagerly, even if those events are not actually used in Ember components.

So, @rwjblue what do you think about not deprecating these, but rather attaching event listeners lazily only when those events are actually used, i.e. reviving your previous work in https://github.com/emberjs/ember.js/pull/17911?

I would guess that this could practically solve the problem here, as in ~99% of apps (my own wild guess), the offending events are not used (at least in that old Ember.Component event method way). And if they are used in the app, you can easily rewrite the usage to attach event listeners manually (similar to RFC486's transition path) - which would enable the lazy approach to not attach non-passive event listeners.

[rwjblue]

Ya, that definitely seems fine to me. Might want to make only these lazy (since I suspect most apps won't use them) be making all of them lazy.

Ultimately, I expect all of the event dispatcher code to be gone when @ember/component is no longer used...