How to debug Chrome [Violation] 'message' handler took


I’m building an app that relies on @Akryum 's RecyleList component to build a table-like view that scrolls through a complex list of components.

If I scroll in small increments everything runs smoothly, but when I try to do a faster scroll, the scrolling becomes jittery and I start getting the [Violation] messages in the console:

[Violation] 'message' handler took 326ms

The warning seems to be traced back to vue.esm.js, particularly these lines:

function flushCallbacks () {
  pending = false;
  var copies = callbacks.slice(0);
  callbacks.length = 0;
  for (var i = 0; i < copies.length; i++) {

Just to start with something, I am hoping that someone can help me out with ideas about how to debug the warnings. I managed to track down the the components that, when rendered, slow down the scrolling and produce the violation, but can’t figure out what particular code in these components is at fault.

My app is quite complex (uses Vuex, dynamic components and gets data from an API) so it would be extremely difficult to reproduce a testable environment in CodeSandbox. If all else fails, I’ll try to generate a demo that outlines the issue.


Do you have any components that listen to an on scroll event? I assume theres something, perhaps your table component that executes a callback on the scroll event, and perhaps this is a heavy function thats executed causing the warning and jitteryness of your application.

There is a warning about performance issues in the readme of vue-virtual-scroll that talks about lots of components and a certain mode may result in performance lost. This could be causing Chrome to warn you about such an issue.


The structure of the app is as follows (very simplified)

  • one big div that has a wheel listener on it
  • when a wheel event is handled, the new scroll positions are calculated based on the current scroll and the wheel deltas.
  • the RecycleList element is manually scrolled to the new scrollY using scrollToPosition

So basically the main thing that listens to the scroll event is the RecycleList.

Its job is to infuse the component in the main slot with the correct item data.

What happens next, is that the component (developed by our team) rendered in that slot updates reactively to the changed props - and this is where the heavy stuff happens.

I’ve started picking off child components to see if that improves scrolling and, indeed, I found which are the main “villains”, but without a possibility to trace the [Violation] message directly to the code, I don’t know where I should start improving.