1272833 - XMLHttpRequest is aborted by browser

Status: RESOLVED DUPLICATE of bug 1269055

(Core :: General, defect)

Description

[Mahks]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

Steps to reproduce:

Intermittent


Actual results:

Since FF 46 became current version, I am seeing intermittent aborts of POST XMLHttpRequests. (have not noticed any GET failures)

In DevTools Network the call has a grey status circle & has no status number. The response tab is empty. In Firebug the status shows as aborted.

Users do not experience these failures in Chrome.
Users are located around the world (not a local issue).

I realize it would be difficult to solve this without a test case, but with it being intermittent this is hard to create. I am looking for help as to how to narrow down what the cause is so I can create a test case for you.

Comment 1

[Mahks]

Both Windows & Linux users have had the problem,

Comment 2

[Loic]

It's probably a dupe of bug 1269055 which is fixed in 47+. Reopen the bug if that's not the case.

Comment 3

[Anand]

Hi Loic, I could able to successfully run my application with 47+ beta version. Do we have any timeline on when 47+ will be available for end users in normal version?

Comment 4

[Loic]

2016-06-07 for FF47, see https://wiki.mozilla.org/RapidRelease/Calendar

Comment 5

[Liz Henry (:lizzard)]

Anand, and Mahks, here's a suggestion from our developers for a workaround:  Adjust your server side persistent connection timeout to be about 5 seconds longer than the firefox value. Firefox uses 115 seconds for HTTP/1.x and 180 seconds for HTTP/2.  

Hope that helps. If you try it, please let us know the result.

Comment 6

[Mahks]

When the issue happens the XMLHttpRequest typically returns a readyState of 4 in less than a second.
No abort or error event is triggered and responseText is empty.

As far as I can tell the request is not hitting a connection timeout.


By "persistent connection timeout" do you mean mysql.connect_timeout? 
It is set to 60 and is not configurable as it is a shared server.

Is this the network.http.keep-alive.timeout I see in about:config? (default 115)
If I had a few users set this to 100, would that accomplish the same objective as your request to increase the server setting?

Comment 7

[Loic]

Mahks, did you test Beta 47?
https://www.mozilla.org/en-US/firefox/beta/all/

Comment 8

[Mahks]

I have not seen it in 47, but it occurs in less than 1% of requests. In fact I have only had this happen to my browser a few times (luckily once I had the tools/network active and saw the strange status of the request which help me realize it was not a connectivity issue)

It is mostly my users that are affected, I put some tracking into the page to log the occurrence and try to narrow the cause, so now I can see each time it happens. I have asked several to try 47, but none have, unfortunately most moved to chrome, which does not have the problem.

I think one reason you have not had a lot of reports about this, though I see more are coming in, is that it is hard to tell that this is not a connectivity problem. The first week, I ignored it as I assumed that. Then I saw that aborted status an realized it was browser based. Blamed my code until I found Chrome did not exhibit the behaviour.

Regarding the timeout possibility, I have a 10 second timeout built into my XMLHttpRequest function, none of these failed requests last even that long.

Comment 9

[Patrick McManus [:mcmanus]]

mahks - just to be clear the timeout in comment 5 that needs to be set is on the server - not in your xhr code.

the trigger happens after a successful http transaction has taken place and the connection has gone idle. There is some waiting around and then one of three things eventually happens - 1] the connection is reused for another transaction, 2] the client closes the connection, or 3] the server closes the connection.

Unfortunately it is possible for both 3 and 1 to happen at basically the same time. The server closes the session down while firefox is trying to send a new request on the connection - that results in an error happening very quickly (as you see).

The versions other than 46 this transaction is replayed onto a new connection for you. In 46 your XHR code receives an error instead when the transaction uses POST.

the workaround increases the amount of idle time allowed on the server so that #3 doesn't happen - either the transaction goes through or firefox closes the connection by itself. That should make things more robust

Alternatively, if you have control over the javascript you can also handle the error there by replaying it manually (in a new xhr).

47 will be out in about 2.5 weeks.

Comment 10

[Mahks]

"just to be clear the timeout in comment 5 that needs to be set is on the server - not in your xhr code." I understand. So can I change that setting in about:config to accomplish the test Liz suggested?

Yau said "In 46 your XHR code receives an error instead when the transaction uses POST"

But it is not receiving an error.

On that request I saw there was no status value for the request, should it not be 408?
The status icon that should be red for an error, was grey.

The error event on the XMLHttpRequest has not triggered on any of the failures since I began tracking that event.

Comment 11

[Mahks]

One of my users has been on FF47 for about 12 hours now and has not experienced the failure. 
He would normally have seen it at least half a dozen times in 12 hours.

Your comment :
"Unfortunately it is possible for both 3 and 1 to happen at basically the same time. The server closes the session down while firefox is trying to send a new request on the connection..."

I don't think this is what is happening with my issue. Often the failure happens within the timeout limit. The server would not have closed the session yet. (The request that fails can be sent within a second of a previous successful one)

Comment 12

[Firefox Bug Husbandry Bot]

Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598