I have a relatively un-plex ASP.Net application, which occasionally displays an alert message in layer, with a shadow, with a pushbutton to dismiss the notification.

This code has been working fine for years.

Lately, I am getting plaints from users of really slow response. What they experience is that the page is pletely unresponsive, and when they click on the [OK] pushbutton nothing happens for a really long time.

When I record a Timeline, I can see the original even which caused a round-trip to the webserver, and I can see the response from the webserver. I can also see all the Javascript code which runs as a result of the response.

As far as the application is concerned, the transaction is over, and, as far as the Javascript is concerned, the transaction is over as well. All we need to do is wait for the user to click the [OK] button and we will dismiss the notification popup.

This is where the "freeze" happens. The [OK] event is not delivered for like 20-30 seconds. What's going on in the meantime? That's why I'm writing:

We see some very short timers fire every once in a while, then we see a quick Recalculate Style call, followed by an Update Layer Tree event.

The Update Layer Tree event takes 10-12 seconds!

Here's the code for the dialog which is going unresponsive because of the Update Layer Tree events The gets displayed first as you see it here, then, if something goes wrong, it may get updated with code similar to showAlert:

Status/error dialog code

I have a relatively un-plex ASP.Net application, which occasionally displays an alert message in layer, with a shadow, with a pushbutton to dismiss the notification.

This code has been working fine for years.

Lately, I am getting plaints from users of really slow response. What they experience is that the page is pletely unresponsive, and when they click on the [OK] pushbutton nothing happens for a really long time.

When I record a Timeline, I can see the original even which caused a round-trip to the webserver, and I can see the response from the webserver. I can also see all the Javascript code which runs as a result of the response.

As far as the application is concerned, the transaction is over, and, as far as the Javascript is concerned, the transaction is over as well. All we need to do is wait for the user to click the [OK] button and we will dismiss the notification popup.

This is where the "freeze" happens. The [OK] event is not delivered for like 20-30 seconds. What's going on in the meantime? That's why I'm writing:

We see some very short timers fire every once in a while, then we see a quick Recalculate Style call, followed by an Update Layer Tree event.

The Update Layer Tree event takes 10-12 seconds!

Here's the code for the dialog which is going unresponsive because of the Update Layer Tree events The gets displayed first as you see it here, then, if something goes wrong, it may get updated with code similar to showAlert:

Status/error dialog code

• javascript
• google-chrome
• timeline

• 2 You'll probably need to post some code to get the help you need – Matthew Strawbridge Commented Nov 10, 2015 at 22:09
• I will post some code tomorrow ... but in the meantime, can anyone think of any possible reason Chrome should go into such a state? 12 seconds to do an Update Layer Tree? ... and as you can see in the plot, it does it again a few seconds later! – TLMAGE Commented Nov 11, 2015 at 0:27
• 1 stackoverflow./questions/25724126/… – tiblu Commented Nov 11, 2015 at 8:33
• TIblu ... I read that article, that mentions many calls to Update Layer Tree ... My case has a single call to Update Layer Tree which takes 10 seconds. – TLMAGE Commented Nov 13, 2015 at 20:53

2 Answers 2

See @tiblu's ment for detail on why Chrome would perform Update Layer Tree.

As for taking 12 seconds: does the interaction behave normally in other browsers, for example Firefox or Safari? If your code has been working fine for years as you say and the browser response issues have been popping up recently (> mid-October, 2015) and only in Chrome the issue may not be your code.

There are a number of similar new issues and plaints recently, pointing to the release of Chrome 46. For example: this issue (code.google.) and this issue (code.google.).

CPU spikes are responsible for browser unresponsiveness, which you can monitor using Chrome's Task Manager. As for why CPU is spiking and further detail you'll need to follow the issues above and others as they develop.

Apologies for the pseudo-answer, don't currently have the rep to slip this into a ment.

Thanks to all who responded ... I was unable to figure out how to re-install an older version of Chrome, but I did manage to get my hands on a beta version of Chrome 48 (48.0.2564.8), and, to my most pleasant surprise, I am no longer able to reproduce the problem.

Just to be sure, I restored 46 from this morning's BACKUP, and it re-exhibited the issue. After re-installing beta-48, the problem is gone.

Hooray! Well done everyone!