I work on a relatively huge ECMAScript codebase (> 60,000 LOC) and we tend to struggle a bit with detecting errors for our dreaded friend Internet Explorer (especially 6 and 7).
At the moment, I've been stuck with an issue for 3 days where my RIA renders fine in Google Chrome, Firefox 3.6, Opera and Internet Explorer 8, but fails when running Internet Explorer 8 in IE7-Mode (or with a real IE-7).
My question really is: how do you do to identify code that will produce an error in IE7?
Usually I rely on JSLint and I tend to catch the usual suspects (trailing commas, I loathe you), but in this particular case I have just re-run a linter on all my code, both source and minimized, and it doesn't yield my usual suspects. So I guess I have mistakenly introduced something that IE doesn't like (who knows, maybe I got crazy and used Array.map instead of dojo.map somewhere?) and it blows up in my face, producing nice error messages that don't help me at all ("[object object]" and " is null" where it shouldn't be, so I assume there was an error up-stream that failed silently and prevented this object from being created).
I've tried having a look at the Google Closure Linter but it doesn't yield anything special, and I don't think that the Google Closure Compiler is going to be my savior either. is there any tool (command-line, web-service or other) that can parse/run code as if it were emulating IE so we can get the appropriate errors?
Any tips are appreciated.
EDIT: Thank you for your help in trying to solve my issue so far, but what I am really just asking is if there are tools that do this sort of checks, meaning validating a feature set and syntax against a particular browser. This is the sort of thing severly lacking in the JS-world in my opinion (not so much for FF or Chrome, obviously as their debuggers are a bit more helpful).
EDIT2: I eventually found the root of my problem today (after 3 days) by going through all my code changes between two branches and realizing that the problem was actually already there but never detected before and going back through even older changes to narrow down the mess and eventually end up adding console logs everywhere until I reached a point of failure (God thank emacs for its regular expression support to add logs to every single line... heavy but works...). Fun fact though: IE swallowed an error message supposed to be displayed in the try catch block originally catching the source problem and then re-throwing it. Still don't why, but if it hadn't then that would have been a lot easier to find, as it was intended for that purpose in case it broke. Weird. Might not like deep-levels of re-throw.
I'll leave the question open as for now there are no answer to the actual question.
You might try the IE8 debugger, as #galambalazs suggests; the old debugger from the IE6 era was generally not useful.
The low-level technique I've always used is to add my own try/catch blocks around large portions of the my Javascript source to narrow down the source of error. By iteratively adjusting your try/catch blocks you can do a "binary search" through your source to locate the code that's causing an exception. What you'll probably find is that there's some code that's harmless in Firefox but which IE's interpreter considers an error. (To be fair, it's usually the case that IE's strictness is justified, and that the lax behavior of Firefox is really undesirable.)
So in other words, you'd start on a Javascript source that you suspect, or perhaps you'd do this to all of your included .js files:
// top of Javascript source file foo.js
try {
// ... all the code ...
} catch (x) { alert("Error in foo.js: " + x); }
Now, if you load the page and get that alert, then you know that the error is somewhere in foo.js. Thus, you split it in half:
// top of foo.js
try {
// ... half the code, roughly ...
}
catch (x) { alert("Error in first half of foo.js: " + x); }
try {
// ... the rest of the code ...
} catch (x) { alert("Error in second half of foo.js: " + x); }
Repeat that process and you'll eventually find the problem.
You may try Microsoft Script Debugger, or Internet Explorer Developer Tools.
For complete list of what may be different in IE 8 from the older version consult with:
Internet Explorer 8 Readiness Toolkit (offical list)
especially DOM Improvements
JavaScript in Internet Explorer 8 (John Resig's post)
Also see Web Bug Track for possible quirks.
As a final note, doing console.log on every line may help you to find a particular bug in a hard way, but considering the amount of code you should really write unit test for modules. That's the only way you can make sure that your application will actually run with different inputs and conditions.
Related
We have a big single page application, that started to crash from time to time. We were trying to debug it for a while now, but unfortunately, still no results. We used traditional debugging tools, but they were not very useful - perhaps not used correctly.
The app seems to crash most often on Safari, it doesn't crash that often in Chrome, but it still does, so I can't rule out a problem with browser(s).
I have managed to get this crash report, which you can find at the end of this question, unfortunately I don't know what to look for in it. I know it's huge and I'm just throwing it at you saying "here, find a bug", but could you possibly have a look at it and give me some hint what might be wrong or what should I focus on in the report?
Here is the crash report http://pastebin.com/bNxpuS6T
Thanks
What I can see from the crash report and the source code is that your JavaScript code was trying to destroy some DOM objects while still iterating through those, which is the reason of the crash.
I guess you may want to check if any timer associated with the idle tabs is still active.
DETAILS:
The WebKit crashed at
1 com.apple.WebCore 0x00007fff83cace2d WebCore::ScriptExecutionContext::willDestroyActiveDOMObject(WebCore::ActiveDOMObject*) + 45
where the source code is (click here)
void ScriptExecutionContext::willDestroyActiveDOMObject(ActiveDOMObject* object)
{
ASSERT(object);
if (m_iteratingActiveDOMObjects)
CRASH();
m_activeDOMObjects.remove(object);
}
Is there a way to tell a page/project this it should ignore some javascript code/file? I am working on a project, that works well on all browsers, eccept IE8. I haven't tested for less than IE8, and I wont bother. Anyway. The error that I am getting is my language, but I'll translate to English.
Exception was thrown at line 4, column 12204 in https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js
0x800a01b6 - A javascript runtime error occured: The object doesn't support the property or method 'getElementsByClassName'
If there is a handler for this exception, the program may be safely continued
This is just one of MANY errors like that.
And many more.
This is a huge problem for me. Is there any workaround for this? I am forced to keep this file, since the project is big, and other pages depend on this file
You could try replacing this line...
getElementsByClassName("classname")
with...
$(".classname")
I ran into this problem today in IE6 (but is reproducible on all recent version of IE).
I noticed quite a few people run into this problem and I haven't seen a very practical way to fix this.
There seems to be some other solution floating about regarding the order of script tags and meta tags in the head of the HTML document. I haven't confirm this but here's a link anyway:
What causes the error "Can't execute code from a freed script"
I also know the solution to this problem so I'm posting it below
First of all you need to locate the source of the message.
IE is known for it's abysmal error reporting but luckily IE9 seems somewhat capable. If this bug occurs in IE6, IE7 or IE8 it will also occur in IE9, so use IE9 to debug (for your sanity)
Open the webdeveloper console in IE9 (press F12) and run through the steps to produce this error.
IE9 should now give you a file and line indication on the console, yay!
What typically goes wrong is a callback that is executed after some delay, either by setTimeout or because of an Ajax request. If the window, document or frame the callback is defined in got unloaded then you will get this message when it tries to execute your callback function.
Seemingly other browsers ignore this problem, which is fine I guess. To make IE do the same just wrap the callback in a try-catch block (I don't know what the callback would evaluate to, I don't think it evaluates to undefined). If you want have more precise error handling or if you actually want to take action when this occurs you can probably do so and please make a post here because I'm curious as to what kind of use case would actually require this.
If you have page that uses several Frames, this error might be caused by objects initialized in one frame being used in some other frame after the initial frame was removed from the page.
When that happens, then depending on situation, you might want to:
Review your code looking for potential memory leaks
If those object represent some data you do actually want passed between frames, then consider using their stringified form instead.
The solution - be sure to place all META statements BEFORE any script statements.
Where I work, all our JavaScript is run through a compiler before it's deployed for production release. One of the things this JavaScript compiler does (beside do things like minify), is look for lines of code that appear like this, and strip them out of the release versions of our JavaScript:
//#debug
alert("this line of code will not make it into the release build")
//#/debug
I haven't look around much but I have yet to see this //#debug directive used in any of our JavaScript.
What is it's possible usefulness? I fail to see why this could ever be a good idea and think #debug directives (whether in a language like C# or JavaScript) are generally a sign of bad programming.
Was that just a waste of time adding the functionality for //#debug or what?
If you were using a big JavaScript library like YUI that has a logger in it, it could only log debug messages when in debug mode, for performance.
Since it is a proprietary solution, we can only guess the reasons. A lot of browsers provide a console object to log various types of messages such as debug, error, etc.
You could write a custom console object is always disabled in production mode. However, the log statements will still be present, but just in a disabled state.
By having the source go though a compiler such as yours, these statements can be stripped out which will reduce the byte size of the final output.
Think of it as being equivalent to something like this:
// in a header somewhere...
// debug is off by default unless turned on at compile time
#ifndef DEBUG
#define DEBUG 0
#endif
// in your code...
var response = getSomeData({foo:1, bar:2});
#if DEBUG
console.log(response);
#endif
doStuffWith(response);
This kind of thing is perfectly acceptable in compiled languages, so why not in (preprocessed) javascript?
I think it was useful (perhaps extremely useful) back a few years, and was probably the easiest way for a majority of developers to know what was going on in their JavaScript. That was because IDE's and other tools either weren't mature enough or as widespread in their use.
I work primarily in the Microsoft stack (so I am not as familiar with other environments), but with tools like VS2008/VS2010, Fiddler and IE8's (ugh! - years behind FF) dev tools and FF tools like firebug/hammerhead/yslow/etc., peppering alerts in your JavaScript isn't really necessary anymore for debugging. (There's probably a few instances where it's useful - but not nearly as much now.) Able to step through JavaScript, inspect requests/responses, and modify on the fly really makes debugging alert statements almost obsolete.
So, the //#debug was useful - probably not so much now.
I've used following self-made stuf:
// Uncomment to enable debug messages
// var debug = true;
function ShowDebugMessage(message) {
if (debug) {
alert(message);
}
}
So when you've declared variable debug which is set to true - all ShowDebugMessage() calls would call alert() as well. So just use it in a code and forget about in place conditions like ifdef or manual commenting of the debug output lines.
For custom projects without any specific overridden console.
I would recommend using: https://github.com/sunnykgupta/jsLogger , it is authored by me.
Features:
It safely overrides the console.log. Takes care if the console is not available (oh yes, you need to factor that too.)
Stores all logs (even if they are suppressed) for later retrieval.
Handles major console functions like log, warn, error, info.
Is open for modifications and will be updated whenever new suggestions come up.
When a javascript error occures in IE (or in other browsers) you get a popup saying that javascript error has occurred - usually this comes with a line number and some hint.
Sometimes it comes with line 0 and with no way of knowing what the problem is.
Javscript can come from HTML itself, from a js file or from JSP (and more).
Microsoft has a script debugger that helps a lot in finding where js errors are, however sometimes when a js error occurs the script debugger cannot find the code portion and thus its difficult of finding where is the root cause of the problem.
My question is whether anyone knows any way of making script debugger find the code any way (mostly happen with js code that is in JSP file), or at least include in the IE popup the method or js file where the error has occurred. (it only display the line number, and many times its line 0...).
Thanks,
Tal.
The error object which is created when an error is thrown by JavaScript is very unreliable when it comes to the source line, especially within IE. Browsers like Firefox and Safari are better at line numbers, but they are generally pointless due to minification of the files.
What is obviously of more use is getting the call stack, but due to the anonymous nature of JavaScript functions (well, that they can be anonymous) a call stack can often be hard to work out.
If you're doing a try/ catch you can do arguments.callee which will return you the method which called the current method which failed.
Here's a good example of doing a complete stack in JavaScript - http://eriwen.com/javascript/js-stack-trace/
Also developer tools included with Internet Explorer 8 is something good to trace and debug your javascript code
There is a version of Firebug called Firebug Lite that will work with Internet Explorer. It's performance is going to be based on how complex your pages are; however, for relatively lightweight pages, it should provide some insight.
I recommend this tool rather than simply using Firebug and Firefox because not all errors that occur in Internet Explorer will occur in Firefox, and so performing any debugging in that browser may not yield any results.
Firebug on Firefox is usually considered one of the best debugging tools.
On Firefox, go to
http://getfirebug.com
to get it.
This will print you a stack trace:
function Stack()
{
try
{
throw Error()
}
catch(ex)
{
return ex.stack
}
};
print( Stack() );
If all else fails (and when dealing with IE it sometimes does) you can always walk through your code with alerts. It's crude and tedious, but sometimes it's all you can do:
Simply:
var count = 0;
then sprinkle some:
alert(count++);
at strategic lines along your code and note where it stops alerting.
Lather rinse repeat until you have your line.
If using Firefox you can press Ctrl + Shift + J to bring up the JavaScript error console that is built into Firefox, which will tell you exactly what went wrong.