I am currently working on a website. For debugging reasons, i chose the view source option of firefox v3.6b4. Then i clicked on javascript link eg something like this from within the source page:
<script type="text/javascript" src="./dealer/dialog/jquery-1.3.2.min.js"></script>
Guess what, it showed me below message:
<HTML>
<HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD>
<BODY>
<H1>Not Found</H1>
The requested document was not found on this server.
<P>
<HR>
<ADDRESS>
Web Server at souq4cars.com
</ADDRESS>
</BODY>
</HTML>
<!--
- Unfortunately, Microsoft has added a clever new
- "feature" to Internet Explorer. If the text of
- an error's message is "too small", specifically
- less than 512 bytes, Internet Explorer returns
- its own error message. You can turn that off,
- but it's pretty tricky to find switch called
- "smart error messages". That means, of course,
- that short error messages are censored by default.
- IIS always returns error messages that are long
- enough to make Internet Explorer happy. The
- workaround is pretty simple: pad the error
- message with a big comment like this to push it
- over the five hundred and twelve bytes minimum.
- Of course, that's exactly what you're reading
- right now.
-->
What is happening there? I am unable to open the JS file !
Firefox showing a message about microsoft and IE !!!
The path to your JavaScript file is most likely incorrect.
Thus, you are (rightly) getting your provider's standard 404 error file.
That error file contains a comment in order to make it larger than 512 bytes.
That is, as the comment points out, because Internet Explorer does not display custom 404 error pages if they are smaller than 512 bytes (source). If they are smaller, it will display its built-in "the page you were looking for could not be found" message.
Correct the path to your JavaScript file and you should be fine.
Sadly, there is no automated mechanism that warns about Javascript files that were referenced to but could not be loaded (I still don't understand why - a browser that can throw Javascript errors could also complain about a missing file). Firebug's net tab is a great way of finding out whether a JavaScript file has been loaded or not, I can recommend that very much for development.
Most likely is that the server is rejecting requests to the URL without the expected HTTP REFERRER header. This will prevent people from grabbing files directly, rather than being referenced by the expected file.
Try to spoof the referring header and attempt to see if you get the same response.
It's either that or the JavaScript path does not actually exist, thus throwing a 404 error.
This message is just so that Internet Explorer will allow the massage through, instead of showing its own message. The "not found" message simply means that the document (website) you are trying to load has a bad file adress. That text is meaningless, it is only extra data in case you are using IE
Related
I am occasionally getting different types of Reference errors logged in chrome console.
For eg: require not defined
Cookies not defined
lozad not defined
The code is bundled in static-internal-bundle.js which is a combination of 7 different util files and minified using gulp-minify.
This error is coming mainly when the url is hit from paid.braintree.com Ad urls and has utm_source, utm_medium and utm_campaign as query parameters.
This error is not consistent and mostly does not reoccur if the site is refreshed.
Also, it has been logged in sentry for all types of devices and Os for over 1.5k times in 6 months. Though it gets logged in console, nothing seems to break on the webpage.
What could be the possible reasons for this type of error?
<script type="text/javascript" src="https://static.pens.com/576801d7b3a368c06ba1944c07fe260b970da596/build/static-internal-bundle.js"></script>
This is the script that gets added into the page in which the error is coming.
I would add this as a comment but StackO won't let me without 50+ rep... I'll edit as needed.
Possibly the error could be in using "require" on the browser side, as browsers do not implement require
This sounds like a problem I have had with Babel, if it is being used I would try updating.
I have a script that detects Javascript errors on my website and sends them to my backend for reporting. It reports the first error encountered, the supposed line number, and the time.
EDIT to include doctype:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" xmlns:fb="http://www.facebook.com/2008/fbml">
...
<script type="text/javascript">
//<![CDATA[
// for debugging javascript!
(function(window){
window.onerror = function(msg, url, ln) {
//transform errors
if (typeof(msg) === 'object' && msg.srcElement && msg.target) {
if(msg.srcElement == '[object HTMLScriptElement]' && msg.target == '[object HTMLScriptElement]'){
msg = 'Error loading script';
}else{
msg = 'Event Error - target:' + msg.target + ' srcElement:' + msg.srcElement;
}
}
msg = msg.toString();
//ignore errors
if(msg.indexOf("Location.toString") > -1){
return;
}
if(msg.indexOf("Error loading script") > -1){
return;
}
//report errors
window.onerror = function(){};
(new Image()).src = "/jserror.php?msg=" + encodeURIComponent(msg) + "&url=" + encodeURIComponent(url || document.location.toString().replace(/#.*$/, "")) + "&ln=" + parseInt(ln || 0) + "&r=" + (+new Date());
};
})(window);
//]]>
</script>
Because of this script, I'm acutely aware of any javascript errors that are happening on my site. One of by biggest offenders is "Script Error." on line 0. in Chrome 10+, and Firefox 3+. This error doesn't exist (or may be called something else?) in Internet Explorer.
Correction (5/23/2013): This "Script Error, Line 0" error is now showing up in IE7 and possibly other versions of IE. Possibly a result of a recent IE security patch as this behavior previously did not exist.
Does anyone have any idea what this error means or what causes it? It happens on about 0.25% of my overall pageloads, and represents half the reported errors.
The "Script error." happens in Firefox, Safari, and Chrome when an exception violates the browser's same-origin policy - i.e. when the error occurs in a script that's hosted on a domain other than the domain of the current page.
This behavior is intentional, to prevent scripts from leaking information to external domains. For an example of why this is necessary, imagine accidentally visiting evilsite.com, that serves up a page with <script src="yourbank.com/index.html">. (yes, we're pointing that script tag at html, not JS). This will result in a script error, but the error is interesting because it can tell us if you're logged in or not. If you're logged in, the error might be 'Welcome Fred...' is undefined, whereas if you're not it might be 'Please Login ...' is undefined. Something along those lines.
If evilsite.com does this for the top 20 or so bank institutions, they'd have a pretty good idea of which banking sites you visit, and could provide a much more targeted phishing page. (This is just one example, of course. But it illustrates why browsers shouldn't allow any data to cross domain boundaries.)
I've tested this in the latest versions of Safari, Chrome, and Firefox - they all do this. IE9 does not - it treats x-origin exceptions the same as same-origin ones. (And Opera doesn't support onerror.)
From the horses mouth: WebKit source that checks origin when passing exceptions to onerror(). And the Firefox source that checks.
UPDATE (10/21/11): The Firefox bug that tracks this issue includes a link to the blog post that inspired this behavior.
UPDATE (12/2/14): You can now enable full cross-domain error reporting on some browsers by specifying a crossorigin attribute on script tags and having the server send the appropriate CORS HTTP response headers.
An update for those that will stumble into this question in the future :
broofa is right with the answer and there's no workaround for this.
Obviously other stumbled into this limitation and some bugs requesting for an fix were filed for Firefox : Bug 69301 and for WebKit : Bug 70574
The good news is that the bug has been resolved for Firefox with the release of Firefox 13.
This is how you use it :
<script src="http://somremotesite.example/script.js" crossorigin>
crossorigin is equivalent to crossorigin=anonymous and tells the browser to do a CORS fetch of the script without sending credentials.
You must ensure that the script is sent with an Access-Control-Allow-Origin HTTP header value that matches the requesting domain, e.g.,
Access-Control-Allow-Origin: http://myhomesite.example
Access-Control-Allow-Origin: *
otherwise the browser will cancel loading the script.
For Apache:
Header set Access-Control-Allow-Origin "*"
(And see CORS examples for other web servers.)
If you're sending scripts in PHP:
header('Access-Control-Allow-Origin', 'http://myhomesite.example');
I've tested this and it works as expected. all errors from the script.js will be caught by the window.onerror handler with message, file and line details.
The WebKit bug hasn't been fixed yet, but a patch has been proposed (and uses the same solution). Hopefully the fix will be released soon.
More info about CORS here : http://enable-cors.org/
This one took quite a bit to figure out.
We did a bunch of stuff to try and solve it, including doing things like dumping the WHOLE document body back to our servers via Ajax to try and figure it out.
I am still unsure what causes "Script Error." (with the period BTW, that's how it shows up in our Ajax logger) in Firefox, but in Chrome, we were able to narrow it down to...
Drum roll...
The auto translate feature of Google Chrome.
Many English speaking people probably do not even know about this feature, but to test it, I guess visit a non-English site using Chrome. Or better yet, if you dig thru the Chrome options, there's a spot to change the browser language. Change it to something non-English, restart the browser, and visit an English site.
You should get the bar at the top asking if you would like Chrome to translate the page for you.
In our case anyways, the translator was causing the issue since it injects a script tag into your document body and (guessing here) uses some sort of JS-based system to send the content to Google's servers and get them to translate it.
Even though the error in the console was Unreferenced something, the message that was being sent to window.onerror was "Script Error.".
Anyways, there is a cure.
http://googlewebmastercentral.blogspot.com/2007/12/answering-more-popular-picks-meta-tags.html
<meta name="google" content="notranslate"/>
This will do 2 things (as far as we know, maybe more?):
a) Disable the translate bar from popping up in Chrome.
b) Disable translating of the the page via translate.google.com.
In our situation anyways, this solved A TON of these "Script Error." issues we were experiencing.
Excuse the spelling mistakes in this post, I am still on a non-English mode in Chrome writing this, and the spell checker is not set to English ;) Time to switch back.
Enjoy!
Due to the low %, you can assume they're not normal users. Probably users with userscripts, bookmarklets or even maybe just messing with the console on you website.
Having the whole HTML of a page where it happens could help testing this theory. As well as the complete error. It should give you a url, is it always the same? Is the line really 0 or just undefined?
I don't think setting default values in you onerror is a good idea and the 0 probably comes from parseInt(ln || 0) when the error isn't really on the page (see examples above).
Adding a if to see if the line is known either in the JavaScript to ignore those errors (because they probably don't come from your own code) or in the server-side code to take care of them separately would, imo, be better.
=== EDIT ===
Got to:
http://www.xavierm02.net/AZE/
Install the user.js file (I did it on Chrome but it should work on Firefox too).
Then open the html page on the same browser. It'll show you the error (I only changed that insteal of reporting to the server, it writes it on the page). With 0 as line number.
I had a similar problem: my scripts are served by a subdomain and fall under the same origin restriction. However, I solved this by:
1) adding every script tag like this:
<script type="text/javascript" src="http://subdomain.mydomain.tld" crossorigin="*.mydomain.tld" />
2) modifying the apache httpd.conf by adding the following inside every vhost (you must enbable mod_headers):
<IfModule mod_headers.c>
Header add Access-Control-Allow-Origin "*.mydomain.tld"
</IfModule>
Hope this helps ...
EDIT
On one of my server I was not able to make this functional except by replacing
*.mydomain.tld
by
*
Be aware of the flaws with potentially allowing * to phish extended information. Documentation on CORS, same-origin, img & fonts, cdn is available but very fewer about script tag crossorigin details is available.
A good article which finally point to this thread. https://danlimerick.wordpress.com/2014/01/18/how-to-catch-javascript-errors-with-window-onerror-even-on-chrome-and-firefox/
In Chrome, I also get "Script error" (on line 0) when loading both the HTML and Javascript from file:// . This doesn't happen in Firefox. Probably overzealous same-origin protection of Chrome.
All is good when loading the same HTML and Javascript over HTTP.
How about the below. The script error is not available via JavaScript so just isolate that particular case and handle it as best you can.
window.onerror = function (msg, url, lineNo, columnNo, error) {
var string = msg.toLowerCase();
var substring = "script error";
if (string.indexOf(substring) > -1){
alert('Script Error: See Browser Console for Detail');
} else {
alert(msg, url, lineNo, columnNo, error);
}
return false;
};
Both Chrome and Firefox on iOS are based on the Safari Webview but insert a bunch of custom scripts into each page that is loaded. If in any of those scripts something goes wrong, it gets reported s Script error on line 0 as well. (Browser inserted scripts count as cross origin as well)
As I have tracked down and documented in this other SO thread both Chrome and Firefox on iOS have issues in their custom scripts handling SVG elements correctly. So in addition to all other answers in this thread: If you use SVG elements and <a> tags inside <svg> tags on your page, that will lead to Script errors being reported in iOS Chrome and iOS Firefox.
I'll tell you what fixed it for me on Safari (WebKit):
If I put the JS callback routine actually on the page, then I get full info. If I include it in a .js file via a tag, I just get the "Script error" error (with no linenumber, etc.).
Maybe this is related to what Broofa said.
Anwyay, so now I have a small callback in the page, and then the rest of the file outside of the page.
I've done a bit of searching and it appears that a "Script Error" means it had trouble loading a file that it was asked to look for. This could be a caching problem on the client side, or it could be a server problem due to overloading.
It's most likely caused by something like this where the script itself is the file it can't load, hence the error occurring on line 0.
<script type="text/javascript" src="somescript.js"></script>
I've experienced
Script Error. line 0
errors for some time being reported back to our server when the error occurred in customer browsers. Yesterday for the first time (after introducing "use strict"; in our javascript) I was able to replicate this issue in Safari and Chrome on Windows 7. After littering our code with alert() statements I traced this error down to the use of an undefined variable! e.g. xx = 123; where xx is not defined with a var statement.
Safari reported this as
ReferenceError: Strict mode forbids implicit creation of global property 'xx'
within Web Inspector, but window.onerror function was detecting
Script Error. line 0
Grepping Firefox's source code reveals that there's no "Script Error.". Thus, it's very likely that some script on your site is throwing an uncaught error like this:
throw new Error('Script Error.');
Probably this statement is only reached in Firefox and Chrome.
Not sure why there's no line number though. Maybe some eval() issue?
I am getting a message sometimes in Firefox, which says that a script is frozen or damaged. The script which the dialog mentions is:
http://example.com/:1
I can not reproduce the dialog at the moment, but the :1 looks suspicious. What could that mean?
The message in Firefox is similiar to this one: A script on this page may be busy, or It may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
Thanks!
If a JavaScript error has a colon followed by a number, the number is what line in the script that caused the error.
For example, foo-bar.js:57 means the error occurred on the 57th line in "foo-bar.js".
The reason why your error says http://example.com/ is because the server of "example.com" is configured to display the home-page without saying "/home.html" in the URL, so you don't see anything after the "/". The JavaScript of "example.com" is probably inline, so it doesn't say http://example.com/script.js:1 either.
* I used fake examples for the "example.com" thing.
I have a script that detects Javascript errors on my website and sends them to my backend for reporting. It reports the first error encountered, the supposed line number, and the time.
EDIT to include doctype:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" xmlns:fb="http://www.facebook.com/2008/fbml">
...
<script type="text/javascript">
//<![CDATA[
// for debugging javascript!
(function(window){
window.onerror = function(msg, url, ln) {
//transform errors
if (typeof(msg) === 'object' && msg.srcElement && msg.target) {
if(msg.srcElement == '[object HTMLScriptElement]' && msg.target == '[object HTMLScriptElement]'){
msg = 'Error loading script';
}else{
msg = 'Event Error - target:' + msg.target + ' srcElement:' + msg.srcElement;
}
}
msg = msg.toString();
//ignore errors
if(msg.indexOf("Location.toString") > -1){
return;
}
if(msg.indexOf("Error loading script") > -1){
return;
}
//report errors
window.onerror = function(){};
(new Image()).src = "/jserror.php?msg=" + encodeURIComponent(msg) + "&url=" + encodeURIComponent(url || document.location.toString().replace(/#.*$/, "")) + "&ln=" + parseInt(ln || 0) + "&r=" + (+new Date());
};
})(window);
//]]>
</script>
Because of this script, I'm acutely aware of any javascript errors that are happening on my site. One of by biggest offenders is "Script Error." on line 0. in Chrome 10+, and Firefox 3+. This error doesn't exist (or may be called something else?) in Internet Explorer.
Correction (5/23/2013): This "Script Error, Line 0" error is now showing up in IE7 and possibly other versions of IE. Possibly a result of a recent IE security patch as this behavior previously did not exist.
Does anyone have any idea what this error means or what causes it? It happens on about 0.25% of my overall pageloads, and represents half the reported errors.
The "Script error." happens in Firefox, Safari, and Chrome when an exception violates the browser's same-origin policy - i.e. when the error occurs in a script that's hosted on a domain other than the domain of the current page.
This behavior is intentional, to prevent scripts from leaking information to external domains. For an example of why this is necessary, imagine accidentally visiting evilsite.com, that serves up a page with <script src="yourbank.com/index.html">. (yes, we're pointing that script tag at html, not JS). This will result in a script error, but the error is interesting because it can tell us if you're logged in or not. If you're logged in, the error might be 'Welcome Fred...' is undefined, whereas if you're not it might be 'Please Login ...' is undefined. Something along those lines.
If evilsite.com does this for the top 20 or so bank institutions, they'd have a pretty good idea of which banking sites you visit, and could provide a much more targeted phishing page. (This is just one example, of course. But it illustrates why browsers shouldn't allow any data to cross domain boundaries.)
I've tested this in the latest versions of Safari, Chrome, and Firefox - they all do this. IE9 does not - it treats x-origin exceptions the same as same-origin ones. (And Opera doesn't support onerror.)
From the horses mouth: WebKit source that checks origin when passing exceptions to onerror(). And the Firefox source that checks.
UPDATE (10/21/11): The Firefox bug that tracks this issue includes a link to the blog post that inspired this behavior.
UPDATE (12/2/14): You can now enable full cross-domain error reporting on some browsers by specifying a crossorigin attribute on script tags and having the server send the appropriate CORS HTTP response headers.
An update for those that will stumble into this question in the future :
broofa is right with the answer and there's no workaround for this.
Obviously other stumbled into this limitation and some bugs requesting for an fix were filed for Firefox : Bug 69301 and for WebKit : Bug 70574
The good news is that the bug has been resolved for Firefox with the release of Firefox 13.
This is how you use it :
<script src="http://somremotesite.example/script.js" crossorigin>
crossorigin is equivalent to crossorigin=anonymous and tells the browser to do a CORS fetch of the script without sending credentials.
You must ensure that the script is sent with an Access-Control-Allow-Origin HTTP header value that matches the requesting domain, e.g.,
Access-Control-Allow-Origin: http://myhomesite.example
Access-Control-Allow-Origin: *
otherwise the browser will cancel loading the script.
For Apache:
Header set Access-Control-Allow-Origin "*"
(And see CORS examples for other web servers.)
If you're sending scripts in PHP:
header('Access-Control-Allow-Origin', 'http://myhomesite.example');
I've tested this and it works as expected. all errors from the script.js will be caught by the window.onerror handler with message, file and line details.
The WebKit bug hasn't been fixed yet, but a patch has been proposed (and uses the same solution). Hopefully the fix will be released soon.
More info about CORS here : http://enable-cors.org/
This one took quite a bit to figure out.
We did a bunch of stuff to try and solve it, including doing things like dumping the WHOLE document body back to our servers via Ajax to try and figure it out.
I am still unsure what causes "Script Error." (with the period BTW, that's how it shows up in our Ajax logger) in Firefox, but in Chrome, we were able to narrow it down to...
Drum roll...
The auto translate feature of Google Chrome.
Many English speaking people probably do not even know about this feature, but to test it, I guess visit a non-English site using Chrome. Or better yet, if you dig thru the Chrome options, there's a spot to change the browser language. Change it to something non-English, restart the browser, and visit an English site.
You should get the bar at the top asking if you would like Chrome to translate the page for you.
In our case anyways, the translator was causing the issue since it injects a script tag into your document body and (guessing here) uses some sort of JS-based system to send the content to Google's servers and get them to translate it.
Even though the error in the console was Unreferenced something, the message that was being sent to window.onerror was "Script Error.".
Anyways, there is a cure.
http://googlewebmastercentral.blogspot.com/2007/12/answering-more-popular-picks-meta-tags.html
<meta name="google" content="notranslate"/>
This will do 2 things (as far as we know, maybe more?):
a) Disable the translate bar from popping up in Chrome.
b) Disable translating of the the page via translate.google.com.
In our situation anyways, this solved A TON of these "Script Error." issues we were experiencing.
Excuse the spelling mistakes in this post, I am still on a non-English mode in Chrome writing this, and the spell checker is not set to English ;) Time to switch back.
Enjoy!
Due to the low %, you can assume they're not normal users. Probably users with userscripts, bookmarklets or even maybe just messing with the console on you website.
Having the whole HTML of a page where it happens could help testing this theory. As well as the complete error. It should give you a url, is it always the same? Is the line really 0 or just undefined?
I don't think setting default values in you onerror is a good idea and the 0 probably comes from parseInt(ln || 0) when the error isn't really on the page (see examples above).
Adding a if to see if the line is known either in the JavaScript to ignore those errors (because they probably don't come from your own code) or in the server-side code to take care of them separately would, imo, be better.
=== EDIT ===
Got to:
http://www.xavierm02.net/AZE/
Install the user.js file (I did it on Chrome but it should work on Firefox too).
Then open the html page on the same browser. It'll show you the error (I only changed that insteal of reporting to the server, it writes it on the page). With 0 as line number.
I had a similar problem: my scripts are served by a subdomain and fall under the same origin restriction. However, I solved this by:
1) adding every script tag like this:
<script type="text/javascript" src="http://subdomain.mydomain.tld" crossorigin="*.mydomain.tld" />
2) modifying the apache httpd.conf by adding the following inside every vhost (you must enbable mod_headers):
<IfModule mod_headers.c>
Header add Access-Control-Allow-Origin "*.mydomain.tld"
</IfModule>
Hope this helps ...
EDIT
On one of my server I was not able to make this functional except by replacing
*.mydomain.tld
by
*
Be aware of the flaws with potentially allowing * to phish extended information. Documentation on CORS, same-origin, img & fonts, cdn is available but very fewer about script tag crossorigin details is available.
A good article which finally point to this thread. https://danlimerick.wordpress.com/2014/01/18/how-to-catch-javascript-errors-with-window-onerror-even-on-chrome-and-firefox/
In Chrome, I also get "Script error" (on line 0) when loading both the HTML and Javascript from file:// . This doesn't happen in Firefox. Probably overzealous same-origin protection of Chrome.
All is good when loading the same HTML and Javascript over HTTP.
How about the below. The script error is not available via JavaScript so just isolate that particular case and handle it as best you can.
window.onerror = function (msg, url, lineNo, columnNo, error) {
var string = msg.toLowerCase();
var substring = "script error";
if (string.indexOf(substring) > -1){
alert('Script Error: See Browser Console for Detail');
} else {
alert(msg, url, lineNo, columnNo, error);
}
return false;
};
Both Chrome and Firefox on iOS are based on the Safari Webview but insert a bunch of custom scripts into each page that is loaded. If in any of those scripts something goes wrong, it gets reported s Script error on line 0 as well. (Browser inserted scripts count as cross origin as well)
As I have tracked down and documented in this other SO thread both Chrome and Firefox on iOS have issues in their custom scripts handling SVG elements correctly. So in addition to all other answers in this thread: If you use SVG elements and <a> tags inside <svg> tags on your page, that will lead to Script errors being reported in iOS Chrome and iOS Firefox.
I'll tell you what fixed it for me on Safari (WebKit):
If I put the JS callback routine actually on the page, then I get full info. If I include it in a .js file via a tag, I just get the "Script error" error (with no linenumber, etc.).
Maybe this is related to what Broofa said.
Anwyay, so now I have a small callback in the page, and then the rest of the file outside of the page.
I've done a bit of searching and it appears that a "Script Error" means it had trouble loading a file that it was asked to look for. This could be a caching problem on the client side, or it could be a server problem due to overloading.
It's most likely caused by something like this where the script itself is the file it can't load, hence the error occurring on line 0.
<script type="text/javascript" src="somescript.js"></script>
I've experienced
Script Error. line 0
errors for some time being reported back to our server when the error occurred in customer browsers. Yesterday for the first time (after introducing "use strict"; in our javascript) I was able to replicate this issue in Safari and Chrome on Windows 7. After littering our code with alert() statements I traced this error down to the use of an undefined variable! e.g. xx = 123; where xx is not defined with a var statement.
Safari reported this as
ReferenceError: Strict mode forbids implicit creation of global property 'xx'
within Web Inspector, but window.onerror function was detecting
Script Error. line 0
Grepping Firefox's source code reveals that there's no "Script Error.". Thus, it's very likely that some script on your site is throwing an uncaught error like this:
throw new Error('Script Error.');
Probably this statement is only reached in Firefox and Chrome.
Not sure why there's no line number though. Maybe some eval() issue?
I get this error message in Firebug:
Permission denied for <http://googleads.g.doubleclick.net> to call method Location.toString
It comes from this page:
http://www.comehike.com/outdoors/trees/add_spotted_trees.php?hike_id=108
The login credentials for this page are:
test#comehike.com | password
When I look at it in Firebug, using the Console --> Errors view, I see that error first, followed by a number of other errors, but I can't really double-click on the errors to see what line they are coming from, and the line isn't written there as far as I can see. There are some line references on the page, but they lead to pretty random spots.
Any ideas how to debug such a thing? I am new to JS and FireBug.
Thanks,
Alex
The Location.toString error is usually due to some ad-serving javascript code, trying to get a text version of the current page's location. Firefox denies access to this information to 3rd party scripts by default, since 3rd party scripts should have no business knowing exactly what page you're on.
Basically it's an attempt by ad networks to work around some clients not sending referers, by trying to grab the location data directly.
In firebug under the "bug" icon (upper left when open) you'll see a pause button (in the console tab). This will cause the page to stop loading and jump to the exact error in the script.
However, when I visited the page I do not see any errors.
body' onLoad is:
initializeTreeHike( , );
You don't need to use comma if you wish to pass no parameters to the function.
When I follow the provided link in Firefox 4.0 with Firebug 1.7, I don't receive the error you encountered. What I do receive however is the following:
Syntax error: initializeTreeHike( , );
It appears this is coming from line 326 in add_spotted_trees.php in the following line:
<body onload="initializeTreeHike( , );"
Perhaps you meant to pass in empty strings as parameters?