Firebug is certainly a wonderful tool for javascript debugging; I use console.log() extensively.
I wanted to know if I can leave the Firebug-specific code in production.
What's the best practice? Commenting the debug code?
If you leave console.log() calls in your production code, then people visiting the site using Internet Explorer will have JavaScript errors. If those people have extra debugging tools configured, then they will see nasty dialog boxes or popups.
A quick search revealed this thread discussing methods to detect if the Firebug console exists: http://www.nabble.com/Re:-detect-firebug-existance-td19610337.html
been bitten by this before. Ideally all the console.log statements need to be removed before production, but this is error prone and developers invariably forget or only test in FF + Firebug.
A possible solution is to create a dummy console object if one isn't already defined.
if( typeof window.console == 'undefined'){
window.console = {
log:function(){}
};
}
One word of caution: It used to be the case for Safari on 10.4 that any call to console.log would throw a security exception as the console object is a reserved object used in the Mac OS Dashboard widgets. Not sure this is the case anymore, will check tonight.
Personally I modified my compressor a while ago to strip out console references pre-compress. A few minutes adding a regex there saves a lifetime of hassle.
Just thought I would add a really good tip for any js debugging.... use the keyword "debugger", and its like a breakpoint in the code, firebug detects it also MSIE (if you have visual studio) detects it and as I say its a breakpoint.
Not many people seem to know about this but I have found it invaluble... also if there isnt a debugger installed on the machine that is running the code, nothing happens and the code goes through fine. Although I wouldn't advise leaving them in there.
I have had many a headache caused by this.
I use console.log() a lot, and until recently, found that it would cause the entire JS code to fail in versions of FF not using firebug.
I usually run a find before going live, and commenting it out.
D
Some compressors will strip out any line prefixed by ;;; (which is a legal sequence to have, being three empty statements.) This way you're not strictly limited to console references (i.e. you could do some calculations and then console.log() the result at the end, and the compressor can strip all of them out.) I use JavaScript::Minifier for this.
I use this in OOP Javascript, making my own wrapper for log that checks that firebug exists:
myclass.prototype.log = function()
{
if( typeof window.console != 'undefined' )
{
console.log.apply( null, arguments );
}
}
Just call:
this.log( arg1, arg2, ...)
Just a reminder that IE Dev Tool does not support apply() on console.log.
Calling console.log.apply() will raise exception in IE8 when dev tool is active.
You can try JavaScript Debug, it is s simple wrapper for console.log
http://benalman.com/projects/javascript-debug-console-log/
Related
This is a simple app simulating a chat. I provide jsfiddle:
http://jsfiddle.net/LkqTU/2785/
Some messages coming from the server, simulated by the button, and a user typing on a textarea binded to the keypress event to get te enter key and send the message.
Well, this is working fine in Chrome and Firefox but fails in IE9.
What could be wrong?
Thanks
Well, it was relatively easy to locate an error: assigning this to an external variable named self right at the beginning of Model function just doesn't look right.
The explanation why it worked fine in Chrome and Firefox, but failed in IE, though, is much more interesting. Obviously varless self refers to window.self, which is actually a special property of window object - reference to... window itself (MDN).
Internet Explorer is actually well-known for its specific treatment of this property: while in other browsers window === window.self evaluates to true, in IE it's false. And I wouldn't say IE does it without any reasoning; check this discussion for some details.
Ironically, in this particular example IE turns out to be a half-hero. ) I said "hero", because IE is the only browser that doesn't let you overwrite window.self. All the others are not so picky; add console.log(window.self) to the end of your script to witness their shame. )
And I said "half", because IE could be much more... heroic about it. ) Instead of ignoring window.self = ... line silently (and throwing an error for that far away line that used the ignored assignment in a slightly different way), why didn't IE just give an early warning? Damn, even a notice would do.
Anyway. It's pretty easy not to rely on IE's sporadic heroism for such things: just add 'use strict' line at the beginning your script, and voila! both Chrome and Firefox will spit out a 'Reference Error' warning right where it belongs - at self = this line. )
Yes, I understand that 'use strict' use is not a simple step, and it might break some scripts; yet I wholly stand by Nicholas Zakas' statement on that topic.
I have seen jquery-ui-1.8.11.js verify console.log functionality by doing
if (this.debug)
console.log()
I have also seen people define an anonymous function that is a no-op for browsers with no console logging like IE7.
if(typeof console === "undefined") {
console = { log: function() { } };
}
Is there a technical difference or are both functionally equivalent?
In the first example you've given, this.debug will be a reference to a debug variable in the jQueryUI code. This debug variable will have been set elsewhere, possibly by checking whether console is defined, but also possibly with other settings.
In any case, the first example is specific to the application; if you want to do a generic check to see whether the console is available, you'll need to use the second technique. You don't have to define an empty console object as per the example, but doing it that way does mean that you won't have to do the if() condition every time you want to call console.log().
Having said all of that, I would counsel you strongly to avoid putting any code into production which contains calls to the console. The console should only be used for debugging purposes while you are working on the code. It should not be necessary in final release, and doing so can be a sign that either your code is unstable or you're unconfident of it, neither of which is a good sign if you're releasing the code for live use.
(libraries such as jQueryUI are an exception to this rule, as they need to provide functionality for developers to do debugging while writing code using their library)
Both of those do something else. The first code suppresses logging messages unless a flag is set. The people who develop jQuery UI need logging when working on it, and turn it on. But people using the library don't want to have their console cluttered by log messages from libraries, so it's off by default. It lets you turn off logging even when the browser supports it – that regular users on IE7 don't get script errors is a (possibly intended) side effect.
The second code defines a dummy console.log(), so you can call the method without checking if it exists everywhere. It will not suppress logging on browsers where it's supported.
The second of the two is standalone, not relying on jQuery. In my opinion, that makes it better.
I'm not a JavaScript Wizard by a long shot. But I am a web-developer and so I need to know my way around it at least a bit.
Something I'll often do is simply alert a variable to see what it is.
However, the problem is that I'll often get a result like: "object HTMLInputElement". To me this means little to nothing. Sure I can look it up, but I need to alert children() of children() of children(), etc...
I've tried walking through the JavaScript with Firebug, but for some reason this is very slow. Firefox hangs when I start a debug session, for every single debug session and I don't know why.
So, I want to inform if there is a way to get detailed info on variables some other way. Or a system I can use to work with to make things easier.
I find the developer tools in Chrome work quite well, giving a good amount of detail on demand (usually just hovering the mouse over the variable in the script tab; if that variable is a structured object, a little tree control appears and you can drill down). But then, I don't have your Firebug issue either (or at least, not often anymore).
Debugging with alert is very time-wasteful and, as you've found, frustrating; if at all possible I'd look at using a real debugger (like Chrome's Dev Tools; I've also heard good things about Opera's).
This should help:
http://www.openjs.com/scripts/others/dump_function_php_print_r.php
The easiest way to inspect a javascript variable is with a debugger. If Firebug is not working out for you try using Google Chrome, it has an inspector built in.
Btw - not sure what you mean by "start a debug session". If you have firebug installed, you should simply be able to click on the firebug icon on the bottom right of your browser. Go to the script tab, and select from the drop down whatever js file you want, stick in a break point (just left-click on the margin) and refresh the page. I've never had a problem with Firebug, it's always worked extremely well. I strongly advise figuring out whatever your issue with it is, it will make your life a million times easier.
Using any of the browser dev tools, including IE9, you can use console.log to get the variable output on the console. What information this gives you will vary by browser, but with Firebug it allows you to explore the variable in the DOM inspector tab, with full access to all properties and functions (you can even copy the content of a function to paste elsewhere).
For instance:
var foo = {};
// Do lots of stuff with foo
if (typeof(console) !== "undefined" && console.log) { // prevent errors when console not open, ideally all console calls should be removed before going into production
console.log(foo);
}
This has the advantage that it doesn't require any break points, so no slow step-debugging. It won't solve everything though, you'll often still need the debugger.
I just started doing some Javascript work for a project, I do mostly backend work so I'm sorry for being new at this! Also, not using a Javascript framework because I want to learn about the fundamentals before making everything very easy for myself :)
So, here is my question/confusion: I wrote a little javascript that dynamically changed forms. This is how I called the code:
// loads the initial box
window.onload = initList(environment_box);
// loads artifacts on each change to environment select box
environment_box.onchange = changeList;
This worked like magic - in CHROME that is! I never noticed it wasn't working in Firefox (its just an internal tool, so I can assume decent browsers, but I figure hey, if its working in Chrome, it will work in Firefox!). So, I did some investigation, and it seems as though the code isnt getting executed in Firefox. I whipped out firebug and wanted to see what was going on.
The interesting thing was, when I enabled Console on firebug, my code got executed! I am very confused as to why, and I would much appreciate any help I could get. Thanks!
-Shawn
You are calling some method on console in your JavaScript is my best guess. Chrome has console defined be default, so it is not a problem.
On Firefox, however, there is no such global object (not without Firebug), so when you try to call a property on an undefined object like,
console.log(..);
it throws an exception which you are not catching, so the JavaScript execution halts.
You're probably calling a method of the console object which just doesn't exist by default in most web browsers. It may be always available on webkit based browsers (like Chrome) but with firefox/IE(/opera?) it requires an external add-on, either firebug or a javascript dependency.
Checkout things like firebugx which simply defines the most common methods of a console object as no-op functions.
Is there an easy way to find parse errors in javascript code?
Last week I was debugging a javascript problem where the first javascript function that was called gave an 'object expected' error. I later determined that this was because the browser wasn't able to parse my javascript code. I eventually solved the problem but it was a painful process that involved pouring over my code line by line, trying to find my mistake.
There must be an easier way.
Use a tool like Jslint or an alternative browser.
Until recently, IE was the only browser that did not have built in development assistance. Other browsers will a) not come to a grinding halt on the first error they encounter, and b) tell you what and where the problem in your code is.
My favorite "quick ad easy" way to test IE syntax problems is to load the page up in Opera. It parses code like IE but will give you meaningful error messages.
I'll clarify with an example:
var foo = {
prop1 : 'value',
prop2 : 'value',
prop2 : 'value', // <-- the problem
};
If I remember correctly: In IE6 and IE7 the code will break because IE demands leaving the last comma out. The parser throws a fit and the browser simply stops. It may alert some errors but the line numbers (or even filenames) will not be reliable. Firefox and Safari, however, simply ignore the comma. Opera runs the code, but will print an error on the console indicating line number (and more).
Easiest way to write JavaScript is with Firefox + Firebug. Test with IE and have Opera tell you what is breaking when it does.
What browser are you using? IE8 has great build-in feature to debug javascript, for Firefox, Firebug is great.
Checking that the values passed into functions are correct and throwing your own errors if they aren't will help you track down problems faster.
Safari 4 (which runs on both Mac OS X and Windows) comes with some development tools (including a debugger) that are very useful. If you prefer using Firefox, Firebug provides similar functionality.
JSLint can help you track down simple errors.
Steve