I've run into an issue where Internet Explorer 7, 8 and 9 freezes because of a request that gets made in the onbeforeunload JavaScript event. This is a complex site with a lot of things going on, but I've managed to isolate the issue into a small test. Exact steps to reproduce in IE7:
Open Internet Explorer 7
Keep one tab open the whole time your testing (to keep the same session)
Open a new tab and go to http://www.brillbrothers.com/LockIE/test2/
Close the tab
Repeat steps 3&4 until requests start to hang (normally takes two times for me). Once they are hanging, the requests don't even get made by IE any longer according to the web proxies / network monitors I'm running.
Steps to reproduce in IE8 are about the same, although the results are a bit different. It normally works the first two times, then intermittently works for a while, then the requests start hanging every time.
In IE9, the steps are still the same, but it takes even longer to reproduce the issue.
I can't reproduce this in IE10.
I've also found that adjusting some registry values can make the problem better. If I change the max connections per domain higher (kb # 282402), the problem takes longer to reproduce. I do have complete control over the browser in this case, since this is used for an internal tool, so any sort of registry change, etc, is fine as long as it won't cause any different problems.
I've also setup a script to run the steps above automatically. It basically opens a new window to the test URL, waits a few seconds, then closes the window. You can run that here to see the problem quickly (you'll have to allow the page to open new windows): http://brillbrothers.com/LockIE/test2/runTest.html
The crazy thing is almost everything seems to affect the outcome. If I set different cookies in the AJAX call, change the content of the AJAX call, etc, it can make it work differently. Completely crazy. I'll be seriously impressed if someone has a solution to this. :)
Related
There are many instances where I leave a looped async function running on a chrome tab (for testing) but whenever I leave the lab, Chrome seems to significantly lessen the speed at which js runs on that tab. Is there any way to have full cpu power for running javascript on a different tab than that I am currently on?
For example, when I'm running a js test file on tab 1 with localhost:3000 but I go off another tab to do something else for a while. When I come back to tab 1, I see minimal progress.
https://developers.google.com/web/updates/2017/03/background_tabs
Background tabs can have a dramatic negative effect on browser performance, especially on battery life. To mitigate this, Chrome has been placing various restrictions on background tabs for the last several years.
...
Chrome provides the --disable-background-timer-throttling flag for use cases like running test suites and other user-sanctioned heavy computations.
So basically just launch chrome with the --disable-background-timer-throttling and you should be good to go
Not a specific programming query but more in relation to a javascript app as a whole having a general problem and looking for any possible solutions to debug it.
I'm using React and have a single page app which is receiving streaming data from a websocket about 40 times a second. The user display is updated a similar amount of times each second to show the updates.
The problem I'm having is that after running the page for more than 12 hours not only google chrome, but all of other applications start to freeze momentarily. If I start trying to do too much with the other applications, sometimes all windows on chrome will turn black and it can freeze for up to 30 seconds. The more processing/memory used by other applications and the more versions of the react app I have open, the faster the freezing starts, but in any case only starts after a few hours.
The only fix is currently to restart the whole of windows because even after closing chrome the problem persists.
I've tried using google chrome profiling to inspect the heap type to see a memory leak but the memory size is the same as when I first launched the app.
I've tried reinstalling chrome but this didn't fix the problem either.
I read somewhere online that freezing like this could be due to too much garbage collection? But what would be triggering this to happen in excess? And I don't understand why that would persist after I close google chrome.
A possible solution would be to build in an auto-refresher to refresh the page every hour once the user has been idle for at least 5 minute, but this seems a bit overkill if its a problem which can be solved.
Any tips/advice for debugging this kind of issue or obvious places I should search for a solution? as its very much un-shipable in its current state
The issue was due to one of the two following things on windows 10. I performed both and one of them has caused the freezing to stop:
1) In control Panel -> Power options -> additional power settings -> change plan settings -> change advanced settings-> change the hard-drive sleep option to never or 0
2) Updated chip-set drivers from the motherboard manufacturers website.
I'm working on Chrome extension which needs to perform an action just before Chrome closes. Is there any method like chrome.window.onClose.addListener(...), or chrome.runtime.onClose.addListener(...) to ensure that something will be done and then chrome will close itself?
I've been struggling with this problem for two weeks. Here are the options for potential solutions that I've found, but they didn't work.
My investigation results:
Using function: chrome.runtime.onSuspend.addListener(...) - I don't know why, but it doesn't work at all for me. For example, I've tried to write a callback for this event, which tries to add hardcoded data to the indexed DB, but it doesn't add it. Description of this method even says that the callback is not guaranteed to be completed. OnSuspend documentation
Sent to the event page just before it is unloaded. This gives the extension opportunity to do some cleanup. Note that since the page is unloading, any asynchronous operations started while handling this event are not guaranteed to complete.
Chrome working in a background - with this option my extensions seems to work, but... only on Windows older than Windows 10. I've checked few options and on my other computer, which has Windows 7 installed, processes connected to Chrome are closing more slowly, which gives time for my extension to perform necessary tasks. Unfortunately, Windows 10 kills all the processes much faster. I've check option "continue running background apps when google chrome is closed", but it doesn't change anything. I've also enabled flag "#enable-push-api-background-mode", it hasn't helped either.
Keep Chrome running in the background on Win10, Enable flag to keep Chrome processes running
chrome.app.window.current().onClosed - I've found a similar question on Stack Overflow, and one of the answers was the code mentioned above. The problem is when I try to type chrome.app.win... inside console, it doesn't show any suggestions both in background script and content script. Google's documentation doesn't mention any permission that I've to add inside my manifest.json to get access to this functionality.Stack Overflow similar question, Google's documentation about chrome.app
Methods build in web browser - I've thought that method window.onclose might be useful in my case. I've performed the same test as for chrome.runtime.onSuspend, but the result was exactly the same. Documentation
I've stuck and haven't got any idea how to solve my problem. Maybe I missed something important? Hope you will help me.
One of my users is intermittently getting a dialog in IE 8 that says:
A script on this page is causing Internet Explorer to run slowly
This problem has been reported numerous times in the MSDN forums and other places on the web. For example:
http://social.msdn.microsoft.com/Forums/ie/en-US/0fdb7550-0a59-4553-a90e-1958475f2ce5/how-to-debug-a-script-on-this-page-is-causing-internet-explorer-to-run-slowly?forum=iewebdevelopment
http://social.msdn.microsoft.com/Forums/ie/en-US/dafffdd8-a390-4a3c-a904-867acaec298e/error-message-a-script-on-this-page-is-causing-internet-explorer-to-run-slowly-for-ie8?forum=whatforum
http://social.msdn.microsoft.com/Forums/ie/en-US/e9d16d2a-60e1-4d6f-8f80-0d981eab3a2e/a-script-on-this-page-is-causing-your-web-browser-to-run-slowly?forum=bingmapsajax
So, this question is a duplicate of those and many others. But it is an intentional duplicate, because I don't think any of those questions were answered in a way that helps a user (developer) to determine precisely what in his scenario causes the dialog to appear.
I know that based on this page:
http://support.microsoft.com/kb/175500
the dialog appears when a certain number of statements have executed since a new script begins execution (through a variety of means). By default the number of statements is 5,000,000 but this is configurable via a registry entry.
The general prescription to this problem is a combination of:
Write less code. Unfortunately, this is not always possible.
Use web workers. This is not an option for IE before IE 10, nor with
some mobile browsers.
Use setTimeOut, setInterval, event handlers, etc to break the
script(s) up. This is a legitimate strategy across all browsers.
So, I understand what the problem is in general terms, and I understand what the options are to solve the problem, again in general terms. The question is, how to determine what area(s) of the code are causing the dialog to appear for a specific user? Often this problem occurs with a very large code base (including third party libraries), so a manual review of the code base without some tooling support is not feasible.
Most browsers, including IE8 and later, have profiling tools that enable the developer to determine JavaScript CPU usage. With the exception of IE, other browsers decide a script is long running not based on the numbers of statements executed but rather the amount of time the script spent executing. To this end, the profilers available in (or as add ons) to the browsers can identify the percentage and usually raw time spent executing a function, both inclusively and exclusively for a function, and the results can be sorted accordingly. IE's profiler will also give you a count of how often a function is called. None of these profilers tell you how many statements of code within a function were executed during profiling; they tell you only how long was spent in the function and how many times the function was called. This doesn't help with IE's slow script dialog logic, which is based on the number of statements (not time) that were executed. There is sometimes a correlation between the time spent executing a function and the number of statements, but it is not a reliable relationship as of course different types of statements can take very different lengths of times to execute (e.g. many native JavaScript functions are faster than calls which update the DOM; both have the same statement count but the former executes faster than the latter, making examining %/raw time not very useful).
One approach I've used that is of some value is when the slow script dialog appears, start the debugger in IE (if not already started) and select the break on next statement command in the debugger. Then click the dialog button in the browser that allows the slow script to continue executing. At this point, the debugger is invoked and the developer can examine the call stack to determine what is executing at the time the slow script dialog appears. This is okay, but a very manual approach and there's no guarantee there aren't multiple scripts running that can at different times invoke the dialog.
An interesting idea I've seen suggested is to use a JavaScript code coverage tool to instrument the code base. There are multiple JavaScript code coverage options out there, but the ease of use of a browser extension that could dynamically instrument the code seems like an ideal solution. (Another interesting idea is to use a proxy server, for example http://siliconforks.com/jscoverage/manual.html; 'jscoverage --server --proxy', but I couldn't get this to work on virtually any website, except the the silicon forks website itself). There's a proof of concept one available for Chrome (http://googletesting.blogspot.ca/2011/10/scriptcover-makes-javascript-coverage.html) that I think could be a great start for helping resolve the the slow script problem -- if such an extension could be made for IE.
So, to reiterate my main question is what tools/processes can one use to debug/analyze a slow script dialog appearing on a user's machine? A subquestion would be, does anyone know of any JavaScript code analysis tools that could be repurposed to help in diagnosing the slow script dialog in IE, and that takes minimal deployment effort? Can an IE extension be written, in theory, that does the sort of code coverage as the Google' script cover extension does?
Thank you,
Notre
In the old times JavaScript was not used that much. Pages used to me more static. These days the PC's were less powered and it was more popular to run complex tasks on the server. JavaScript was only used for some animations.
Microsoft (my way or no way) took their time to acknowledge heavily JavaScript-ed content. (They were also fiddling with their JScript in IE8). Until IE9 they were considering that running > 5 000 000 instruction in a script is a potential mistake.
I'm not aware of any tool that retrieves the instructions count. It's a browser build in feature.
But most of the browsers retrieve the execution time of a function. I know that in every different computer, same number of instructions can take different times, but you can set a benchmark.
Run a script with 5 000 000 instructions on the machine and see how long it takes to run. Then use that time to benchmark your other JavaScript. It's not 100 % accurate but it can became close once you fiddle with it.
Since old IE developer tools are quite poor you can use some third party one. A ussage example here:
deep-tracing-of-internet-explorer
Anyway, the “A script on this page is causing your computer to run slow ...” is only a problem in IE4 - IE8. Since those browsers are obsolete, so should this question be.
during the development with angular + requirejs. I met a weird problem.
if I quick refresh page(like pressing F5), after a few times, I will get the following error message and the page is not working any more even refresh the page again, unless clean the cache and open the page on new tab:
Error: $digest already in progress
at Error (<anonymous>)
at beginPhase (http://www.caoglish.info/angular_bug/assets/vendor/angular/angular.js:8495:15)
at Object.Scope.$apply (http://www.caoglish.info/angular_bug/assets/vendor/angular/angular.js:8297:11)
at done (http://www.caoglish.info/angular_bug/assets/vendor/angular/angular.js:9357:20)
at completeRequest (http://www.caoglish.info/angular_bug/assets/vendor/angular/angular.js:9520:7)
at XMLHttpRequest.xhr.onreadystatechange (http://www.caoglish.info/angular_bug/assets/vendor/angular/angular.js:9490:11)
at http://www.caoglish.info/angular_bug/assets/vendor/angular/angular.js:9499:11
at sendReq (http://www.caoglish.info/angular_bug/assets/vendor/angular/angular.js:9333:9)
at $http (http://www.caoglish.info/angular_bug/assets/vendor/angular/angular.js:9124:17)
at Function.$http.(anonymous function) (http://www.caoglish.info/angular_bug/assets/vendor/angular/angular.js:9267:18)
this error seem to only happen in chrome. I try to trigger it on IE and Firefox, it was not happening. however, I try it in chrome on slow computer, it also not happen.
the computer which I triggered this issue has i7 cpu, 8gb ram.angular I using is 1.0.8.
I attached my code which isolated this issue. my project code is more complex then this, so less times to trigger it. the isolated code may requires press more few times on F5 to trigger the issue.
the isolated example code: Link
how to trigger the bug: video
quick pressing F5 until it happen.
I create a issue post on angular project: Link
This question may be dead, but I've seen the same behavior. And it's definitely not an Angular issue. It's just a simple race condition, and it's more or less unavoidable. When you hit F5, the browser halts everything going on in the "sandbox" for security reasons: standard requests for things like IMG content, XHR requests, the main thread your Angular code runs in, etc. It's extremely fast but not instant, and if you work hard to disrupt it, you succeed.
IMO the root question here should be whether this is "bad", and to me, that means does it either a) create a security vulnerability, or b) do something that could corrupt important data.
You can rule out the first because only code already running in the browser at the moment F5 was pressed could POSSIBLY try to exploit whatever edge cases come out of the race condition here. And if it's already running in the browser, it can do anything it wants because it's already "within the walls" so to speak.
You can rule out the second because you aren't supposed to design Web apps that require 100% confidence that the next line of code will be executed... because you know that's never certain. The user could just close the browser any time they wanted to, and once you assume that you have to code in such a way to tolerate these kinds of conditions anyway.