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

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Dave]

Attachment: firefox-file-upload-repro.xpi

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]);

        $.ajax({
            url: "http://example.com",
            data: formData,
            cache: false,
            contentType: false,
            processData: false,
            type: 'POST'
        })
        .done(function(response) {
            console.log("Success!");
            console.log(response);
        })
        .fail(function(jqxhr, status) {
            console.log("*sad trombone*");
            console.log(jqxhr.statusText);
        });



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/[e-mail]!/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 http://example.com/. This can be fixed by moving the resource to the same domain or enabling CORS."

Comment 1

[Matthias Versen [:Matti]]

Could you find the regression range with our mozregression tool ?
- http://mozilla.github.io/mozregression/

Comment 2

[Dave]

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)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=daa84204a11a&tochange=dc352a7bf234

No more inbounds to bisect
Last good revision: 0ed4b3b8d79b
First bad revision: dc352a7bf234
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0ed4b3b8d79b&tochange=dc352a7bf234

Comment 3

[Matthias Versen [:Matti]]

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 
>http://example.com/. 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

[Dave]

The latest Firefox 34 candidate still exhibits the issue (https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/34.0b2-candidates/build1/mac/en-US/).

The very latest nightly build appears to be fixed. (https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-36.0a1.en-US.mac.dmg)

It would be wonderful to get a fix for this issue pushed out with the upcoming Firefox 34 release :-)

Comment 5

[Matthias Versen [:Matti]]

>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)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d66436af432&tochange=7c24470b6b3a

Comment 6

[Matthias Versen [:Matti]]

the Last not working revision:
https://hg.mozilla.org/mozilla-central/rev/8c47153a1dd1

First revision that fixed the issue
https://hg.mozilla.org/mozilla-central/rev/090b62fdfd21

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.

Comment 7

[Peter Van der Beken [: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.

Comment 8

[Matthias Versen [:Matti]]

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

Comment 9

[Paul Oiegas [:poiegas], PM for (Ecosystem QA, Services QA, WebCompat QA, Hubs QA teams)]

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 ?

Thanks,
Paul