github.christian Reporter
	Description • 7 years ago

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171010220102

Steps to reproduce:

I try to load a file with XMLHttpRequest:
var xmlHttpRequest = new XMLHttpRequest ( );
xmlHttpRequest.onreadystatechange = function ( event ) {
	if ( this.readyState === XMLHttpRequest.DONE ) {
		if ( this.status === 200 ) {
			_LoadFile ( this.responseText,'', true );
		} 
	}
};
xmlHttpRequest.open ( 'GET', serverUrl, true	) ;
xmlHttpRequest.send ( null );



Actual results:

The error occurs when trying to access the responseText, specially when the size of the responseText is hight ( 200kb). Sometime its working when trying to restart the request. 
I have replaced the _LoadFile(...) with a simple console.log (this.responseText) and I have the same error.
No problems with Firefox 55 or 57...

	Pascal Chevrel:pascalc (PTO until August 21)
	Comment 1 • 7 years ago

I can't reproduce with Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 ID:20171010220102 and a 500kb remote json file

	Ben Kelly [:bkelly, not reviewing]
	Comment 2 • 7 years ago

Andrea, is this something you fixed in blob changes recently?

	Andrea Marchesini [:baku] Assignee
	Comment 3 • 7 years ago

(In reply to Ben Kelly [:bkelly] from comment #2)
> Andrea, is this something you fixed in blob changes recently?

I don't see the use of responseType='blob' here.

Hi Christian, thanks for your report. I have a couple of questions:

1. does it happen with a file:// URL or http/https?
2. can you share a test file?

	github.christian Reporter
	Comment 4 • 7 years ago

Hi,

you can test eventually with this link: 
http://dev.ouaie.be/TravelNotes/?fil=aHR0cDovL2Rldi5vdWFpZS5iZS9tYXBzZGF0YS9Ucm9tc28wLnRydg==

The string aHR0cDovL2Rldi5vdWFpZS5iZS9tYXBzZGF0YS9Ucm9tc28wLnRydg== in the url is the path of the file loaded with the XMLHttpRequest and base64 encoded (-> http://dev.ouaie.be/mapsdata/Tromso0.trv ). If everything work correctly you must have a map of north Norway on your screen. See eventually the console for the NS_ERROR_UNEXPECTED message.
The file have a .trv extension but is a json file.

my Javascript code is on Github: https://github.com/wwwouaiebe/leaflet.TravelNotes/blob/master/src/core/TravelEditor.js See starting line 349.

	Andrea Marchesini [:baku] Assignee
	Comment 5 • 7 years ago

I cannot reproduce it. Can somebody help testing this?

	github.christian Reporter
	Comment 6 • 7 years ago

attached index.html for tests

	github.christian Reporter
	Comment 7 • 7 years ago

Attached test.json for tests. See also my comments

	github.christian Reporter
	Comment 8 • 7 years ago

I have attached 2 files to the bug. Save the files index.html and test.json in the same folder and open the index.html and look the console.
It'seems to be not stable and  can occurs with file:// and http//. When I open the attached file with the file:// I have the error - see copy of the console below -

file:///C:/Users/Christian/Documents/shared/tmp/test.json
index.html:11:4
Erreur d’analyse XML : erreur de syntaxe
Emplacement : file:///C:/Users/Christian/Documents/shared/tmp/test.json
Numéro de ligne 1, Colonne 1 :
test.json:1:1
NS_ERROR_UNEXPECTED: 
index.html:16

And when I put the files on my server ( http://dev.ouaie.be/bug1407573/ ) I don't have any problem.
But when I have created the bug the problem occurs with http://

Also no problem with the file:// when I reduce the size of the json file.

My computer is a Windows 10 64 bits and I don't have any extra modules loaded with firefox.

	Andrea Marchesini [:baku] Assignee
	Comment 9 • 7 years ago

http://searchfox.org/mozilla-central/source/dom/xhr/XMLHttpRequestMainThread.cpp#2738-2748

Here the reason why we have this issue. We try to parse the content as XML.

	github.christian Reporter
	Comment 11 • 7 years ago

I agree that the mime type is the problem ( and the bad idea to change the file extension from .json to .trv ).
When I add a "xmlHttpRequest.overrideMimeType ( 'application/json' )" in my JavaScript code everything work fine and also when I use .json as extension file (in this case the server add a contentType 'application/json' in the response headers).

Now the last question: my (bad) code work with FF 56, FF 57, MS Edge and Vivaldi (not tried others browsers) and I'm affraid that you will find a lot of code like this on the internet. So it's a bug in FF 58 or not?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 12 • 7 years ago

So this is a regression from bug 1070763?

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 13 • 7 years ago

Comment on attachment 8918335 [details] [diff] [review]
xhr_file.patch

Since the relevant code seems to come from bug 1070763, perhaps Thomas could look at this first.

	Thomas Wisniewski
	Comment 14 • 7 years ago

Comment on attachment 8918335 [details] [diff] [review]
xhr_file.patch

Yes, this looks like a good fix to me. Sorry for not replying to this sooner, I'm still on PTO until Monday and so have been a bit busy.

And now that I look at this, I'm hopeful that it will fix the other bugs reported related to bug 1070763 and its follow-up, bug 1405571.

(We should of course try to land a test-case as well, whether it's part of this patch or a follow-up).

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 15 • 7 years ago

Comment on attachment 8918335 [details] [diff] [review]
xhr_file.patch

Review of attachment 8918335 [details] [diff] [review]:
-----------------------------------------------------------------

I don't see a reason why we would only want to call AppendToResponseText(nullptr, 0, true); if the response body is empty. Hence, r-.

I suggest we close this bug and roll fixes to the fallout from bug 1070763 into the relanding of bug 1070763.

I guess I shouldn't have r+'ed the patch for bug 1405571 on the basis that there is an NS_ENSURE_STATE per bug 1405571 comment 14, since that's probably where this bug came from. Sorry.

Ideally, we should make the CORS proxy not cause double calls to OnStopRequest. Failing that, we need to be careful to show only happy NS_OK on the second OnStopRequest.

	Andrea Marchesini [:baku] Assignee
	Comment 16 • 7 years ago

Good to me.