Imagine this: You want to make some things with a XML element you receive in a method. So you try this:
function makeNiceThings(XMLDOM){
if(XMLDOM.getElementsByTagName("err")){
makeReallyNiceThings(XMLDOM.getElementsByTagName("err")[0].childNodes[0].nodeValue);
}
}
So, Javascript tells you you're trying to call childNodes[0] from a null reference. But if you try:
function makeNiceThings(XMLDOM){
if(XMLDOM.getElementsByTagName("err")[0]){
makeReallyNiceThings(XMLDOM.getElementsByTagName("err")[0].childNodes[0].nodeValue);
}
}
It works flawlessly.
However, you update the page sometimes, and both are working again, no problems at all.
I have already faces so many situations like this, that I really want to know if there is a place I can show these bizarre errors in order to make javascript even better. Google returned me nothing but places to discover programmer errors. Ideas?
Well, I don't see an issue there. In the first example you may get and empty array which is not nothing. So the condition becomes true. Whereas in the second example you do what you really meant to do — check if there's an element with index 0.
Or, if you are really convinced that this is not your fault, you should do what Rocket Hazmat said:
Bugs with JavaScript itself should be reported to the bug tracker of
the browser. Though, chances are this is not a bug with JavaScript.
But most probably this is a mistake in the code. If there's no err elements, you'll get an empty array and the condition will be evaluated to true; but there's no 0th element — that's why you get an exeption.
Hope that was clear.
I'm working in a large project that was developed for several years and had tons of code. Recently uninformative alert start to appear. It just says Undefined. I need to find the source of this alert. Is the any chance to make something like "breakpoint on alert"? I want to see the source of this alert.
One possibility is to redefine alert function. I tried to make it in firefox without any success.
I'd go with redefining window.alert right at the start of the code for this type of development purposes.
window.alert = function(e){ console.warn( "Alerted: " + e ); }
This will give You a line number for sure. ( Tested on chrome console )
This is an old question, but thought I would help out with a simpler solution. A very easy way in Chrome to find the source is by placing a debug in the console on window.alert:
debug(window.alert)
This will break on alert and take you to the source. In general, using console with debug(fname) will break whenever the function fname is called.
As a continuation to Vsevolod's method, in FireBug over Firefox for example, you could place one conditional breakpoint on each and every alert(), and see which one fires off, then go up the callstack shown by FireBug.
The condition could be "typeof whatever_variable_is_displayed == 'undefined'".
Is it possible to get a breakpoint when debugging, so that it stops each time when the certain class is accessed, otherwise it runs normally.
It's very common use case when one don't want to stop on jquery functions or other common libs functions, and want rather to stay on a specific js-file, but has no idea of what there could fire a bug, so one don't want explicitly to set a breakpoint on every line in the js file to catch all accesses on that file. Are there any options for Chrome DevTools for that debugging functionality?
Update:
Or maybe there is another way to get the similar functionality by ignoring whole libraries such as jquery, if there should be a breakpoint, so that only other files will be handled with debugger? That would be still not the best solution for the case, but anyway saves much time.
Update2:
the second approach is described here, but I have Chrome 26, and unfortunately cannot update it in the next one-two months, so this feature doesn't work for my browser now.
The only way to do it would be to sprinkle debugger; statements inside your file. At the begining of the file and at the begining of every function body should be enough.
Reference: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger
You can set conditional breakpoints to in the Sources panel. If you right-click on the line-number gutter it will show you a context menu for different options you can use, one of which is conditional breakpoints.
Like, if(condition) break;
Click Edit Breakpoint to do this
If you know the function(s) being called, you can use function breakpoints
debug(function);
function(...args);
When you call the function, it will hit the breakpoint. These aren't saved on page reload, but you can set a line breakpoint once you hit the function breakpoint.
This can get kinda tedious though.
If you have a array of functions, you can do
[function0, function1].map(debug)
#Tibos answer would be good if there was some sort of babel transform to insert debugger; at the start of every function, instead of inserting it manually.
You press F12 => select Sources => press CTRL+O => entry file name => finaly make breakpoint
I'm working on a substantially large rich web page JavaScript application. For some reason a recent change is causing it to randomly hang the browser.
How can I narrow down where the problem is? Since the browser becomes unresponsive, I don't see any errors and can't Break on next using FireBug.
Instead of commenting the hell out of your code, you should use a debug console log.
You should use the console.log() functionality provided by most modern browsers, or emulate it if you use a browser that doesn't support it.
Every time you call console.log('sometext'), a log entry in the debug console of your browser will be created with your specified text, usually followed by the actual time.
You should set a log entry before every critical part of your application flow, then more and more until you find down what log isn't being called. That means the code before that log is hanging the browser.
You can also write your own personal log function with added functionalities, for example the state of some particular variable, or an object containing a more detailed aspect of your program flow, etc.
Example
console.log('step 1');
while(1) {}
console.log('step 2');
The infinite loop will halt the program, but you will still be able to see the console log with the program flow recorded until before the program halted.
So in this example you won't see "step 2" in the console log, but you will see "step 1". This means the program halted between step 1 and step 2.
You can then add additional console log in the code between the two steps to search deeply for the problem, until you find it.
I'm surprised this hasn't been properly answered yet, and the most voted answer is basically "put console logs everywhere until you figure it out" which isn't really a solution, especially with larger applications, unless you really want to spend all your time copy-pasting "console log".
Anyways, all you need is debugger; someone already mentioned this but didn't really explain how it could be used:
In chrome (and most other browsers), debugger; will halt execution, take you to the dev console, and show you the currently executing code on the left and the stack trace on the right. At the top right of the console there are some arrow like buttons. The first one is "resume script execution". The one we want is the next one "step over next function call".
Basically, all you need to do is put a debugger anywhere in your code, at a point where you know the page hasn't frozen yet, and then run it, and repeatedly click "step over next function call" which looks like an arrow jumping over a circle. It will go line by line, call by call, through the execution of your script until it hangs/gets stuck in an infinite loop. At this point, you will be able to see exactly where your code gets stuck, as well as all the variables/values currently in scope, which should help you understand why the script is stuck.
I was just racking my brain trying to find a hanging loop in some rather complex JS I'm working on, and I managed to find it in about 30 seconds using this method.
You can add debugger; anywhere in your JS code to set a breakpoint manually. It will pause execution and allow you to resume/inspect the code (Firebug/FF).
Firebug Wiki page: http://getfirebug.com/wiki/index.php/Debugger;_keyword
Todays browsers Firefox/Seamonkey (Ctrl-Shift-I / Debugger / PAUSE-Icon), Chrome, ... usually have a builtin JS debugger with PAUSE button which works any time. Simply hit that when on a looping / CPU-intensive page, and most likely the "Call Stack" kind of pane will point you to the problem - ready for further inspection ...
To isolate the problem you could start by removing/disabling/commenting different sections of your code until you have narrowed down the code to a small part which will allow you to find the error. Another possibility is to look at your source control check-in history for the different changes that have recently been committed. Hopefully you will understand where the problem comes from.
Install Google Chrome, go to your page, press f12 and the developer console will popup. Then select the Scripts button, then select your script (ex: myScript.js) from the dropdown in the top-left of the console. Then click on the first line (or a line where you think don't hangs) and a break-point will be made. After the javascript reaches your break-point click on one of the buttons of the top-right of the console (you will see a button like Pause symbol and then other 4 button). Press on the 2º button (or the button after pause to step over) or the 3º button (step in). Mouse over the buttons and they will explain to you what they mean.
Then you will go in your code like this until it hangs and then you can debug it better.
Google Chrome debugger is far better than firebug and faster. I made the change from firebug and this is really great! ;)
I know it's primitive, but I like to sprinkle my js code with 'alert's to see how far my code is going before a problem occurs. If alert windows are too annoying, you might setup a textarea to which you can append logs:
<textarea id='txtLog' ...></textarea>
<script>
...
function log(str) {
$('#txtLog').append(str + '\n');
}
log("some message, like 'Executing Step #2'...");
...
</script>
In my experience, issues which cause the browser to become unresponsive are usually infinite loops or the suchlike.
As a start point, investigate your loops for silly things like not incrementing something you later rely on.
As an earlier poster said, other than that, comment out bits of code to isolate the issue. You 'could' use a divide and conquer methodology and near literally comment out half the pages JS, if it worked with a different error, you've probably found the right bit!.
Then split that in half, etc etc until you find the culprit.
I think you can Use Console Log like this
console.log(new Date() + " started Function Name or block of lines from # to #");
// functions or few lines of code
console.log(new Date() + " finished Function Name or block of lines from # to #")
By the end of running your webpage, you can identify the area that take so much time during executions, b
Besides using manual log output and the debugger it might sometimes be helpful to log each and every function call to track down where the loop occurs. Following snippet from Adding console.log to every function automatically might come in handy to do so ...
function augment(withFn) {
var name, fn;
for (name in window) {
fn = window[name];
if (typeof fn === 'function') {
window[name] = (function(name, fn) {
var args = arguments;
return function() {
withFn.apply(this, args);
return fn.apply(this, arguments);
}
})(name, fn);
}
}
}
augment(function(name, fn) {
console.log("calling " + name);
});
I know this question is old, but in VS2013 and you can press the pause button and get a full JS stack trace. This was driving me crazy because the loop was inside angular, so I couldn't really put in alerts, break points, etc. because I had no idea where to put them. I don't know if it works with the free express edition, but it's worth a shot.
I've also read that Chrome has a pause function, so that could be an option, but I haven't tried it myself.
I ran into same problem and that's how I resolved it.
Check Console for errors and fix them
Some time console even is hanging
Check for all the loops if the one is infinite
Check for recursive code
Check for the code which is dynamically adding elements to document
Use break points in your console
Use some console logging i.e log the suspected code blocks
Something I don't really see in these answers is that you can do e.g.:
let start;
let end;
//This would represent your application loop.
while (true) {
start = performance.now();
//Loop code.
//...
end = performance.now();
//Measured in ms.
if (end - start > 1000) {
//Application is lagging! Etc.
}
}
In this manner, you can perhaps detect when your application is starting to perform poorly etc.
https://developer.mozilla.org/en-US/docs/Web/API/Performance/now
Somehow somewhere in my code one of the elements on the page gets a style attribute which I don't expect it to get. Namely, it gets style="position:fixed". I can see this happening in HTML tab in Firebug, but can't find it in the code. The application is fairly big and I can't simply look through all of the code to find the place, besides, several third-party libraries are being used (jQuery is one of them).
So, my question is, is it possible to somehow catch this style being changed and get the trace?
In Google Chrome, right click on an element in the page and select "Inspect Element." The Developer Tools window or pane will open with that element selected in the source view. You can then right click the selected tag and choose "Break on Attributes Modifications."
Well, after a couple of hours of googling and experimenting, it seems that the best one can do it setup a MutationEvent handler (Firefox supports them) like this:
var node_modified = function(evt) {
if(evt.attrName == 'style') {
alert('Style is changing from ' + evt.prevValue + ' to ' + evt.newValue);
}
}
var test_close = document.getElementById('test_close');
test_close.addEventListener('DOMAttrModified', node_modified, false);
An then set up some kind of logging throughout your code and see when this event gets triggered. Unfortunately, you can't just set up a breakpoint in the mutation event handler and see the stack trace, because event handler's stack trace has no information about the place in the code, where the event got triggered. Kind of logical, but I think that with some hacking this feature can be implemented in Firebug.
Thank you for your time!
In Firebug's HTML inspector you can right click on a node and there is an option to interrupt on attribute change.
Breakpoints persist through page reloads and you can also browse the call stack.
Sounds like you really need a debugger. Firebug has one built in, otherwise you can give Venkman a try, which I find a bit more cumbersome but perhaps is more effective..
Good luck! :)