We Keep Coding

XMLHttpRequest takes very long only in Internet Explorer

We have recently noticed an issue where a common page on our site temporarily freezes when navigated to from Internet Explorer with the message "This web page is not responding due to a long running script".
After investigating, I can see that it is caused by an AJAX XMLHttpRequest that is taking 30 - 45 seconds to complete. Normally when there are performance issues with our AJAX calls like this, the long wait time is during the wait for the server's response. But here, it is the wait to create the request and send it that is taking so long:
Note that there are no issues with this request in Google Chrome at all, it only takes 200ms:
These results are consistent on every page refresh. Note also that this is not a large request nor a large response. The request body is actually empty:
and the response is quite small:
I figured since the problem appears to be client-side, there must be something off with our scripts, but we use the same generic function for all of our AJAX calls and don't have this problem with anything else:
JSONRequest: function (url, type, data, success, error) {
var customError = function (er) {
console.log(er);
}
if (error !== 'undefined' && error != null)
customError = error;
$.ajax({
url: url,
type: type,
cache: false,
data: JSON.stringify(data),
contentType: 'application/json; charset=utf-8',
success: success,
error: customError
});
},
I am quite puzzled here. Is this simply a matter of "Avoid IE", or is there something I am missing? 30+ seconds to create a small request and send it seems absurdly long, especially when it is fast in Chrome. What gives?
*Note that I am testing with IE 11.

For some reason, a line of JQuery that unchecks all check boxes in a list of them was causing the issue:
$('.list-check-buttons.check-button.only-button input:checkbox').prop('checked', false)
I verified this by stepping through in the Chrome Debugger and also removing this line resolved the issue for the most part. (It turns out we didn't need this line as the same logic was also being handled in another place which strangely enough was not causing performance issues.)

Differentiate between different error types on image load

I'm playing around with implementing a JavaScript server ping tool based on the accepted answer given on this question: Is it possible to ping a server from Javascript?. This essentially works by assuming the pinged server is down if no response has been given after n milliseconds.
That's great, and it's a pretty cool way of doing it, however there are two rather large pitfalls:
Not all servers do respond within the allocated time.
Sometimes an ERR_CONNECTION_TIMED_OUT error is thrown before our timeout timer has finished.
Both of these things cause incorrect results. The former suggests that the server is offline when it's possibly online and responding slowly, and the latter suggests the server is online when it's (likely) offline.
In an ideal world this code would capture what type of error thrown was thrown and handle this appropriately. After all, if the error thrown is a 404 Not Found error, this counter-intuitively means the server is online and has responded.
If we log the image error event, the only thing we see surrounding the error is:
Event {
...
type: "error"
}
There's no message or anything hinting at what the error thrown was, and both the 404 and ERR_CONNECTION_TIMED_OUT errors give identical information.
What can I do to capture the ERR_CONNECTION_TIMED_OUT error I see in Chrome's JavaScript console, rather than relying on a fixed-speed timer?
Update
The best way I can replicate this issue is by altering Trante's JSFiddle demo (as linked to in the question I've linked above) to use a 30000ms timer rather than a 1500ms timer:
this.timer = setTimeout(function () {
if (_that.inUse) {
_that.inUse = false;
_that.callback('timeout');
}
}, 30000);
The 'unknown' server should obviously not respond, but instead we see this:
In Chrome's console, the following error has been thrown:
Failed to load resource: net::ERR_NAME_NOT_RESOLVED
As the Image's onerror function has been fired with the generic error as given above, the function believes this to mean that 1. 'unknown' exists, and 2. it's online. The ERR_NAME_NOT_RESOLVED error appears to be something which only Chrome is aware of, and isn't passed through to the error event at all.
Update 2
Today I tried doing this with web sockets instead of images and unfortunately these suffer from the same problem. The only data surrounding the error returned is type: "error" - no information about what the error actually was.

EmberData find request isRejected, how do I debug this?

I'm having a similar problem as: Find operation (AJAX request) rejected, not seen in the wire
However, in my case, I am making one request. This request works on normal page load. It fails to load silently after a form submit (not through ember), that redirects back to the same page. There is no AJAX request being made.
My main question is: how do I go about debugging issues like this?
What I've Tried
I've added console.log statements in all sorts of places to understand the request lifecycle.
Since I've read that promises can get rejected if something throws an exception within it, I've tried switching the chrome debugger to "Pause on all exceptions" (as opposed to "Pause on uncaught exceptions"). Of course it breaks at a bunch of exceptions like:
// This should fail with an exception
// Gecko does not error, returns false instead
try {
matches.call( div, "[test!='']:sizzle" );
But since I have a way to get the request to work and a way to get it to not work, I can easily compare the difference. I expected there to be an uncaught exception when my request failed, but no such luck.
I've also added a
Ember.RSVP.configure('onerror', function(error) {
console.log(error.message);
console.log(error.stack);
});
block, but it does not get called.
I've also poked around at different objects in the console to try and understand my application state:
store = App.__container__.lookup('store:main')
b = store.find('bundle')
b.isRejected // => true
b.reason.statusText // => "error"
Update: More Details
The project I am working on is backed by rails. I am using:
DEBUG: -------------------------------
DEBUG: Ember.VERSION : 1.0.0
DEBUG: Handlebars.VERSION : 1.0.0
DEBUG: jQuery.VERSION : 1.8.3
DEBUG: -------------------------------
And it doesn't show up in the debug output, but I'm using ember-data 1.0 beta 3:
// Version: v1.0.0-beta.3
// Last commit: 2259c27 (2013-09-28 19:24:07 -0700)
The app loads all of the bundles to render them and a form, but the form submits directly to rails. Rails processes the post request and redirects back to /, where the ember app lives.
The first request to / loads everything fine, but when I submit the form, and it redirects back, that's when my ajax call my call to store.find('bundle') does nothing.
UPDATE
I've discovered that my issue is related to pusher (websockets).
The issue seems intermittent and I've only seen it in Chrome (I've only tested Firefox).
The issue went away when I disconnected from websockets before a page refresh.

In your case the fail handler is receiving the jQuery XMLHttpRequest. Try to see what responseText and status is returning.
App.__container__.lookup('store:main').find('bundle').then(null, function(reason) {
reason.responseText // response from the server, maybe can show an error page in html
reason.status // 404 page not found, 500 some server error you will need to chech the logs etc.
});
I hope it helps

JSON object becomes 'null'

I've been having trouble with my html5 web worker. The web worker postMessage()'s a JSON object to the document-level javascript that invoked the worker, which comes with an onmessage() function.
Apparently the "iterationsjob" key can be accessed as the worker can process the associated number value, but this seems to only work in Google Chrome and it still raises the error:
18Uncaught TypeError: Cannot read property 'iterationsjob' of null
In Firefox, the web worker does not work at all and doesn't seem to be able to access the numbers either, I'm getting a successful ajax call but it seems to bypass the logging steps and raise another error with a separate ajax call.
So I hacked together a basic way for workers to log() messages back to the console, and invoked them from within the worker:
var iterations
//get iteration data from the server
p.ajax.post({
url:'/getdataurl',
dataType: "json",
success: function(responseText){
log("test");
log("responseText is "+responseText);
iterations = responseText.iterationsjob;
log("iterations is "+iterations);
}
});
I expected to see the following:
test
responseText is [object Object]
iterations is 3993547
Instead, I see:
test
responseText is [object Object]
iterations is 3993547
test
responseText is null
Uncaught TypeError: Cannot read property 'iterationsjob' of null
Could anybody explain what the problem is and how to fix it?
EDIT: I've uploaded a zip of the source code here. Runs on Google App Engine.
Thanks! any help much appreciated.

Ah, turns out that I needed to add an empty success callback function to the second ajax call. for some reason it calls the first success callback by default if there is none defined...

JQuery Ajax post parameters sometimes not sent on IE

The problem I am having is that when I use jquery ajax post, with very low frequency (< 2%), the post parameters never make it to the server. I do see the post request in the access log. It seems to happen only on IE (I've observed it on 7, 8, and 9 in the logs).
When I switch the call from type "post" to type "get" the issue goes away.
Has anyone else ever seen this odd behavior on IE? Thanks!
I have seen this for various ajax calls, but here is a typical one:
var data= {
"guess" : "m1",
"eas" : "hello world"
};
$.ajax({
url: "http://myco.com/ajaxcall.action",
data: data,
type : 'post',
dataType: 'json',
success: function(data) {},
error: function() {}
});
Update: passing "cache: false" does not fix the issue.

I have spent the last week tracking down a similar problem in my own application (uses Dojo, not JQuery). From your description and frequency of occurrence, I would say it's the same issue.
When HTTP persistent connections are used between browser and server (the default behavior), an HTTP connection can be closed down by the server at any time. This creates a very small timing hole when the browser starts to send a new request at the same time the server closes the connection. Most browsers will use a different connection or open a new connection and resend the request. This is the behavior suggested in RFC 2616 section 8.1.4:
A client, server, or proxy MAY close the transport connection at any
time. For example, a client might have started to send a new request
at the same time that the server has decided to close the "idle"
connection. From the server's point of view, the connection is being
closed while it was idle, but from the client's point of view, a
request is in progress.
This means that clients, servers, and proxies MUST be able to recover
from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted sequence of requests
without user interaction so long as the request sequence is
idempotent (see section 9.1.2).
Internet explorer does try to resend the request when this happens, but when it happens to be a POST, it mangles it up by sending the headers (with Content-Length) but no actual data. That is a malformed request and should always lead to an HTTP error (usually after some timeout waiting for the data that never comes).
This bug is documented by Microsoft as KB 895954 (see http://support.microsoft.com/kb/895954). Microsoft first recognized this bug in IE 6. They provided a hotfix, and appear to have shipped the hotfix with every version of IE since then including IE 9. There are two problems with the fix:
The hotfix is not activated by default. You have to create a really weird key using regedit to activate the fix: HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_SKIP_POST_RETRY_ON_INTERNETWRITEFILE_KB895954.
The fix doesn't really fix the problem. The "fixed" behavior is that when the connection is closed when trying to send a request, it does not even try to resend it. It simply passes the error along to the javascript application.
It appears that you have to add error handlers in your code and re-post the request yourself if it fails. I am looking into this solution for my application. My concern is that I'm not sure how to tell if the error I get is caused by a failed attempt to send the query, or some error sent back from the server as a result of the query (in which case I don't want to resend it).
I wrote a C program to simulate a web server and explicitly close a connection to see how the browser handles it. I have found that IE reproduces the errant behavior 100% of the time, while Firefox, Safari and Chrome recover by properly resending the POST on another connection 100% of the time. Perhaps the answer is, "don't use IE."

As a direct answer to your question: Yes we have just come across this issue and could not find a reasonable explanation. It only affects IE and with a very low frequency - took a long while to get to the conclusion that it is a sporadic jQuery Ajax in IE bug. We had to 'fix' the issue by returning a fail from the server under this condition and re-posting the data after a 1 second delay!
Hacky as hell but seemed to be the only way.
There was definitely no clash with DOM elements etc. and no logical reason for this to happen, the page can be updated many times by the user successfully with intermittent fails.
Must be a bug.

I think you have to prevent caching in Internet Explorer. Try to set option cache to false.
Example:
$.ajax({
url: "http://myco.com/ajaxcall.action",
data: data,
type : 'post',
dataType: 'json',
success: function(data) {},
error: function() {},
cache: false
});

The params sent to the PHP are received from IE in GET:
$.ajax ({
url: "path/to/ajax.php"
,method: "POST"
,data: {
var1: "value1"
,var2: true
,varX: 123123
}
,cache: false
,success: function (data) {
alert (data);
}
});
Then on PHP you should use REQUEST instead of POST:
$var1 = $_REQUEST ["var1"]; // value1
$var2 = $_REQUEST ["var2"]; // true
$var3 = $_REQUEST ["var3"]; // 123123
This example could use it for compatibility with IE7