I am getting the strange error "SCRIPT70: Permission denied jquery.js, line 21 character 67" on IE-9. Searched on google but could not find anything except a bug on CKEditor.
Position it showed just contains following:
P=navigator.userAgent,xa=false,Q=[],M,ca=Object.prototype.toString,da=Object.prototype.hasOwnProperty,ea=Array.prototype.push,R=Array.prototype.slice,V=Array.prototype.indexOf;c.fn=c.prototype={init:function(a,b){var d,f;if(!a)return this;if(a.nodeType){this.context=this[0]=a;this.length=1;return this}if(typeof a==="string")if((d=Oa.exec(a))&&(d[1]||!b))if(d[1]){f=b?b.ownerDocument||b:s;if(a=Sa.exec(a))if(c.isPlainObject(b)){a=[s.createElement(a[1])];
anyone run into this error?
*Additional Info:*We open an iframe and call some javascript functions inside this iframe.
thanks.
The SCRIPT70 error in IE9 occurs most likely when your iframe is calling some javascript (especially if it affects the parent page - e.g. hash change of parent url)
Check that your iframe's host/protocol/port number matches.
IE9 is exceptionally strict about the host name(down to the www portion in my case) and document.domain did not seem to provide a workaround for that.
Encountered this issue and fixed it while dealing with multiple iframes, hope this helps others with the same issue.
function Sizzle( selector, context, results, seed ) {
var match, elem, m, nodeType,
// QSA vars
i, groups, old, nid, newContext, newSelector;
// MY EDIT - this try/catch seems to fix IE 'permission denied' errors as described here:
// http://bugs.jquery.com/ticket/14535
try{
document === document; //may cause permission denied
}
catch(err){
document = window.document; //resets document, and no more permission denied errors.
}
if ( ( context ? context.ownerDocument || context : preferredDoc ) !== document ) {
setDocument( context );
}
//...... snip .........//
}
http://jsfiddle.net/xqb4s/
I was having this exact problem with IE9 and in fact, it happens with IE11 as well.
My problem was I was opening a website via http (i.e. http://mywebsite.com) and an iframe within my code was trying to access a portion of the website using https. This was causing the error. Once I accessed the website using https, the error went away. A old bookmark was the cause of it using http and the site had been updated with https so check your URLS.
You cannot access any of your iframe's contents if it points to a different domain than the parent site.
If you are dealing with select element in your script maybe your problem is like mine
SCRIPT70: Permission denied when adding options to select element from a recently closed iframe
Recently I encountered this error. In the application I am working, I'm using TinyMce text editor for our email composer. This creates an iframe which contains the objects I need for an email composer. After seeing many blogs about the said error, I tried to programmatically remove the TinyMce text editor object then triggered the redirection. And it WORKED!
Facing a similar issue (maybe not with jquery.js but the same error description) the solution was a bit different from above. Actually I have searched for other iexplore.exe lines in regedit. I have found other two and changed it to 1 and it worked then.
hkey_local_machine\software\microsoft\internet explorer\main\featurecontrol\feature_protocol_lockdown
hkey_local_machine\software\microsoft\internet explorer\main\featurecontrol\feature_internet_shell_folders
If you run a 64-bit OS, make sure the value of this key is also set to 1: HKEY_LOCAL_MACHINE\SOFTWARE\**Wow6432Node**\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_OBJECT_CACHING\\iexplore.exe
Without this key we had random SCRIPT70: Permission denied errors in Internet Explorer 11.
Tip from this one page should help: http://forum.jquery.com/topic/strange-behaviour-in-ie9
Make sure that HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_OBJECT_CACHING\iexplore.exe is not set to 0 (it should be 1 or missing)
Related
My question is different from the other posts similar to this.
AutoCAD offers developers a means of displaying a URL page inside the application. I created an intranet site for my company with the hopes that users can explore via desktop browser or their AutoCAD application.
The problem is that the browser AutoCAD uses is Chrome version 33 (currently its at 84) - there is no way to update or change the browser either.
I have no way to "inspect" or debug the site inside AutoCAD - and I've come to find out there are many difference in v84 and v33. I'm trying to diagnose errors right now but again, I have no way of accessing the console logs inside the AutoCAD Browser.
Is there a way for me to "alert" any errors that the console is trying to give me? (ie: the page can't find a script reference, there is an unexpected '.', etc...)
NOTE - my site runs great on the most updated Chrome browser (v84 on desktop browser), but some little things are not working right in v33 (in AutoCAD Browser).
If you control the website you can attach a listener on the window to listen for any unhandled exceptions. Add this before all other scripts to make sure everything is captured.
window.on('error', (e) => {
// if error is intresting, do work.
alert(e.message);
});
The handler accepts an ErrorEvent object.
NOTE - This will not capture errors that are triggered in scripts across domain. For example if you are loading google maps, and an error is triggered within that script, you will typically get a 'Script error.' and no other info. This has to do with cross origin policies. You can read more here.
If you need to specifically to capture data sent to console.error you can simply proxy the function. This may not capture anything except for code that explicitly calls console.error and is not recommended.
const error = console.error;
console.error = (...args) => {
// alert(...);
error.apply(console, args);
}
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 have an AJAX post that retrieves data from the server and either replaces part of the page or in some cases the full page. This is controlled by a javascript fullRefresh parameter. The problem is the refresh code works find in Firefox but causes a Permission Denied error in the bowels of JQuery after it runs in IE although it would appear to actually replace the page contents successfully.
IE version 11.0.9600.16659
JQuery version 1.8.2
Error message
Unhandled exception at line 2843, column 3 in http://localhost:62761/Scripts/jquery-1.8.2.js
0x800a0046 - JavaScript runtime error: Permission denied
My code is
function RefreshScreenContent(formActionUrl, formHTML, fullRefresh) {
fullRefresh = (typeof fullRefresh === "undefined") ? false : fullRefresh;
if (fullRefresh) {
document.write(formHTML);
document.close();
}
else {
$("#content-parent").html(formHTML);
}
}
The partial refreshes work fine but the full refreshes are the problem. I have tried hardcoding the document.write call to write a well formed simple html page rather than formHTML in case that was somehow the problem but even a simple single word page causes the error.
The actual error occurs a some point later with a callback inside JQuery.
The AJAX post to the server is in the same application i.e. is not a cross domain request. I have seen posts online talking aboue cross domain stuff that is not applicable here.
Can anyone tell me why this is happening and how to stop it? Is there an alternative IE way of replacing the page contents?
Your code is fine (at least at first glance). My guess is that you make the call in such a way, that it is interpreted as cross-domain.
I would suggest checking:
http vs https (most common)
the destination port
the root url
maybe the "destination" page makes some requests of its own, check to be on same domain
The reason why IE may be the only one with the problem is that it has higher security demanding by default that other browsers (check advanced security settings - can't remember where they are put in menu) so it interprets requests in a more "paranoid" manor.
I repeat, what I said is just a guess, based on cases I've been put into.
In the end I used the approach here to replace the body tag in the pgae with the one in the markup the AJAX receives back https://stackoverflow.com/a/7839921/463967
I would have preferred to replace all content not just the body but I can always adapt later to include the header etc as body is enough for my uses right now. This works in IE and Firefox.
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 have a outer HTML-document (subdomain1.server-a.de) with an iFrame and inner HTML-document (subdomain2.server-a.de). The inner script should send & receive AJAX-requests to subdomain2.server-a.de. I've set the document.domain-value for both documents to "server-a.de" - so far, so good, works well in all tested browsers (FF/Chrome/Opera). Now I move the scripts to server-b.de with same subdomains and set the document.domain on both documents to "server-b.de". That still works in FF and Chrome, but Opera gives me a "Security error: attempted to read protected variable: xy" when trying to call my AJAX function from the outer document.
My conclusion so far: I can't violate the same domain policy, because then FF and Chrome wouldn't communicate with the inner document from outside either. I've also tried the solution from Focus with Cross-domain Ajax in Opera with the interval function, same issue.
Thanks a lot in advance for every hint.
UPDATE: I have set up a testing site for this. If you go to this site, you'll see, it works even with Opera (a dialog pops up with "Test called" after a few seconds). Now, if you copy the outer frame files "operatest.html" and jquery to another server - so it has to work in my case - you'll see, that FF and Chrome don't have a problem, but Opera has.
Is Opera comparing server details in order to fulfill the same origin policy? Or will it deny access, if ip adresses of both subdomains don't match?
Sounds like it might be a timing issue, i.e. the outer document tries to initiate the request before the inner document has run the script that sets document.domain?? Or perhaps Opera has cached the IFRAME contents and you initially loaded a version where the script inside the IFRAME was wrong and didn't set document.domain correctly?
I suggest you forget the document.domain approach and use window.postMessage() (AKA HTML5-style cross-document messaging) instead.
http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#web-messaging
Had the same absurd issue with JS calls between parent and an iframe on a different subdomain - worked everywhere, but failed under Opera with the above mentioned error.
Removing ~/.opera folder (Opera settings folder in Linux) solved this, and another one very weird problem.
Cheers.