Closed
Bug 1086993
Opened 10 years ago
Closed 9 years ago
File upload via FormData + $.ajax from within an extension content script is broken in Firefox 33
Categories
(Firefox :: Untriaged, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bugzilla, Unassigned)
References
Details
(Keywords: regression)
Attachments
(1 file)
90.53 KB,
application/zip
|
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]);
$.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/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 http://example.com/. This can be fixed by moving the resource to the same domain or enabling CORS."
Comment 1•10 years ago
|
||
Could you find the regression range with our mozregression tool ?
- http://mozilla.github.io/mozregression/
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•10 years ago
|
||
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 ?
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•10 years ago
|
||
>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•10 years ago
|
||
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.
Flags: needinfo?(peterv)
Comment 7•10 years ago
|
||
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)
Comment 8•10 years ago
|
||
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•9 years ago
|
||
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
Flags: needinfo?(bugzilla)
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(bugzilla)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•