The default bug view has changed. See this FAQ.

Allow naming blob URL

RESOLVED FIXED in mozilla22

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: BenWa, Assigned: evilpie)

Tracking

unspecified
mozilla22
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox -)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
I've tried several variation of MozBlobBuilder but I can't get it to name the blob URL. I'm looking to set the default download file name to something useful rather then a UUID like 'Profile-<data>.dat'.

Here is my repo:
https://github.com/bgirard/cleopatra/blob/master/js/ui.js#L639

I've tried:
var blob = bb.getFile("test.zip", "application/octet-stream");
or
bb.append('file', gRawProfile, "test.zip");

This post suggest that other browser support this but it doesn't appear to be in the w3c spec:
http://stackoverflow.com/questions/8495301/changing-filename-in-blobbuilder-to-be-passed-as-formdata-on-xhr
(Reporter)

Comment 1

5 years ago
Correction it is in the spec:
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-append%28%29-method
My guess is that we need to stick the filename on the channel we create in the blob protocol handler.
(In reply to Benoit Girard (:BenWa) from comment #1)
> Correction it is in the spec:
> http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-append%28%29-method

The spec you're quoting is for FormData, not BlobBuilder ...
> My guess is that we need to stick the filename on the channel we create in the blob
> protocol handler.

Assuming you have the filename there, yeah.  You'll need to change nsBaseChannel to allow setting (and usefully getting) a content-disposition or at least a content disposition filename.

Comment 5

5 years ago
This is a duplicate of Bug #690659
No, it's not.  There's no FormData involved here.

Comment 7

5 years ago
Both bugs imply the same thing: Allow adding the Filename of a blob you're uploading. Both bugs point to the same standard to implement the same functionality. Please, explain how both aren't the same?
No they don't.  This bug is about how even if you have a filename on the blob, if you feed Firefox the blob URL the filename does not get used by the download manager.  The link in comment 1 has nothing to do with the bug, which I stated in comment 3.

Comment 9

5 years ago
Got it, the original bug post is confusing indeed. The bug confuses the "Content-disposition" filename parameter when downloading a file for the FormData upload parameter for naming blobs. Guess it isn't a firefox bug then.
Created attachment 606638 [details] [diff] [review]
Patch

This needs the patch in Bug 665216 to work.
Assignee: nobody → khuey
Status: NEW → ASSIGNED
Attachment #606638 - Flags: review?(jonas)
(Reporter)

Updated

5 years ago
Depends on: 665216
I'd somewhat rather we actually had a content disposition filename here, so extensions will work with it properly.  Is there a reason to prefer the channel property thing to that approach?
One problem is that currently we always get header values by QIing to nsIHttpChannel and using methods there. But blob-channels don't currently implement nsIHttpChannel.

Should we move header management to nsIChannel? Or make blob channels implement nsIHttpChannel?
Why do you need header values?  nsIChannel has an explicit getter for the content-disposition filename, and we can (and should) add a setter on nsIInputStreamChannel to set the filename on it.
Comment on attachment 606638 [details] [diff] [review]
Patch

I guess this is the right thing to do, but it doesn't seem like it's solving many of the problems raised in this bug. I.e. you still can't download a blob with a page-specified filename. Though I guess that's what FileSaver is for.
Attachment #606638 - Flags: review?(jonas) → review+
(Assignee)

Comment 15

4 years ago
Created attachment 714901 [details] [diff] [review]
v1

This fixes on specific case where we try to download an nsIDOMFile. Comment #1 etc. seem to want something else as well.
Assignee: khuey → evilpies
Attachment #606638 - Attachment is obsolete: true
Attachment #714901 - Flags: review?(jonas)
(Assignee)

Updated

4 years ago
Depends on: 795442
Comment on attachment 714901 [details] [diff] [review]
v1

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

Looks great but needs tests.
Attachment #714901 - Flags: review?(jonas) → review+
(Assignee)

Comment 17

4 years ago
I tried editing https://mxr.mozilla.org/mozilla-central/source/browser/base/content/test/browser_bug676619.js, so that we pass a File object to the download_page.html, sadly everytime I do this the page just doesn't load. I don't see any actual reason for that. How should I pass data to that page?
I'm not sure what you mean by "the page just doesn't load". You have to wait until the page has loaded until you can pass a File object to it, no?

But what you might be running into is security wrappers. You might need to do the |new window.File(file, { type: file.type, name: file.name })| thing again.
(Assignee)

Comment 19

4 years ago
Created attachment 725933 [details] [diff] [review]
test

After thinking about this for a while, I came to the conclusion that a more explicit test would be easier and shorter.
Attachment #725933 - Flags: review?(jonas)
Attachment #725933 - Flags: review?(jonas) → review+
(Assignee)

Comment 20

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/3ce9677df96d
https://hg.mozilla.org/integration/mozilla-inbound/rev/29fc22298dc4
https://hg.mozilla.org/mozilla-central/rev/3ce9677df96d
https://hg.mozilla.org/mozilla-central/rev/29fc22298dc4
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
relnote-firefox: --- → ?
Too esoteric for the release notes. Should probably go up on MDN instead.
relnote-firefox: ? → -
You need to log in before you can comment on or make changes to this bug.