I have a development site which seems to have an intermittent Javascript error in IE7. Now I can fully test IE7, but I was wondering if there is a resource that would allow me to analyze the Javascript for possible browser issues.
You can try running your javascript through JSLint
A common IE-only problem is the inclusion of closing commas in array or object literals. Non-IE browsers handle this fine.
Are you generating any array or object literals via a JSON response or similar?
Eg
a = [1,2,4,]; // error in IE, not in other browsers
b = {a: 1, b: 2,}; // also error in IE
Look for any code that runs as the page loads.
ex:
<script src = "test.js"></script>
test.js
document.getElementById("whatever");
Depending on the speed of the JS interpreter, you'll get a race condition with the loading of the script vs. the loading of the DOM. If the issue is "intermittent", this is almost certainly the problem. Stick everything that looks at the DOM in $(document).ready
You may wish to try using Selenium for scenario tests as well.
Related
I have developed a JS library that renders layouts (similar to layout rendering as in Razor View Engine in ASP.Net MVC). In order to display the final result, I replace the whole document by calling the document.write(...) function. For example:
document.open()
document.write(renderedLayout)
document.close()
I'm using this methods because I need all scripts whether defined by the developer or acquired from an external resource to be run and evaluated right after the content is replaced. That said, replacing the inner HTML of the html node will fail.
The methods I described works in Opera, Chrome, and Firefox but when I try to test it under IE and Edge, it fails and the browser does not showing anything once the write method is called.
My test shows that, all console outputs are received just before write is called and after that everything disappears.
Even though some may suggest that it could be a security measure in IE or Edge which might be solved by changing their configs, I would like to know how I can solve it using pure JavaScript so that my solution could be used in all major browsers.
I have traced and tested my code carefully, and I'm 100% sure the block of code I attached in the question is causing the blocking.
document.write writes to the document stream, calling document.write on a closed (loaded) document automatically calls document.open, which will clear the document.
removing document.open() and document.close() might help.
Next time when you are confused if your function written works on browser,
Open console(use ctrl+i or F12) - In Console place your Javascript code.
Here is the reference for you : https://developer.mozilla.org/en-US/docs/Web/API/Document/write
I've been doing some scraping and at some websites I found references to JS like this:
<script type="text/javascript">
unescape("%3Cscript src='Scriptdir/pr.asp?id=123456' language='javascript'%3E%3C/script%3E"));
</script>
In such cases, it is trivial to retrieve the script code (just go to the link). But how do I retrieve the code in cases like this:
<select ID="Spinner" class="text" onchange="javascript:IWantTheCodeOfThis();">
Is it even possible, or are they stored server-side without an acces for the client?
JavaScript is always stored server-side but executed client-side, so the browser has to get hold of it at some time (unlike to e.g. PHP-code).
What you posted is a JS-function-call so the function "IWantTheCodeOfThis" must be in one of the include-files which are "trivial to retrieve" :)
You could use Chrome or Safari to use the console and look at the resources. You could also type IWantTheCodeOfThis (without ()) in the console, and you will probably see the source code for the function.
Not at all. Any access to Javascript has to be on the client already.
To lookup where the function is located, it's a good idea to use a debugger like Firebug or the Chrome developer tools. Both explicitly show you all available javascript sources on the current site.
JavaScript is executed on the client side. Always.
IWantTheCodeOfThis() is a function that would be in one of the JavaScript downloaded by the browser. Most of the new browsers has some time of "inspector", "develop menu", or "developer tools" from which you can see all of the scripts that were loaded and even search them. Safari, Chrome and Internet Explorer 8/9 all have this. In Firefox, you can use Firebug.
You could go through the scripts by hand but that would be difficult as some websites may load some of their JavaScripts dynamically.
On the server lies a html file with javascript code included.
This javascript code includes a method called something like "CheckObject".
This file works for all users, except one specific (but important).
He gets a javascript error and in his browser sourcode appears something unbelievable:
The methodname "CheckObject" is replaced with "Check!==ect", means the "Obj" of the method name is replaced with !==.
Why could that be?
Hope anybody can help me!
Best regards
If he's using a browser that supports extensions (like Firefox, Chrome, and some others), it's probably worth disabling all of the extensions and seeing if the problem goes away.
If you haven't already, I'd completely clear his cache in case there was a bad page transfer once and the browser is reusing it.
I can't imagine how it would be happening reliably otherwise.
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.
I have an ASP.NET MVC project that uses some simple AJAX functionality through jQuery's $.get method like so:
$.get(myUrl, null, function(result) {
$('#myselector').html(result);
});
The amount of content is relatively low here -- usually a single div with a short blurb of text. Sometimes, however, I am also injecting some javascript into the page. At some point when I dynamically include script into content that was itself dynamically added to the page, the script still runs, but it ceases to be available to the debugger. In VS2008, any breakpoints are ignored, and when I use the "debugger" statement, I get a messagebox saying that "no source code is available at this location." This fails both for the VS2008 debugger and the Firebug debugger in Firefox. I have tried both including the script inline in my dynamic content and also referencing a separate js file from this dynamic content -- both ways seemed to result in script that's unavailable to the debugger.
So, my question is twofold:
Is there any way to help the debugger recognize the existence of this script?
If not, what's the best way to include scripts that are used infrequently and in dynamically generated content in a way that is accessible to the debuggers?
I can not comment yet, but I can maybe help answer. As qwerty said, firefox console can be the way to go. I'd recommend going full bar and getting firebug. It hasn't ever missed code in my 3 years using it.
You could also change the way the injected javascript is added and see if that effects the debugger you're using. (I take it you're using Microsoft's IDE?).
In any case, I find the best way to inject javascript for IE is to put it as an appendChild in the head. In the case that isn't viable, the eval function (I hate using it as much as you do) can be used. Here is my AJAX IE fixer code I use. I use it for safari too since it has similar behavior. If you need that too just change the browser condition check (document.all for IE, Safari is navigator.userAgent.toLowerCase() == 'safari';).
function execajaxscripts(obj){
if(document.all){
var scripts = obj.getElementsByTagName('script');
for(var i=0; i<scripts.length; i++){
eval(scripts[i].innerHTML);
}
}
}
I've never used jquery, I preferred prototype then dojo but... I take it that it would look something like this:
$.get(myUrl, null, function(result) {
$('#myselector').html(result);
execajaxscripts(result);
});
The one problem is, eval debug errors may not be caught since it creates another instance of the interpreter. But it is worth trying.. and otherwise. Use a different debugger :D
This might be a long shot, but I don't have access to IE right now to test.
Try naming the anonymous function, e.g.:
$.get(myUrl, null, function anon_temp1(result) {
$('#myselector').html(result);
});
I'm surprised firebug is not catching the 'debugger' statement. I've never had any problems no matter how complicated the JS including method was
If this is javascript embedded within dynmically generated HTML, I can see where that might be a problem since the debugger would not see it in the initial load. I am surprised that you could put it into a seperate .js file and the debugger still failed to see the function.
It seems you could define a function in a seperate static file, nominally "get_and_show" (or whatever, possibly nested in a namespace of sorts) with a parameter of myUrl, and then call the function from the HTML. Why won't that trip the breakpoint (did you try something like this -- the question is unclear as to whether the reference to the .js in the dynamic HTML was just a func call, or the actual script/load reference as well)? Be sure to first load the external script file from a "hard coded" reference in the HTML file? (view source on roboprogs.com/index.html -- loads .js files, then runs a text insertion func)
We use firebug for debug javascript, profile requests, throw logs, etc.
You can download from http://getfirebug.com/
If firebug don't show your javascript source, post some url to test your example case.
I hope I've been of any help!
If you add // # sourceURL=foo.js to the end of the script that you're injecting then it should show up in the list of scripts in firebug and webkit inspector.
jQuery could be patched to do this automatically, but the ticket was rejected.
Here's a related question: Is possible to debug dynamic loading JavaScript by some debugger like WebKit, FireBug or IE8 Developer Tool?