I can open the Chrome DevTools console for this URL: https://www.google.com/ and enter the following command to print "Hello world!" to the console:
console.log("Hello world!")
However, when I attempt to use the same command for this URL: https://svc.mt.gov/dor/property/prc my message isn't printed in the console. Why is that?
Is there any way to force the console to work for this MT website?
I've tried using python/selenium to open the page and execute_script() to issue the command, but that hasn't worked either.
If you do
console.dir(console.log)
and click on the [[FunctionLocation]], you'll see the following in the site's source code:
"Debug" != e && (window.console.log = function() {}
)
Seems like a cheap (but lazy?) way to suppress logging on production.
One way to fix it, kinda, would be to use one of the many other console commands. (console.dir, or console.error, if you want)
If you really want the original console.log to work again, the only way to do that would be to run code before the page code runs, so that you can save a reference to the function. For example, with a userscript:
// <metadata block...>
// #grant none
// ==/UserScript==
const origConsoleLog = console.log;
// set original window.console.log back to its original
// after the page loads
setTimeout(() => {
window.console.log = origConsoleLog;
}, 2000);
// there are more elegant but more complicated approaches too
CertainPerformance already explained how this is possible and what the reason for suppressing the log seems to be. I'm going to show here another method to get back console.log after the original has been lost.
document.body.appendChild(document.createElement('IFRAME')).onload = function () {
this.contentWindow.console.log('Hello, World!');
this.remove();
};
This basically uses an old method of restoring global objects from a temporary iframe.
I prototyped Function so that it has a getBody function:
Function.prototype.getBody = function() {
// Get content between first { and last }
var m = this.toString().match(/\{([\s\S]*)\}/m)[1];
// Strip comments
return m.replace(/^\s*\/\/.*$/mg,'');
};
See here for more info.
I tried to test it this way:
console.log(console.log.getBody.getBody());
but received an error: TypeError: console.log.getBody is undefined.
I figured out that maybe this happens because console.log was defined before I actually prototyped Function so I created an empty function x right before the prototyping and tried to call
console.log(x.getBody.getBody());
which worked without a problem. Checking the type of console.log with typeof console.log results in "function". Here's a CodePen to try it out. All of this wasn't really a surprise since it's what I expected except of console.log.getBody to be undefined.
So why does prototyping Function not affect console.log? I'm using Firefox 18.0.1 with Firebug 1.11.1.
This seems to be an issue with Firebug not with Firefox per se. My guess is that Function in Firebug lives in a different scope then Function in your page. (since unlike the other browsers Firebug is an extension , not a built in browser tool)
In fact if instead of Firebug you use the built in Firefox console (Ctrl+Shift+K), your code works perfectly fine.
More information about Firebug internals can be found here
http://getfirebug.com/wiki/index.php/Firebug_Internals
This excerpt may be interesting
When Firebug is detached from Firefox, open in a new or separate
window, the new window has its own scope. In that scope, a few Firebug
script tags compile to create a connection back to the original
browser.xul window. Most important, chrome.js is unique to each top
level window, but the Firebug object used by the detached window is
the object of the parent browser.xul.
Note: Firebug being Firebug extension and/or Webkit developer tools.
With the faking of calling file I mean the link at the right side of the console output, pointing to the location where the output function (like console.log) is called.
This becomes a problem when you have unified handler for error messaging etc, thus all the console.log calls originate from the same file & linenumber.
Is there any way to fake this information? Or bake such link (pointing to line number) into the firebug console log (providing one has the stacktrace)? Just adding the filename and line number to the end of any log adds noise to the console output, making it messy.
Most modern browsers define a console.log function. How about instead of writing your own error handler, you go ahead and call console.log everywhere you have an error. Then, for the browsers that do not define console.log, you can define it yourself using whatever you want. For instance, if you wanted to alert the error in IE (or FF without firebug installed.. etc) you could use this code:
<html>
<head>
<title>Test</title>
</head>
<body>
<button onclick="throwError()">
Throw Error</button>
<script type="text/javascript">
function throwError() {
console.log("error here!");
}
if (!window.console) {
window.console = {
log: function(e) {
alert(e);
}
};
}
//Added in EDIT: in production add these lines below to overwrite browser's console.log function
window.console.log = function(e) {
alert("production alert: " + e); //or whatever custom error logging you want
};
</script>
</body>
</html>
You can add whatever you want to the console object. I've tested this in IE8 and Firefox, and I'm fairly confident you can make this idea work for whatever set of browsers you support.
EDIT: Looks like you can also overwrite the default console.log function in Firefox, Safari, and Chrome. Just remap the log member of the console object to a new function that does whatever you want while in production.
Taking a brief trawl on the firebug forums it seems to imply that it (sometimes?) looks at the exception to determine what the line number is.
So you may well be able to fake it that way by judicious massaging.
With Firebug there is an option to show the call stack alongside errors.
Click on the down arrow next to the console tab's name to see and activate it.
It causes a 'plus' icon to show to the left of the message, which reveals the stack.
This might get you closer the code that caused the error.
If you will also need to log errors with console.error() to make use of this.
(not sure how compatible this is with chrome though)
I have a bunch of console.log() calls in my JavaScript.
Should I comment them out before I deploy to production?
I'd like to just leave them there, so I don't have to go to the trouble of re-adding the comments later on if I need to do any more debugging. Is this a bad idea?
It will cause Javascript errors, terminating the execution of the block of Javascript containing the error.
You could, however, define a dummy function that's a no-op when Firebug is not active:
if(typeof console === "undefined") {
console = { log: function() { } };
}
If you use any methods other than log, you would need to stub out those as well.
As others have already pointed it, leaving it in will cause errors in some browsers, but those errors can be worked around by putting in some stubs.
However, I would not only comment them out, but outright remove those lines. It just seems sloppy to do otherwise. Perhaps I'm being pedantic, but I don't think that "production" code should include "debug" code at all, even in commented form. If you leave comments in at all, those comments should describe what the code is doing, or the reasoning behind it--not blocks of disabled code. (Although, most comments should be removed automatically by your minification process. You are minimizing, right?)
Also, in several years of working with JavaScript, I can't recall ever coming back to a function and saying "Gee, I wish I'd left those console.logs in place here!" In general, when I am "done" with working on a function, and later have to come back to it, I'm coming back to fix some other problem. Whatever that new problem is, if the console.logs from a previous round of work could have been helpful, then I'd have spotted the problem the first time. In other words, if I come back to something, I'm not likely to need exactly the same debug information as I needed on previous occasions.
Just my two cents... Good luck!
Update after 13 years
I've changed my mind, and now agree with the comments that have accumulated on this answer over the years.
Some log messages provide long-term value to an application, even a client-side JavaScript application, and should be left in.
Other log messages are low-value noise and should be removed, or else they will drown out the high-value messages.
If you have a deployment script, you can use it to strip out the calls to console.log (and minify the file).
While you're at it, you can throw your JS through JSLint and log the violations for inspection (or prevent the deployment).
This is a great example of why you want to automate your deployment. If your process allows you to publish a js file with console.logs in it, at some point you will do it.
To my knowledge there is no shorter method of stubbing out console.log than the following 45 characters:
window.console||(console={log:function(){}});
That's the first of 3 different versions depending on which console methods you want to stub out all of them are tiny and all have been tested in IE6+ and modern browsers.
The other two versions cover varying other console methods. One covers the four basics and the other covers all known console methods for firebug and webkit. Again, in the tiniest file sizes possible.
That project is on github: https://github.com/andyet/ConsoleDummy.js
If you can think of any way to minimize the code further, contributions are welcomed.
-- EDIT -- May 16, 2012
I've since improved on this code. It's still tiny but adds the ability to turn the console output on and off: https://github.com/HenrikJoreteg/andlog
It was featured on The Changelog Show
You should at least create a dummy console.log if the object doesn't exist so your code won't throw errors on users' machines without firebug installed.
Another possibility would be to trigger logging only in 'debug mode', ie if a certain flag is set:
if(_debug) console.log('foo');
_debug && console.log('foo');
Hope it helps someone--I wrote a wrapper for it a while back, its slightly more flexible than the accepted solution.
Obviously, if you use other methods such as console.info etc, you can replicate the effect. when done with your staging environment, simply change the default C.debug to false for production and you won't have to change any other code / take lines out etc. Very easy to come back to and debug later on.
var C = {
// console wrapper
debug: true, // global debug on|off
quietDismiss: false, // may want to just drop, or alert instead
log: function() {
if (!C.debug) return false;
if (typeof console == 'object' && typeof console.log != "undefined") {
console.log.apply(this, arguments);
}
else {
if (!C.quietDismiss) {
var result = "";
for (var i = 0, l = arguments.length; i < l; i++)
result += arguments[i] + " ("+typeof arguments[i]+") ";
alert(result);
}
}
}
}; // end console wrapper.
// example data and object
var foo = "foo", bar = document.getElementById("divImage");
C.log(foo, bar);
// to surpress alerts on IE w/o a console:
C.quietDismiss = true;
C.log("this won't show if no console");
// to disable console completely everywhere:
C.debug = false;
C.log("this won't show ever");
this seems to work for me...
if (!window.console) {
window.console = {
log: function () {},
group: function () {},
error: function () {},
warn: function () {},
groupEnd: function () {}
};
}
Figured I would share a different perspective. Leaving this type of output visible to the outside world in a PCI application makes you non-compliant.
I agree that the console stub is a good approach. I've tried various console plugins, code snippets, including some fairly complex ones. They all had some problem in at least one browser, so I ended up going with something simple like below, which is an amalgamation of other snippets I've seen and some suggestions from the YUI team. It appears to function in IE8+, Firefox, Chrome and Safari (for Windows).
// To disable logging when posting a production release, just change this to false.
var debugMode = false;
// Support logging to console in all browsers even if the console is disabled.
var log = function (msg) {
debugMode && window.console && console.log ? console.log(msg) : null;
};
Note: It supports disabling logging to the console via a flag. Perhaps you could automate this via build scripts too. Alternatively, you could expose UI or some other mechanism to flip this flag at run time. You can get much more sophisticated of course, with logging levels, ajax submission of logs based on log threshold (e.g. all Error level statements are transmitted to the server for storage there etc.).
Many of these threads/questions around logging seem to think of log statements as debug code and not code instrumentation. Hence the desire to remove the log statements. Instrumentation is extremely useful when an application is in the wild and it's no longer as easy to attach a debugger or information is fed to you from a user or via support. You should never log anything sensitive, regardless of where it's been logged to so privacy/security should not be compromised. Once you think of the logging as instrumentation it now becomes production code and should be written to the same standard.
With applications using ever more complex javascript I think instrumentation is critical.
As other have mentions it will thrown an error in most browsers. In Firefox 4 it won't throw an error, the message is logged in the web developer console (new in Firefox 4).
One workaround to such mistakes that I really liked was de&&bug:
var de = true;
var bug = function() { console.log.apply(this, arguments); }
// within code
de&&bug(someObject);
A nice one-liner:
(!console) ? console.log=function(){} : console.log('Logging is supported.');
Yes, it's bad idea to let them running always in production.
What you can do is you can use console.debug which will console ONLY when the debugger is opened.
https://developer.mozilla.org/en-US/docs/Web/API/console/debug
I am using a javascript called 'Facelift 1.2' in one of my websites and while the script works in Safari 3, 4b and Opera, OmniWeb and Firefox it does not in any IE version.
But even in the working browser i get the following error I cannot decipher.
Maybe in due time—with more experience in things Javascript—I will be able to but for now I thought I would ask some of you, here at SO.
The following is the error popup i get in IETester testing the page for Interet Explorer 6,7 and 8:
The following is from the Firebug console in Firefox 3.0.6:
The website is: http://www.457cc.co.nz/index.php In case it helps you see the problem mentioned in action.
I have also looked up what line 620 corresponds to which is:
"line 76" is:
this.isCraptastic = (typeof document.body.style.maxHeight=='undefined');
which is part of this block of code (taken from the flir.js):
// either (options Object, fstyle FLIRStyle Object) or (fstyle FLIRStyle Object)
,init: function(options, fstyle) { // or options for flir style
if(this.isFStyle(options)) { // (fstyle FLIRStyle Object)
this.defaultStyle = options;
}else { // [options Object, fstyle FLIRStyle Object]
if(typeof options != 'undefined')
this.loadOptions(options);
if(typeof fstyle == 'undefined') {
this.defaultStyle = new FLIRStyle();
}else {
if(this.isFStyle(fstyle))
this.defaultStyle = fstyle;
else
this.defaultStyle = new FLIRStyle(fstyle);
}
}
this.calcDPI();
if(this.options.findEmbededFonts)
this.discoverEmbededFonts();
this.isIE = (navigator.userAgent.toLowerCase().indexOf('msie')>-1 && navigator.userAgent.toLowerCase().indexOf('opera')<0);
this.isCraptastic = (typeof document.body.style.maxHeight=='undefined');
if(this.isIE) {
this.flirIERepObj = [];
this.flirIEHovEls = [];
this.flirIEHovStyles = [];
}
}
The whole script is also available on my server: http://www.457cc.co.nz/facelift-1.2/flir.js
I just don't know where to start looking for the error, especially since it only affects IE but works in the rest. Maybe you guys have an idea. I would love to hear them.
Thanks for reading.
Jannis
PS: This is what Opera's error console reports:
JavaScript - http://www.457cc.co.nz/index.php
Inline script thread
Error:
name: TypeError
message: Statement on line 620: Cannot convert undefined or null to Object
Backtrace:
Line 620 of linked script http://www.457cc.co.nz/facelift-1.2/flir.js
document.body.appendChild(test);
Line 70 of linked script http://www.457cc.co.nz/facelift-1.2/flir.js
this.calcDPI();
Line 2 of inline#1 script in http://www.457cc.co.nz/index.php
FLIR.init();
stacktrace: n/a; see 'opera:config#UserPrefs|Exceptions Have Stacktrace'
I agree with tvanfosson - the reason you're getting that error is quite likely because you're calling init() before the page is done loading, so document.body is not yet defined.
In the page you linked, you should move the following code to the bottom of the page (just before the closing html tag:
<script type="text/javascript">
FLIR.init({ path: 'http://www.457cc.co.nz/facelift-1.2/' });
FLIR.auto();
</script>
Even better, you should attach the initialization to the document's ready event. If you do it this way, there is no need to even move your javascript to the bottom of the file. Using jquery:
$(document).ready( function(){
FLIR.init({ path: 'http://www.457cc.co.nz/facelift-1.2/' });
FLIR.auto();
});
More on jquery's document.ready event »
Edit Answer left for context. See #Triptych's (accepted) answer for the correct resolution.
My suggestion is to move the inclusion of the javascript to the end of your mark up. I think what is happening is that the code is executing before the DOM is completely loaded and thus the document.body is null when you try to reference it in determining the maxHeight style property. Moving the inclusion of the javascript to the end of your markup should be enough to guarantee that the body of the document is loaded at least and avoid this particular error.
... rest of html....
<script type='text/javascript'
src='http://www.457cc.co.nz/facelift/flir.js'>
</script>
</body>
</html>
Install .net Framework v2 and solve the problem.