Perfect-scrollbar: "passive" event support

[mankins]

I've been noticing warnings in Chrome:

"Handling of 'wheel' input event was delayed for 3198 ms due to main thread being busy. Consider marking event handler as 'passive' to make the page more responive."

A little more googling presented the "passive" event handler, recently added by browsers:

http://stackoverflow.com/questions/39152877/consider-marking-event-handler-as-passive-to-make-the-page-more-responive/39187679#39187679

And so I wonder if there's any advice on how to setup perfect-scrollbar to take advantage of this feature?

[hatashiro]

Interesting. For the time being, I have no idea about the passive event handler, but I will absolutely look into this, at least before working on v1.0.

[mankins]

Thanks!

[hatashiro]

I've looked into the doc and found it can help PS, but seems difficult at least for the time being. Currently wheel and touch event logic is too complicated to safely apply the passive event support. I may consider using this after I finish v1 implementation and the logic becomes more straight forward.

[xDeepx]

I have same problem in Fuse http://fuse-angular-material.withinpixels.com/ui/forms

[lekhnath]

Any progress on it??

[hatashiro]

I've looked into the feature. Shortly, it is difficult to use it for the time being. Using passive event prevent scrolling from being blocked by main thread, by ensuring preventDefault() is not called. However, PS uses preventDefault() in the events for checking whether and how it should scroll. It may be possible in the future by modifying the logic and removing the predicates from PS, but at least not now.

Besides the passive event support, you can easily remove the warnings. Using passive events isn't the only solution for the problem. The warning means that scroll events are delayed because of heavy job in main threads. Thus, the problem is actually the heavy job in main threads, not the scroll events themselves. To fix it, just remove them and make the page light. If it is difficult to make them lighter but the problem still exist, please consider using native scrollbars. Keep in mind that using custom scrollbar is bad practice for performance.

I am afraid I close this issue here. If there is any good suggestion or implementation about this issue, please reopen it or upload a PR.

[kinkoazc]

Hi! I might be wrong, but, as per this answer http://stackoverflow.com/questions/37721782/what-are-passive-event-listeners (and these release notes https://blog.chromium.org/2016/05/new-apis-to-help-developers-improve.html), the whole point of using the flag is to "skip the line" of waiting for the jank-causing JS process and allow for smooth scrolling regardless.

[kinkoazc]

But that's not the issue I guess.

[edgargaza]

Hello there. I have the same issue.

[Violation] Added non-passive event listener to a scroll-blocking 'wheel' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952

Maybe this link can help you, @utatti

[mbonaci]

@edgargaza Wow, where did you manage to find that link :)

[edgargaza]

It was in the warning shown by Google Chrome console (it's the same link as it's in the error that I posted), maybe you can find it in the console too just by initializing an element with the
"new PerfectScrollbar(container)". It appears when I initialize it to be handled by Perfect Scrollbar.

[kerembeyazit]

I got this message in Lighthouse test.

[julesbou]

I solved the problem by adding ({ passive: false } option):

EventElement.prototype.bind = function bind (eventName, handler) {
  if (typeof this.handlers[eventName] === 'undefined') {
    this.handlers[eventName] = [];
  }
  this.handlers[eventName].push(handler);
  this.element.addEventListener(eventName, handler, { passive: false });
};

My issue was that i'm using PS inside an iframe (fixed positioned as a sidebar panel), and when I was scrolling the iframe, the parent page was scrolling too.

Maybe we should allow to pass this option.

[suhailkc]

I have the same issue

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

[andrei-gheorghiu]

@utatti , note you don't have to change anything else except the syntax, based on feature detection. Please have a look at my commit.

[jadamec]

Anything new about this? Added non-passive event listener to a scroll-blocking <some> event. Consider marking event handler as 'passive' to make the page more responsive.