720059 - xmlhttprequest

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[jacobtopper]

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1

Steps to reproduce:

I made an xml http request like so on the latest fennec nightly
  var xhr = Cc["@mozilla.org/xmlextras/xmlhttprequest;1"].createInstance(Ci.nsIXMLHttpRequest);
  xhr.onreadystatechange = function(evt) {
	L.log("readystate changed to " + xhr.readyState);
	if (xhr.readyState == 4) {
	  L.log("response = " + xhr.responseText);
	}
  };
  xhr.open('POST', "https://my_login_url", true);
  xhr.send('username=username&password=password');


Actual results:

1. the protocol handler's newURI function was called for the url I gave  when I called open. 
2. the protocol handler's newURI function was called again, but this time it was passed the base of the url (minus /api/login in my case) and a null baseURI
3. I saw readyStates 2 and 4, but it skipped 3
4. the responseText is null


Expected results:

1. the protocol handler's newURI function was called for the url I gave  when I called open. 
2. I readyStates 2, 3, and 4 print
3. I have non-null responseText

This is what happens in a version of fennec that I built at least. I built it based on nightly source from about 2 weeks ago I believe but I can look up a specific date if need be.

Comment 1

[jacobtopper]

After a bunch more digging I've discovered that using an http url instead of an https one seems to make things work. That's not really a viable work around for a login which is what I'm doing, but at least it narrows things down.

Comment 2

[jacobtopper]

I think I figured the behavior out now. I checked 3 times to make sure I wasn't crazy. I found that if I was running a fresh copy of fennec and I made my request with https it would fail. However, if I made the request with http, then I would be able to make it with https thereafter.

Comment 3

[jacobtopper]

I did a test again yesterday in the hopes of producing a test case and realized that in the 1/30/2012 build the problem no longer seems to exist.

Comment 4

[Gervase Markham [:gerv]]

Resolving WFM based on comment 3.

Gerv