1506562 - The use of webRequest.onBeforeRequest with 'requestBody' is corrupting certain XMLHttpRequest in websites

Status: RESOLVED FIXED

(WebExtensions :: Request Handling, defect, P3)

Description

[Wojciech Walek [:wojwal]]

I found this bug in 63.0.1 - but I guess earlier releases are also affected. 

I am using certain Javascript code that is uploading binary data using XMLHttpRequest, data is prepared in Blob, but ArrayBuffer causes the same issue. One important thing is that this happens for larger size data (above 1MB) - for some reason smaller requests are not affected, and works fine.

Sample Javascript code
">
	var size = 2 * 1024 * 1024;
	var longInt8View = new Uint8Array(size);
	for (var i = 0 ; i < size ; i++) {
		longInt8View[i] = Math.floor(Math.random() * 256);
	}
			
	var blob = new Blob([longInt8View]);
		
	var xhr = new XMLHttpRequest();
	xhr.open("POST", window.location.href, true);
	xhr.setRequestHeader("Content-Type", "application/octet-stream");
    	xhr.upload.onprogress = function(e) {
    		var progress = e.total > 0 ? Math.floor((e.loaded / e.total) * 100) : 0;
			console.log("PROGRESS " + progress + "%", e);
    	}
	xhr.onload = function() {
		console.log("SUCCESS");
	}
	//xhr.send(longInt8View);
	xhr.send(blob);
"

Keep in mind above is just website JS - not extension related. But I am also using extension and eventually I found out that the use of "webRequest.onBeforeRequest" with "requestBody" is causing above Javascript to fail (it's hanged actually).

Sample Javascript extension code that is causing the issue:
">
	chrome.webRequest.onBeforeRequest.addListener(function(e) {
		//empty
	}, {urls: ["<all_urls>"], types: ["xmlhttprequest"]}, ['requestBody']);
"

When I commented out above empty listener - the issue is not happening. And when above listener is used browser console shows following errors:

">
[Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsISeekableStream.seek]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: resource://gre/modules/WebRequestUpload.jsm :: rewind :: line 144"  data: no]

Handler function threw an exception: [Exception... "Component returned failure code: 0x80470002 (NS_BASE_STREAM_CLOSED) [nsISeekableStream.tell]"  nsresult: "0x80470002 (NS_BASE_STREAM_CLOSED)"  
"

And after some time of progress beeing hanged eventually it finishes and Browser Console additionally shows:
NotFoundError: The operation failed because the requested database object could not be found. For example, an object store did not exist but was being opened.
">

"

Comment 1

[Wojciech Walek [:wojwal]]

Attachment: browser-console.png

Comment 2

[Erik Moeller]

I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1532530 which may be related or have the same root cause, but note that it does not require the use of XmlHttpRequest, nor do I see the same error messages on the console.

Because the NoScript extension uses this listener, the issue is having major downstream effects for Tor browser users and associated projects.

Comment 3

[Rob Wu [:robwu]]

Bug 1532530 could also have been caused this bug. The screenshot shows that the caller of rewind is createFormData, which suggests that the stream was invalidated by the parseFormData call.

In bug 1532530, the data loss was caused by the stream being closed as a side effect of garbage collection. The error messages in the stack trace complain about the stream being closed, which also suggests that the two caused of the bugs may be identical.

I was not able to reproduce the bug in Firefox 66.0.1 (not on localhost, neither on an intranet).
Wojciech, could you check whether the bug still occurs in Nightly (version 68.0a1 buildID 20190326095147 or newer)?

Comment 4

[Wojciech Walek [:wojwal]]

Hi guys,

Looks like you can close this ticket - just checked - and I don't see this issue anymore... I rolled back to FF 63.0.1 that I reported it for - and issue is there. I also tried FF 64.0.2 and looks like it was fixed along with FF 64

Thanks

Comment 5

[Rob Wu [:robwu]]

This bug appears to be unrelated to bug 1532530.

I did a bisect and found that the bug was fixed by the patch for bug 1494176 .