Msg: Deferred long-running timer task(s)... in console

[dudafreitasrj]

Hello,

I began to use the "angular material" to two weeks, but I have had some performance issues when using on an android phone.

In the link below, you can see that when you open with Chrome using the inspection function, the site freezes time.

In the console, I note that the "Deferred long-running timer task (s) to Improve scrolling smoothness. See crbug.com/574343." It appears all the time.

Link: https://material.angularjs.org/latest/demo/list

[dudafreitasrj]

The solution is "#3287"

Add css .md-scroll-mask { position: initial;}

[ThomasBurleson]

@crisbeto - should we add this fix to our css?

[crisbeto]

I don't think this has anything to do with CSS. It seems to be shown on the first touch event after a route change. E.g. go into device mode, use the sidenav to go to another page and tap anywhere.

[crisbeto]

Well seems like there are ~10 timeouts, pointing to $browser.defer, being triggered on every page change, but those could also be done by Angular. To see it, throw this into your console:

var originalTimeout = window.setTimeout;
window.setTimeout = function(callback){
    console.log(callback);
    return originalTimeout.apply(this, arguments);
};

I think I've narrowed it down to somewhere in $mdGesture. It seems to happen right after a drag event. I'm not sure what might be causing it since the only time timeouts are being used is in the hold event, which isn't being fired in the demo site. @devversion do you have any ideas what it could be?

[crisbeto]

Me and @devversion have been looking into this. Looks like Chrome will log that warning on timeouts longer than 50ms (source).
Also seems like usually the last timeout before a warning gets trigger by the ripple directive here, however there are probably other directives contributing as well, because the warning still gets logged when removing the ripples completely.

[devversion]

So we've continued investigating.

We've read through the related chrome bug and noticed some changes, which led to:

• https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail

So we figured out, that the scheduler will recognize blocking timeouts in the scheduler, when the timeout was triggered inside of an event handler, which is waiting for a response while interacting.

document.body.addEventListener('touchmove', function(){
  setTimeout(function(){
   console.log('Touch Move');
  }, 1000);
});

The timeout delay must be higher than 50ms.

So while scrolling, we trigger a timeout, which is higher than 50ms.
Chrome detects this timeout and throws the warning, because there should be any response within the 50ms.

[crisbeto]

I'll close this because it doesn't seem very practical to fix this within Material, without breaking existing components.