File upload via FormData + $.ajax from within an extension content script is broken in Firefox 33




4 years ago
3 years ago


(Reporter: bugzilla, Unassigned)



33 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)



(1 attachment)



4 years ago
Created attachment 8509040 [details]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36

Steps to reproduce:

From the context of a Firefox extension content script, code to upload a file that worked prior to Firefox version 33 is now failing.

1. Install the attached "firefox-file-upload-repro.xpi" extension.
2. Browse to any page, notice that the extension injected a file input at the top of the page.
3. While watching the developer console for results, select a file for upload.

Alternatively, execute the following code (which uses jQuery) from within the context of an extension content script:

        var formData = new FormData();
        formData.append("name", <file input element>.files[0]);

            url: "",
            data: formData,
            cache: false,
            contentType: false,
            processData: false,
            type: 'POST'
        .done(function(response) {
        .fail(function(jqxhr, status) {
            console.log("*sad trombone*");

Actual results:

Since Firefox 33, the request fails *before* initiating a network connection with the following error:

"[Exception... "JavaScript component does not have a method named: "available"'JavaScript component does not have a method named: "available"' when calling method: [nsIInputStream::available]"  nsresult: "0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "JS frame :: resource://gre/modules/addons/XPIProvider.jsm -> jar:file:///Users/dmills/Library/Application%20Support/Firefox/Profiles/z61gll4r.default/extensions/jid1-T5mdAATMX3urKA@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/loader/sandbox.js -> resource://jid1-eemyweqy0j38aw-at-jetpack/firefox-file-upload-repro/data/jquery-1.11.1.js :: .send :: line 9631"  data: no]"

Expected results:

The request should successfully upload the selected file. Or, in the case on the "firefox-file-upload-repro.xpi" extension, it should fail with the following message:

"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at This can be fixed by moving the resource to the same domain or enabling CORS."
Could you find the regression range with our mozregression tool ?

Comment 2

4 years ago
mozregression results: 

Got as far as we can go bisecting nightlies...
Ensuring we have enough metadata to get a pushlog...
Last good revision: daa84204a11a (2014-08-25)
First bad revision: dc352a7bf234 (2014-08-26)

No more inbounds to bisect
Last good revision: 0ed4b3b8d79b
First bad revision: dc352a7bf234
Thank your very much for doing the regression range search but there is no apparent checking in that changelog that would explain this :-(

I've tried your extension+STR with a Firefox trunk builds and got :
>Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at 
> This can be fixed by moving the resource to the same domain or enabling CORS. 

According to your comment this means that it works as expected
Can you try a nightly build and see if your issue is already fixed ?

Comment 4

4 years ago
The latest Firefox 34 candidate still exhibits the issue (

The very latest nightly build appears to be fixed. (

It would be wonderful to get a fix for this issue pushed out with the upcoming Firefox 34 release :-)
>It would be wonderful to get a fix for this issue pushed out with the upcoming Firefox 34 release :-)
That can only happen if the patch that fixed this issue will be uplifted to that branch.
This can be requested but i do not know which patch fixed the issue because and i get server errors for inbound builds at the moment. I will try that tomorrow again.

This is the comm-central part of the mozregression test for finding the FIX (good means broken behavior in this case)

Last good revision: 9d66436af432 (2014-09-29)
First bad revision: 7c24470b6b3a (2014-09-30)
the Last not working revision:

First revision that fixed the issue

fixed by bug 787070

I doubt that Peter wants to uplift this but asking anyway.

Peter: You checkin fixed this bug that is happening with Firefox33 and the Firefox34 branch and the reporter is asking for an uplift in comment#4.
Flags: needinfo?(peterv)
That patch is unfortunately not suitable for uplifting. Without the regressing changeset and a clear understanding of the bug we can't cherrypick something form it either.
Flags: needinfo?(peterv)
this bug is a regression from bug 1041731 and was fixed by bug 787070 (confirmed with local builds)

peter: You decide, please close this as worksforme if you do not want to fix this on FF34, thanks
Blocks: 1041731
Ever confirmed: true
Keywords: regression
Hi guys,

Since this was not marked as "worksforme"(judging by the latest post), can I assume it was uplifted in FF34 and mark it as resolved ?

Flags: needinfo?(bugzilla)
Last Resolved: 3 years ago
Flags: needinfo?(bugzilla)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.