I'm currently developing a mobile single page webapp using React and Nuclear.js with Immutable.js.
When I due with click event, there's always a delay about 200ms long. I thought it was because the "click delay" problem, so I changed to touch events, which is onTouchStart in React.
But the delay seems still there. I use timeline view in devtools to investigate the delay, found the time was cost in "native v8natives.js:1229", as shown below:
I'm wondering what is the delay? and why it is always there, even when I use touch events instead of click.
I investigated it further today. The time shown in the chart is not that accurate and kind of misleading.
In fact, the time of the execution is included in that delay, though it is not shown.
So after digged into my scripts, using console.time() and performance tools packaged with React, the delay now is decreased dramatically.
Related
I have a relatively un-complex 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 complaints from users of really slow response. What they experience is that the page is completely 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
See #tiblu's comment 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 complaints recently, pointing to the release of Chrome 46. For example: this issue (code.google.com) and this issue (code.google.com).
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 comment.
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!
I've been experiencing some strange behavior with a web app I've been working on where the app doesn't function as expected when a user switches tabs. After some googling, I found the comments section on this question: How do browsers pause/change Javascript when tab or window is not active? which indicated that time outs under 1000 ms are increased to 1000ms when page focus is lost. This behavior would explain a lot of quirks that I've seen in my web app where the console.time feature was inexplicably reading out 1000ms times. After searching google I haven't been able to find any articles detailing this behavior and I haven't found a way to prevent it. Does anyone happen to know where I could find more info or how I might prevent chrome from increasing my timeouts on page blur?
EDIT: To answer the useless "Why?" response, it's a WebRTC app that I've been working on as a novelty. If certain timers in my page stop working the app is no longer a web based real time communication app, and is a web based delayed communication app.
Thanks to apsillers for finding the solution to this problem. This link: setTimeout/setInterval 1000ms lag in background tabs (Chrome and Firefox) details how web workers can circumvent this behavior.
I recently integrated fastclick.js into my project to eliminate the 300ms delay when physically tapping one of the links on a touchscreen device. Now I'd like to test it to make sure that it's integrated properly. If this is properly integrated I should be able to benchmark the 300ms speed difference.
(According to Google...mobile browsers will wait approximately 300ms from the time that you tap the button to fire the click event. The reason for this is that the browser is waiting to see if you are actually performing a double tap.)
I'm having difficulty thinking up the logic I can use to benchmark this, however...
The issue is that if I bind this to the link clicking event (and set var startTime = new Date(); there), it will only run the benchmarks after the link is registered (after the 300ms), and I won't be able to get an accurate benchmark that way.
Any ideas on how I can benchmark the difference and test that fastclick.js is properly integrated into my project?
I can try starting the timer at the mouseover event, but is there a better alternative to that?
Here's the link to the fastclick.js repository on GitHub
Use the difference of "mousedown" and "click" event.
On touch devices you also have "touchstart", use that instead of mousedown.
While developing a web-application based on the cappuccino-framework which
only has to run in a Chromium browser environment (~ Chromium V.19 released spring this year)
I struggle with the following problem:
We want the application to lock or delete all mouse clicks for some seconds (while the application performs some background calculations).
This apparently simple task seems to be almost impossible.
we implemented a Html-<div> layer over the whole screen and tried to manipulate its
mouseup, mousedown-handlers like:
onmouseup="return false;"
onmousedown="return false;"
but that didn't show any results.
Also iterating through all CPControl subviews of the actual Cappuccino window-view
and disable them
[subview setEnabled:NO];
does not really help:
Then indeed the subviews become disabled (and can't be clicked, exactly what we want)
but too LATE: although we disabled them BEFORE starting the background task,
the disable-effect comes into effect AFTER the background task has finished and so does
not prevent the user from making silly clicks during a sensible calculation.
I also tried to implement code like
[CPRunLoop limitDateForMode:CPDefaultRunLoopMode];
after disabling the CPControls and before starting the background task but it also does not work.
So has anyone an idea either on the Javascript-/Html or Cappuccino side?
CPWindow has a method: setIgnoresMouseEvents: Just call that on your window.
A few questions here:
Is there anyway to keep iOS from freezing javascript on the page while scrolling?
Does iOS freeze javascript when your in another tab or if you switch apps?
Are there any other major javascript limitations on iOS?
iOS 6.x suspends all event timers in response to touch events like scrolling and has a tendency not to start up all the timers again once the event is done. It's a well known iOS 6 bug that is super-annoying. It pretty much breaks parallax and stuff. Some people have resorted to building their own scroll functionality.
Here's another StackOverflow on the same topic:
iOS 6 safari, setInterval doesn't get fired
and another:
setInterval pauses in iphone/ipad (mobile Safari) during scrolling
and here is the closest thing you'll get to a bug report on it (Apple doesn't make bug reports public to maintain the illusion of perfection, so developers made their own bug site): http://openradar.appspot.com/12756410
This bit of code will unfreeze timers that are broken / lost / destroyed by iOS during a page scroll: https://gist.github.com/ronkorving/3755461
This is another attempt to fix the freeze: iOS 6 js events function not called if has setTimeout in it
Unfortunately, there is nothing you can do to fire events WHILE page scrolling. Like fade out a back-to-top link when scrolling up the page. When it comes to scrolling, iOS6 is incapable of rubbing it's tummy and patting it's head. (iOS5 works fine, btw. This is a regression)
To answer the third question, a decent-sized limitation is that sometimes innerHTML just plain doesn't work. From the accepted answer:
It happens when the CPU of the phone is very busy (say 100%). Then the rendering engine sometimes forget about innerHTML settings.
The solution included in my unify project is to test if there is an element in childNodes, otherwise apply it again.