My javascript application has its own error handling (and UI support) for dealing with comms errors with the server. For testing, I'm inducing comms errors by simply severing the network connection (turning off the wifi).
All good in Chrome/Safari... IE 11, however, will replace my content with its own network loss messages, like "This page can't be displayed" (i.e., shows dnserrordiagoff.htm). This is, in short, annoying and undesired. Is there any way to suppress it?
Bonus: Firefox 43 is kind enough to replace my content with a blank/empty window. Any thoughts?
Thanks all, -Pete
Related
IE8 seems doesn't allow to replace <script> e.g:
someHtml.replace(/<script.+<\/script>/g, "")
and page with that script fails to load providing that information:
The website cannot display the page HTTP 500
Most likely causes:
The website is under maintenance.
The website has a programming error.
What you can try:
Refresh the page. Go back to the previous page. < sarcasm>Use normal browser.< /sarcasm>
More information
This error (HTTP 500 Internal Server Error) means that the website you
are visiting had a server problem which prevented the webpage from
displaying.
500 (!!) error when it clearly not server error (but wait, that's IE nothing to wonder)
However when I change script to div like so:
someHtml.replace(/<div.+<\/div>/g, "")
It works.
So I have that feeling that it is some IE bug so it tried to read <script as a start of script element and it fails (managed to find out that 500 error displayed even when there is not escaped slash / e.g. /<div.+</div>/g )
Or maybe there is some setting in IE that prevents to do things like that for some security means.
Can someone confirm that it is a bug or some setting needed or even something else?
I'm loading a json file via ajax. If Chrome dev tools is open, everything functions perfectly. If Chrome dev tools is closed it fails. Thankfully dev tools still keeps doing it's thing even when closed so I can still see the exception I get:
Failed to load resource: the server responded with a status of 412 (Precondition Failed) http://localhost/experiments/escape/maps/test.json
Why would there be a precondition on whether dev tools is open? Also, it seems unlikely that opening and closing the dev tools could in any way affect the server's behaviour so I think it is Chrome that is preventing the request rather than the server as suggested in the exception.
Unfortunately, dev tools does not keep track of network activity when closed so I can't use the network tab to get any further info.
The AJAX is handled via JQuery with the following code:
map.load = function(mapName, tileSource, tileWidth, tileHeight, onLoad) {
$.ajax({
url: '../escape/maps/'+mapName+'.json',
type: 'post',
success: function(mapData) {
// there's loads of stuff in here but I don't think it's relevant to the question as the failure prevents the success method from being called.
}
});
};
This code causes no issues in Firefox and so does seem specifically to be connected to Chrome Dev Tools. Any suggestions welcome as I'm completely flummoxed!
EDIT: Ok so it's not dev tools fault at all - I had disabled the cache in dev tools, re-enabling it allows the script to work correctly. Why does my code depend on the cache? Disabling / enabling the cache in Firefox does not cause any issues
EDIT2: Ok, I think I'm getting close. The precondition that is failing is the if-modified-since condition (the file hasn't changed). I assume that chrome is sending this to confirm whether or not to use the cached version, however, despite the precondition failing it does not load the cached version. I thought this might mean the cache was corrupted in some way so I cleared the cache. Unfortunately this doesn't solve the issue. The file will happily load once but on the next time I'm back where I started with the same issue. Any ideas?
#Rondel - You've got it! The issue was that I was stupidly using 'post' to fetch a static file. Post requests are never supposed to be cached so that is why Chrome doesn't retrieve it. I've still got no idea why chrome still sends the if-modified-since header but in any case changing the request type to get is the solution to the problem (Sorry Crome Dev tools for unfairly blaming you - the issue, as usual, was my code!)
Because IE doesn't support Asynchronous file uploads, I'm using a work-around that involves posting a form to an iframe. I bind the the onLoad event of the iframe and read its contents when the event is fired. This works well, except when the server returns a status code other than 200, in which case IE8/IE9 throws a "SCRIPT5: Access is denied" error. It seems Microsoft have decided that no one should be allowed to read the contents of an iframe unless the request returns 200 OK.
Googling has turned up nothing, so here I am seeking help. Can anyone else reproduce this odd behavior? Is there anyway around this issue?
The iframe does not violate any cross-site security policies. It's all on the same domain.
I think I've worked this one out while trying to reproduce the problem on fiddler. Turning off the "Show Friendly HTTP error messages" in IE seems to fix it. The reason I couldn't reproduce it on fiddler is that their 404 pages are over 512 bytes, hence it would show the nginx error regardless.
Basically, the whole issue is that when a page is less than 512 bytes (or 256 in some cases), IE seems to substitute the whole page which has the consequence of blocking access to that page programmatically. Obviously an oversight by Microsoft which still seems to be present in IE10.
It's easy to reproduce. Just place the following in a file (e.g. test.html) under a server than returns a 404 response code under 512 bytes, and ensure your IE is set to show friendly error messages (also make sure "test1.file" doesn't actually exist). Hit the page with IE with the developer console open, and you should see a "access denied" error. How you refresh the page alters the outcome. A CTRL+F5 doesn't seem to exhibit the problem, but a CTRL+R or F5 does.
<!DOCTYPE html>
<html lang="en">
<head>
</head>
<body>
<script type="text/javascript">
iframe = document.createElement('iframe')
iframe.src = '/test1.file'
document.body.appendChild(iframe )
iframe.contentDocument
</script>
</body>
</html>
Now, if only I could find where I can submit bug reports for IE10 so we can make our life dealing with this horrific browser just a little better.
I am developing a FireFox extension
when I do xhr to the Secure server , particularly POST a data
it gives a status 500, and following mesage:
onsip.highrisehq.com : server does not
support RFC 5746, see CVE-2009-3555
How can I by pass by It? I assume that this is because of the Server misconfiguration, but I can't wait till someone from 37 signal will fix it. thanks for your help
Well - "see CVE-2009-3555". Basically it's a server side vulnerability which might allow to compromise a TLS/SSL session.
I'm not sure there's anything you can do on the client side to resolve this, until 37signals update their servers.
This is sort of a hack, but another option (instead of the XHR request) is a "hidden" (1px by 1px) IFRAME. It's not pretty, but I've used it in situations where I had (different) problems with the XHR route (and there might even be a way to hide it entirely, but the 1px/1px works for me so I've never bothered to try anything else).
Just change the frame's src attribute to "make a request", then view it's document to read the "response".
The project I'm working on uses a window.onerror event handler to report user problems. I've noticed a single user that just cannot seem to load the Google Analytics script. Our site doesn't see a lot of traffic so I'm not sure how widespread this is, but so far it seems to just effect one user.
His user agent is: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 Firefox/2.0.0.17".
The error message Firefox gives is: "Error loading script".
Additional note: The site references several other javascript files. However, the analytics reference is the only one to an external domain and the only script reference at the bottom of the page, just before the closing body tag.
Has anybody else run across this, or have any idea what could be the issue? Thanks!
This problem occurs when leaving a page in Firefox before all scripts have finished loading. So I assume that it is safe to ignore the error.
You don't see this error in the Firefox error console, but you can make it visible by binding an alert to the window.onerror event. Then you will be able to see the alert box for a small amount of time and get the following error in the error console:
[11:35:57.428] uncaught exception: [Exception... "prompt aborted by user" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: resource:///components/nsPrompter.js :: openTabPrompt :: line 462" data: no]
I'm using the following check to ignore this error in my onerror handler:
if (navigator.userAgent.search('Firefox') != -1 && message === 'Error loading script') {
// Firefox generates this error when leaving a page before all scripts have finished loading
return;
}
This is a rather random guess, but I wonder if the user is using an add-on like NoScript to control script execution and is not allowing scripts from Google Analytics to run. I know this is possible because it's what I do :) I don't know if that would show up as the error you're seeing.
I have a site with over 80 pages, all that employ JavaScript error trapping. My site serves well over 2000 pages a day and I get about ten "Error loading script" scripting errors each day from Firefox browsers. It is beginning to really annoy me and I am becoming convinced that it is a problem in Firefox.
I can discount the NOSCRIPT suggestion because the script loads in the head of my pages where there are no NOSCRIPT tags.
I can discount the 'external domain' suggestion because I have two sites that suffer this problem and in both cases the JS library files are located on the sites own server.
I have carefully checked every library file and web page using JavaScript Lint and I have discovered scripting errors and questionable scripting techniques. All these problems have been corrected but this has not provided any sort of cure to the "Error loading script" problem.
My pages do load several JavaScript library files that do not have this problem and the only difference is the size of the files. Most of the files are under 5KB but the problem file is 17KB.
Could the size of the library file be the problem?
Aagh!
We had the same issue and after examining our CDN logs, we discovered that Firefox triggers the onerror event when a script returns with HTTP status "304 Not Modified", so a cache hit. In fact, Firefox (tested with Firefox 12 at time of this writing), seems to trigger onerror event for all HTTP statuses except '200 Ok'. Other browsers behaved differently in our experiment: Chrome (19) triggered onerror only on '407 Proxy Authentication Required' and Opera (12) on 100, 101, 204, 4xx and 5xx.
I'm sure this is long resolved.. but to anyone who stumbles across this page: this error is triggered by firefox when an external script fails to load (it's easy to find the code that triggers this in the source code). We were catching these errors on our site and it turned out that we were returning 404s for the script, so I suggest looking at your logs as one possibly source of this error.