We Keep Coding

IE8 shows 500 page when it contains regex with script replace

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?

Firefox Javascript console and network tab not showing important errors?

While casually debugging some javascript on a web page, I noticed that Firefox (33.0 - Windows 7) Javascript console would not tell me if some .js files failed to load, so I decided to give this a closer look.
What I found is that if I have an HTML with a script tag pointing to a wrong local url, as the page loads the console shows no errors at all. Instead it shows the full path and file name for the wrong .js script as if there was nothing wrong with it.
I also tried with a button element issuing a xmlhttprequest to a non existing remote url, and same thing, no errors at all in the console when clicking.
$("#button").click(function(){
console.log("clicked me")
$.getJSON("demo_ajax_json.js",function(result){
$.each(result, function(i, field){
$("div").append(field + " ");
});
});
});
while "clicked me" will show as expected.
Also I verified that every possible log setting in developer tools is checked.
After reading that someone had luck with complete settings reset I went through that using Menu > Help > Troubleshooting > Reset Firefox settings. But... no. The errors still don't show up.
So, end of the story, given I just recently decided to look into this, and I can't exactly remember how long I've not been seeing errors exactly, I am questioning myself whether those kind of errors do not shown up at all in Firefox by design and if it's just a prerogative of Chrome... which, it goes by itself, shows all the errors (like for example "net::ERR_FILE_NOT_FOUND").
Anyone for a quick test on their console?
UPDATE, attaching screenshots of both Firefox and Chrome.
As you can see the situation is totally different.
Code:
Firefox Console Tab:
Also no errors on the missing files, whose name is just printed out normally in the console as if nothing was wrong with them.
Firefox Network Tab:
AS OPPOSED TO
Chrome Console Tab:
Chrome Network Tab:

After looking at the screenshots you added, I noticed that you were references resources on your local file system, so I decided to do some tests. I found that Firefox indeed does not report network errors for files on the local filesystem, reporting nothing on the console or the network tab, however it does report them properly for network resources. Unfortunately I could not reproduce the errors in chrome exactly, as my local filesystem is locked down rather tightly (I'm on an enterprise-owned system) and chrome simply reports that it doesn't have permission to access the local filesystem, regardless of whether the file exists or not (Firefox says nothing). Meanwhile, I imagine if you pointed your script/link tags to a network address such as a CDN, or if you are testing on a local test server something like:
http://localhost/[script-address]
it should report the error in both consoles.
Here's my test code:
And the firefox net panel
And the chrome console
Preserving my original answer below this point, as the JQuery API notes may be helpful for others who find themselves here
As mentioned in Ian's comment, and the JQuery API document at http://api.jquery.com/jQuery.getJSON/ JQuery's getJSON method will simply fail silently if you have a syntax error, the URL doesn't exist, or if it doesn't return a response. You can force it to do so by adding a .fail() method call to the end like so:
$("#button").click(function(){
console.log("clicked me")
$.getJSON("demo_ajax_json.js",function(result){
$.each(result, function(i, field){
$("div").append(field + " ");
});
}).fail(function() {
console.log("AJAX request failed");
});
});
You can also bind a function to the error event by using the .ajaxError method documented here: http://api.jquery.com/ajaxError/
$.ajaxError(function() {
console.log("AJAX request failed.");
});
Note that when you do it this way, JQuery will pass the function several useful parameters if you create variables to hold them, including the error event itself, the ajax object that triggered it, the settings that were used, and the error string, which you can then use to output whatever information you need to the console in order to debug what was causing your error. Good luck!

Form/JavaScript not working on IE 11 with error DOM7011

The register button for our ASP.net form, which uses the __postback function stopped working on IE 11, from the developer console, it shows:
DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337.
Does anyone know how to get around with this? What is this caching thing and why does it mess up forms. I seen similar complaints about this from others.

This issue occurs if the server sends a "Cache-control:no-store" header or sends a "Cache-control:no-cache" header.

I have seen exactly the same error, also with IE11. In my case the issue occurred when user clicked <button> element, which was inside <form> tags.
The issue was remedied, by placing the <button> outside of <form> tags.

This error occurred for me when using window.location.reload(). Replacing with window.location = window.location.href solved the problem.

I faced the same issue before.
I cleared all the IE caches/browsing history/cookies & re-launch IE. It works after caches removed.
You may have a try. :)

In my case, this exception was being caused by an unsecure ajax call on an SSL enabled site. Specifically: my url was 'http://...' instead of 'https://...'. I just replaced it with '//...'.
To me, the error was misleading, and hopefully this may help anyone landing here after searching for the same error.

I run into this when click on a html , it is fixed by adding type = "button" attribute.

I got the same console warning, when an ajax request was firing, so my form was also not working properly.
I disabled caching on the server's ajax call with the following response headers:
Cache-Control: no-cache, no-store, must-revalidate
Expires: -1
Pragma: no-cache
After this, the form was working. Refer to the server language (c#, php, java etc) you are using on how to add these response headers.

I had a similar problem on Internet Explorer, and got the same error number. The culprit was an HTML comment. I know it sounds unbelievable, so here is the story.
I saw a series of 6 articles on the Internet. I liked them, so I decided to download the 6 Web-Pages and store them on my Hard Drive. At the top of each page, was a couple of HTML <a> Tags, that would allow you to go to the next article or the previous article. So I changed the href attribute to point to the next folder on my Hard Drive, instead of the next URL on the Internet.
After all of the links had been re-directed, the Browser refused to display any of the Web-Pages when I clicked on the Links. The message in the Console was the Error Number that was mentioned at the top of this page.
However, the real problem was a Comment. Whenever you download a Web-Page using Google Chrome, the Chrome Browser inserts a Comment at the very top of the page that includes the URL of the location that you got the Web-Page from. After I removed the Comment at the top of each one of the 6 Pages, all of the Links worked fine ( although I continued to get the same Error Message in the Console. )

Go to
Tools > Compatibility View settings > Uncheck the option "Display intranet sites in Compatibility View".
Click on Close. It may re-launch the page and then your problem would be resolved.

"undefined" randomly appended in 1% of requested urls on my website since 12 june 2012

Since 12 june 2012 11:20 TU, I see very weirds errors in my varnish/apache logs.
Sometimes, when a user has requested one page, several seconds later I see a similar request but the all string after the last / in the url has been replaced by "undefined".
Example:
http://example.com/foo/bar triggers a http://example.com/foo/undefined request.
Of course theses "undefined" pages does not exist and my 404 page is returned instead (which is a custom page with a standard layout, not a classic apache 404)
This happens with any pages (from the homepage to the deepest)
with various browsers, (mostly Chrome 19, but also firefox 3.5 to 12, IE 8/9...) but only 1% of the trafic.
The headers sent by these request are classic headers (and there is no ajax headers).
For a given ip, this seems occur randomly: sometimes at the first page visited, sometimes on a random page during the visit, sometimes several pages during the visit...
Of course it looks like a javascript problem (I'm using jquery 1.7.2 hosted by google), but I've absolutely nothing changed in the js/html or the server configuration since several days and I never saw this kind of error before. And of course, there is no such links in the html.
I also noticed some interesting facts:
the undefined requests are never found as referer of another pages, but instead the "real" pages were used as referer for the following request of the same IP (the user has the ability to use the classic menu on the 404 page)
I did not see any trace of these pages in Google Analytics, so I assume no javascript has been executed (tracker exists on all pages including 404)
nobody has contacted us about this, even when I invoked the problem in the social networks of the website
most of the users continue the visit after that
All theses facts make me think the problem occurs silently in the browers, probably triggered by a buggy add-on, antivirus, a browser bar or a crappy manufacturer soft integrated in browsers updated yesterday (but I didn't find any add-on released yesterday for chrome, firefox and IE).
Is anyone here has noticed the same issue, or have a more complete explanation?

There is no simple straight answer.
You are going to have to debug this and it is probably JavaScript due to the 'undefined' word in the URL. However it doesn't have to be AJAX, it could be JavaScript creating any URL that is automatically resolved by the browser (e.g. JavaScript that sets the src attribute on an image tag, setting a css-image attribute, etc). I use Firefox with Firebug installed most of the time, so my directions will be with that in mind.
Firebug Initial Setup
Skip this if you already know how to use Firebug.
After the installs and restarting Firefox for Firebug, you are going to have to enable most of Firebug's 'panels'. To open Firebug there will be a little fire bug/insect looking thing in the top right corner of your browser or you can press F12. Click through the Firebug tabs 'Console', 'Script', 'Net' and enable them by opening them up and reading the panel's information. You might have to refresh the page to get them working properly.
Debugging User Interaction
Navigate to one of the pages that has the issue with Firebug open and the Net panel active. In the Net panel there will be a few options: 'Clear', 'Persist', 'All', 'Html', etc. Make sure ALL is selected. Don't do anything on the page and try not to mouse over anything on it. Look through the requests. The request for the invalid URL will be red and probably have a status of 404 Not Found (or similar).
See it on load? Skip to the next part.
Don't see it on initial load? Start using your page and continue here.
Start clicking on every feature, mouse over everything, etc. Keep your eyes on the Net panel and watch for a requests that fail. You might have to be creative, but continue using your application till you see your browser make an invalid request. If the page makes many requests, feel free to hit the 'Clear' button on the top left of the Net panel to clear it up a bit.
If you submit the page and see a failed request go out really quick but then lose it because the next page loads, enable persistence by clicking 'Persist' in the top left of the Net panel.
Once it does, and it should, consider what you did to make that happen. See if you can make it happen again. After you figure out what user interaction is making it happen, dive into that code and start looking for things that are making invalid requests.
You can use the Script tab to setup breakpoints in your JavaScript and step through them. Investigate event handlers done via $(elemment).bind/click/focus/etc or from old school event attributes like onclick=""/onfocus="" etc.
If the request is happening as soon as the page loads
This is going to be a little harder to peg down. You will need to go to the Script tab and start adding break points to every script that runs on load. You do this by clicking on the left side of the line of JavaScript.
Reload your page and your break points should stop the browser from loading the page. Press the 'Continue' button on the script panel. Go to your net panel and see if your request was made, continue till it is found. You can use this to narrow down where the request is being made from by slowly adding more and more break points and then stepping into and out of functions.
What you are looking for in your code
Something that is similar to the following:
var url = workingUrl + someObject['someProperty'];
var url = workingUrl + someObject.someProperty;
Keep in mind that someObject might be an object {}, an array [], or any of the internal browser types. The point is that a property will be accessed that doesn't exist.
I don't see any 404/red requests
Then whatever is causing it isn't being triggered by your tests. Try using more things. The point is you should be able to make the request happen somehow. You just don't know yet. It has to show up in the Net panel. The only time it won't is when you aren't doing whatever triggers it.
Conclusion
There is no super easy way to peg down what exactly is going on. However using the methods I outlined you should be at least be able to get close. It is probably something you aren't even considering.

Based on this post, I reverse-engineered the "Complitly" Chrome Plugin/malware, and found that this extension is injecting an "improved autocomplete" feature that was throwing "undefined" requests at every site that has a input text field with NAME or ID of "search", "q" and many others.
I found also that the enable.js file (one of complitly files) were checking a global variable called "suggestmeyes_loaded" to see if it's already loaded (like a Singleton). So, setting this variable to false disables the plugin.
To disable the malware and stop "undefined" requests, apply this to every page with a search field on your site:
<script type="text/javascript">
window.suggestmeyes_loaded = true;
</script>
This malware also redirects your users to a "searchcompletion.com" site, sometimes showing competitors ADS. So, it should be taken seriously.

You have correctly established that the undefined relates to a JavaScript problem and if your site users haven't complained about seeing error pages, you could check the following.
If JavaScript is used to set or change image locations, it sometimes happens that an undefined makes its way into the URI.
When that happens, the browser will happily try to load the image (no AJAX headers), but it will leave hints: it sets a particular Accept: header; instead of text/html, text/xml, ... it will use image/jpeg, image/png, ....
Once such a header is confirmed, you have narrowed down the problem to images only. Finding the root cause will possibly take some time though :)
Update
To help debugging you could override $.fn.attr() and invoke the debugger when something is being assigned to undefined. Something like this:
​(function($, undefined) {
var $attr = $.fn.attr;
$.fn.attr = function(attributeName, value) {
var v = attributeName === 'src' ? value : attributeName.src;
if (v === 'undefined') {
alert("Setting src to undefined");
}
return $attr(attributeName, value);
}
}(jQuery));

Some facts that have been established, especially in this thread: http://productforums.google.com/forum/#!msg/chrome/G1snYHaHSOc/p8RLCohxz2kJ
it happens on pages that have no javascript at all.
this proves that it is not an on-page programming error
the user is unaware of the issue and continues to browse quite happily.
it happens a few seconds after the person visits the page.
it doesn't happen to everybody.
happens on multiple browsers (Chrome, IE, Firefox, Mobile Safari, Opera)
happens on multiple operating systems (Linux, Android, NT)
happens on multiple web servers (IIS, Nginx, Apache)
I have one case of googlebot following the link and claiming the same referrer. They may just be trying to be clever and the browser communicated it to the mothership who then set out a bot to investigate.
I am fairly convinced by the proposal that it is caused by plugins. Complitly is one, but that doesn't support Opera. There many be others.
Though the mobile browsers weigh against the plugin theory.
Sysadmins have reported a major drop off by adding some javascript on the page to trick Complitly into thinking it is already initialized.
Here's my solution for nginx:
location ~ undefined/?$ {
return 204;
}
This returns "yeah okay, but no content for you".
If you are on website.com/some/page and you (somehow) navigate to website.com/some/page/undefined the browser will show the URL as changed but will not even do a page reload. The previous page will stay as it was in the window.
If for some reason this is something experienced by users then they will have a clean noop experience and it will not disturb whatever they were doing.

This sounds like a race condition where a variable is not getting properly initialized before getting used. Considering this is not an AJAX issue according to your comments, there will be a couple of ways of figuring this out, listed below.
Hookup a Javascript exception Logger: this will help you catch just about all random javascript exceptions in your log. Most of the time programmatic errors will bubble up here. Put it before any scripts. You will need to catch these on the server and print them to your logs for analysis later. This is your first line of defense. Here is an example:
window.onerror = function(m,f,l) {
var e = window.encodeURIComponent;
new Image().src = "/jslog?msg=" + e(m) + "&filename=" + e(f) + "&line=" + e(l) + "&url=" + e(window.location.href);
};
Search for window.location: for each of these instances you should add logging or check for undefined concats/appenders to your window.location. For example:
function myCode(loc) {
// window.location.href = loc; // old
typeof loc === 'undefined' && window.onerror(...); //new
window.location.href = loc; //new
}
or the slightly cleaner:
window.setLocation = function(url) {
/undefined/.test(url) ?
window.onerror(...) : window.location.href = url;
}
function myCode(loc) {
//window.location.href = loc; //old
window.setLocation(loc); //new
}
If you are interested in getting stacktraces at this stage take a look at: https://github.com/eriwen/javascript-stacktrace
Grab all unhandled undefined links: Besides window.location The only thing left are the DOM links themselves. The third step is to check all unhandeled DOM links for your invalid URL pattern (you can attach this right after jQuery finishes loading, earlier better):
$("body").on("click", "a[href$='undefined']", function() {
window.onerror('Bad link: ' + $(this).html()); //alert home base
});
Hope this is helpful. Happy debugging.

I'm wondering if this might be an adblocker issue. When I search through the logs by IP address it appears that every request by a particular user to /folder/page.html is followed by a request to /folder/undefined

I don't know if this helps, but my website is replacing one particular *.webp image file with undefined after it's loaded in multiple browsers. Is your site hosting webp images?

I had a similar problem (but with /null 404 errors in the console) that #andrew-martinez's answer helped me to resolve.
Turns out that I was using img tags with an empty src field:
<img src="" alt="My image" data-src="/images/my-image.jpg">
My idea was to prevent browser from loading the image at page load to manually load later by setting the src attribute from the data-src attribute with javascript (lazy loading). But when combined with iDangerous Swiper, that method caused the error.

Firefox 'Error loading script' loading Google Analytics in FF2

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.