736324 - Allow naming blob URL

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Benoit Girard (:BenWa)]

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

Comment 1

[Benoit Girard (:BenWa)]

Correction it is in the spec:
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-append%28%29-method

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

My guess is that we need to stick the filename on the channel we create in the blob protocol handler.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(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 ...

Comment 4

[Boris Zbarsky [:bzbarsky]]

> 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

[John Villar]

This is a duplicate of Bug #690659

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

No, it's not.  There's no FormData involved here.

Comment 7

[John Villar]

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?

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

[John Villar]

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.

Comment 10

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Patch

This needs the patch in Bug 665216 to work.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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?

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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?

Comment 13

[Boris Zbarsky [:bzbarsky]]

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 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 15

[Tom S. (please needinfo tschuster)]

Attachment: v1

This fixes on specific case where we try to download an nsIDOMFile. Comment #1 etc. seem to want something else as well.

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 714901 [details] [diff] [review]
v1

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

Looks great but needs tests.

Comment 17

[Tom S. (please needinfo tschuster)]

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?

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 19

[Tom S. (please needinfo tschuster)]

Attachment: test

After thinking about this for a while, I came to the conclusion that a more explicit test would be easier and shorter.

Comment 20

[Tom S. (please needinfo tschuster)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3ce9677df96d
https://hg.mozilla.org/integration/mozilla-inbound/rev/29fc22298dc4

Comment 21

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/3ce9677df96d
https://hg.mozilla.org/mozilla-central/rev/29fc22298dc4

Comment 22

[Alex Keybl [:akeybl]]

Too esoteric for the release notes. Should probably go up on MDN instead.