I checked my index.php and removed all the console.log() but when I go to IE7 I am still getting console errors. The funny thing is if I check the in IE9 and then change the browser mode to IE7 it works fine, however if test the site straight into an IE7 browser it gives a console error message.
Any idea on how to stop this please?
You probably missed a console.log call somewhere. The reason why it works in IE9 switching to IE7 is that the console object is created as soon as you open the console to switch the version. Thus no error will be thrown in the IE7 emulation mode of IE9.
The better solution is to include the following in your js-code beforehand:
if (!window.console){console = {log:function(){}};}
Now all your console.log calls won't throw an error but will be silently ignored.
I do the following when developing:
var logging = 1;
if (!window.console){console = {log:function(){}};}
function _log(a) { if(logging) { console.log(a); } }
and keep on using _log("foo") for the entire code. Now you can switch logging with a simple logging = 0 and are safe against the missing console object.
Related
Just doing some JavaScript stuff in google chrome (don't want to try in other browsers for now, in case this is really doing real damage) and I'm not sure why this seemed to break my console.
>var x = "http://www.foo.bar/q?name=%%this%%";
<undefined
>x
After x (and enter) the console stops working... I restarted chrome and now when I do a simple
console.clear();
It's giving me
Console was cleared
And not clearing the console. Now in my scripts console.log's do not register and I'm wondering what is going on. 99% sure it has to do with the double percent signs (%%).
Anyone know what I did wrong or better yet, how to fix the console?
A bug report for this issue has been filed here.
Edit: Feeling pretty dumb, but I had Preserve log checked... That's why the console wasn't clearing.
As discussed in the comments, there are actually many different ways of constructing a string that causes this issue, and it is not necessary for there to be two percent signs in most cases.
http://example.com/%
http://%%%
http://ab%
http://%ab
http://%zz
However, it's not just the presence of a percent sign that breaks the Chrome console, as when we enter the following well-formed URL, the console continues to work properly and produces a clickable link.
http://ab%20cd
Additionally, the strings http://%, and http://%% will also print properly, since Chrome will not auto-link a URL-link string unless the http:// is followed by at least 3 characters.
From here I hypothesized that the issue must be in the process of linking a URL string in the console, likely in the process of decoding a malformed URL. I remembered that the JavaScript function decodeURI will throw an exception if given a malformed URL, and since Chrome's developer tools are largely written in JavaScript, could this be the issue that is evidently crashing the developer console?
To test this theory, I ran Chrome by the command link, to see if any errors were being logged.
Indeed, the same error you would see if you ran decodeURI on a malformed URL (i.e. decodeURI('http://example.com/%')) was being printed to the console:
[4810:1287:0107/164725:ERROR:CONSOLE(683)] "Uncaught URIError: URI malformed", source: chrome-devtools://devtools/bundled/devtools.js (683)
So, I opened the URL chrome-devtools://devtools/bundled/devtools.js in Chrome, and on line 683, I found the following.
{var parsedURL=new WebInspector.ParsedURL(decodeURI(url));var origin;var folderPath;var name;if(parsedURL.isValid){origin=parsedURL.scheme+"://"+parsedURL.host;if(parsedURL.port)
As we can see, decodeURI(url) is being called on the URL without any error checking, thus throwing the exception and crashing the developer console.
A real fix for this issue will come from adding error handling to the Chrome console code, but in the meantime, one way to avoid the issue would be to wrap the string in a complex data type like an array to prevent parsing when logging.
var x = "http://example.com/%";
console.log([x]);
Thankfully, the broken console issue does not persist once the tab is closed, and will not affect other tabs.
Update:
Apparently, the issue can persist across tabs and restarts if Preserve Log is checked. Uncheck this if you are having this issue.
Update 2:
As of Chrome 40, this issue is fixed.
Currently I use manual workaround like binary search: "delete half of potentially invalid code, check whatever extension loads, repeat for other half, repeat for potentially invalid code".
setting dom.report_all_js_exceptions to true described in How to detect syntax errors when debugging Firefox extensions failed to change anything.
It's a Bug 986689 in v30 and newer.
For now I'm using older version of Firefox. v29 seems to be the latest that still shows the errors.
Another possible solution is to use
try
{
//code here
}
catch(ex)
{
//error captured
dump(ex)
}
and output in console ex in catch (although it won't help with syntax errors)
Javascript on a page in Internet Explorer (8 and 9) with Developer Tools open reaches console.log(), which is defined - but nothing appears in the actual log.
Things tried:
Double-checking with alert()s that console is defined and that console.log is a function.
Checking with alert()s before and after that the code does reach the console.log() line,
Checking code for any IE fallbacks like if(ie){console={log:function(){}}}, removing links to libraries and checking code snippets for mentions of console
Checking IE's settings and enabling anything relating to debugging
Checking that IE isn't broken by loading a 3rd party page with console.log()s (e.g. http://jsbin.com logs "init" and "runner")
Swapping console for window.console
So the console is there and active, but no console messages show up in the actual console (on either the Script tab or the Console tab).
What else could stop console.log() from actually logging anything, even when Developer Tools is open and console.log is a defined function?
The culprit in this case turned out to be, of all things, firebug lite.
My test dev pages often include this to (ironically) aid certain types of debugging in IE:
<!--[if IE]>
<script type="text/javascript" src="https://getfirebug.com/firebug-lite.js"></script>
<![endif]-->
Since it appears in text editors as a comment, it's easy to accidentally overlook.
Alerting alert(console.log); before and after shows firebug lite changes the console.log function from the native code to this:
function(){return f.apply(c,arguments)}
...which for some reason (at the moment, here) then does nothing.
Without Firebug Lite getting involved, alert(console.log); in IE gives this:
function log() {
[native code]
}
...and does its usual trick of logging if f12 Dev Tools is open and crashing if it isn't.
I'm truly stumped by this problem.
I've got some JavaScript to control a product configurator.
A simple bit of code to select some defaults
works fine in Chrome
works fine in IE
doesn't work in Firefox (newest versions of everything)
However, if I do anything to observe the code in FF it works fine.
If I have it alert anything relevant, it works.
If I log anything relevant, it works, but only if the console is actually open so I can see the log. If the console isn't open, doesn't work.
for(type in radio_groups) {
if_checked = !!$(":radio[name="+type+"]:checked").length;
console.log($('.'+type).not('[class*="unavailable"]'));
//This loop doesnt do anything without this log above
alert($('.'+type).not('[class*="unavailable"]'));
// Or this alert.
var t = $('.'+type).not('[class*="unavailable"]');
// Line above doesn't make stuff work.
if(!if_checked)
$('.'+type).not('[class*="unavailable"]').first().click();
}
if_checked is false for every type, I can verify that when it runs.
However, nothing happens.
No buttons are clicked.
This is plain single threaded JS in a browser.
There's no interval/timeout functions on the page.
I can do time arbitrary time consuming tasks before the last line (my best idea was that it was a concurrency issue somehow, I don't see how else logging could affect anything) and it doesn't have any effect.
I can run the same selector and put it in a string, or do anything you can think of to it besides logging or alerting and it wont work; no buttons get clicked. Only actively observing whats happening makes the code work. The entire deal is rather involved and I cant provide the entire thing.
Any ideas on how:
logging can possibly affect the outcome of a simple click event?
why this is Firefox specific? Or other ways I might try to see whats going wrong without the console or alerts?
Edit: Oh, and I've had two other people replicate the issue in their browsers (again, Firefox only), so its not some wonky extension issue unless we all share it.
Thanks.
This line is not valid:
var t = "$('.'+type).not('[class*="unavailable"]')";
It should probably be:
var t = "$('.'+type).not('[class*=\"unavailable\"]')";
or:
var t = $('.'+type).not('[class*="unavailable"]');
Here's a bit of speculation:
if_checked = !!$(":radio[name="+type+"]:checked").length;
It looks like the quotes aren't paired correctly. Did you mean this?
if_checked = !!$(":radio[name='"+type+"']:checked").length;
(See the single quotes that wrap the value of type?)
I've come across this before. If I'm leaving any logging in place in production code I'd wrap it in a try > catch statement.
try {
console.log("my log message")
} catch (err) { };
I know it's considered bad practice to have an empty 'catch' but hey, it's also bad practice to leave the logging in on priduction code.
It seems in FF (also in older IE) if the console is not open then it doesn't exist so the error being caught is probably something like 'console is undefined'
http://pastie.org/856698
Anyone have any idea why the script is causing this error?
Check your jQuery file to see if you don't have extra characters in there. That is the first referenced script and your error doesn't give a file.
UPDATE:
I'm not getting any errors on your site in IE8 until I press submit. Then it tells me regSubmit() is not an object, and indeed it isn't, your function is called submitReg(). Perhaps the reason you are getting errors "in IE" is simply because without a debugger loaded, non-IE browsers tend to just skip errors, whereas IE stops processing and puts up a notification.
Try installing Firebug or using Chrome, CTRL+SHIFT+J and watch and see if you get errors there now (you will if you watch the console, but processing will continue anyway).