Processing of the input event "wheel" was delayed for xxx-ms due to the fact that the main thread is busy

I used the Chrome version: Version 55.0.2883.75 beta (64-bit) with material-ui ( https://github.com/callemall/material-ui ) version 0.16.5 with react + react-dom version 15.4.1 and noticed The following warning message when I scroll with the mouse wheel:

The input event "wheel" was delayed by xxx ms due to the main thread being busy. Consider the labeling event handler as “passive” to make the page more responsive.

Here is a screenshot from the Chrome Chrome console: enter image description here

At first, I thought that another react-waypoint dependency caused the problem, but after some investigation and thanks to lencioni follow ups at https://github.com/brigade/react-waypoint/issues/143 , I realized that this could be caused by a combination react with the latest version of material-ui .

With material-ui version 0.16.5 , wheel event listeners become visible from the Chrome Toolbox tab: enter image description here which has the passive: false property, which can explain why the warning appears on the console when scrolling when the main thread is busy.

However, after reading a similar post about Consider labeling the event handler as “passive” to make the page more responsive , I'm a little confused because it suggested that we might have to wait for your .js to support support . Before raising the github question to suggest such an improvement, my confused point was that which JS library / dependency can be separated while waiting?

In this particular case, is it react (see discussion )? or material-ui ? Or something else that was completely left out of this question? The above screenshot showed that the wheel event listener was added by ReactEventListener from react-dom , but by lowering the material-ui version to 0.16.4 , the warning will disappear because there is no wheel event listener.

So, I'm mainly at this crossroads of browser, react and third-party dependencies and trying to understand the variables that contribute to this problem, and is there anything that we, as a consumer of these libraries, could do to solve this problem?

Any suggestions or comments would be highly appreciated! Thanks.

+6
source share
1 answer

Just confirming that this material-ui causes it, since I do not use a “reaction point”, and also test it on MaterialUI v0.16.5 and React 15.4.x.

Update. It seems like everything is working fine after upgrading to MaterialUI v0.16.6.

+2
source

Source: https://habr.com/ru/post/1013162/


All Articles