835267 - When saving file from data: url, the file extension disappears

Status: RESOLVED FIXED

(Core Graveyard :: File Handling, defect)

Description

[bigd]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Steps to reproduce:

Trying to save a file from a DataURL, build by JS is my application. 


Actual results:

When letting Firefox save it at the default-folder automatically (without getting prompted to select destination folder) the file extension is missing and its only gets the *.part extension (e.g. 7axxxxxJ.gif.part).


Expected results:

When Firefox has to prompt for download destination folder, the correct file extension is set (e.g. 7axxxxxJ.gif.part.gif), depending on the MimeType defined. 

BTW: Please do something about that ugly filenames. It would be great if I could define the filename, like the download-attribute in chrome (download="filename.ext").

Comment 1

[Boris Zbarsky [:bzbarsky]]

> It would be great if I could define the filename, like the download-attribute in chrome

See bug 676619.

As for this bug... it should have the .part there until the download finishes, then it should be renamed to "7axxxxxJ.gif".  Is that not happening?

Comment 2

[bigd]

It depends... 

If firefox is configured to save files directly to the (default) download-folder, and automatically produces filenames like "7axxxxxJ.gif.part", you are right, ".part" shouldn't be there, at least after the download is completed successfully it should vanish. Seems auto-renaming doesn't take place in this case. Until the download-attribute (or something similare) is ready that would be fine for me.

But ...
In case firefox has to ask/prompt for the download-destination (save-as-dialoge), the issue/bug is the (ugly) filename firefox proposes. ".part" is already in the random filename firefox proposes in the save-as-dialoge, for example "7axxxxxJ.gif.part.gif". I can change the filename to what ever i want (i usually dont, im lazy ^^, as most other users too), and the filename of the saved file is correct after that. So firefox should propose something like "7axxxxxJ.gif" instead of "7axxxxxJ.gif.part.gif". 


If someone has a (even dirty) solution to use in my web-application to solve taht problem for now, i appreciate any suggestions and help.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, I see.  Sounds like a front-end bug, then...  it's quite odd that the .part is in the suggested filename!  A link to a page that shows the problem would be very helpful here.

Note that support for @download is shipping in about two months, for what that's worth.

Comment 4

[Manuela Muntean [Away]]

Reporter, thank you for pointing this out. Please answer to comment 3.

Comment 5

[bigd]

Sorry, was busy this days ...

Currently I have no public site running, but following code reproduces the bug:

<a id="dataurl" href="">Download</a>
<script type="text/javascript">
  var blob = new Blob(['Hello World!'], {type : 'application/zip'});
  var a = document.getElementById("dataurl");
  a.download = 'test.zip';
  a.href = window.URL.createObjectURL(blob);
  a.dataset.downloadurl = ['application/zip', a.download, a.href].join(':');
  a.textContent = 'Download ready';
</script>

I choosed zip to force Firefox to download the file instead of opening it. 

BTW: A attribute/parameter/function what ever to "force" whether firefox should open or download a file would be nice.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> A attribute/parameter/function what ever to "force" whether firefox should open or
> download a file would be nice.

That's the user's call...

In any case, using the testcase from comment 5, if I take out the "a.download = 'test.zip'" bit I can reproduce the reported problem.  I'll take a look at what's going on here.

Comment 7

[Manuela Muntean [Away]]

On the latest Nightly, using the testcase from comment 5, the file was downloaded properly, with the full .zip extension, but when I tried to open it, I received the error message:  Can not open file as archive.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130204 Firefox/21.0
Build ID: 20130204030941

With the same build, after changing the testcase from comment 5 as suggested in comment 6, I can indeed reproduce the issue. The file is saved with this name:  8RvWA9KI.zip.part.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> but when I tried to open it, I received the error message

That's because the data is not actually ZIP data.  That part is expected.  This bug is just about the 8RvWA9KI.zip.part bit.

Comment 9

[Manuela Muntean [Away]]

(In reply to Boris Zbarsky (:bz) from comment #8)
> > but when I tried to open it, I received the error message
> 
> That's because the data is not actually ZIP data.  That part is expected. 
> This bug is just about the 8RvWA9KI.zip.part bit.

Ok, thank you.

Comment 10

[bigd]

> A attribute/parameter/function what ever to "force" whether firefox should open or
> download a file would be nice.

I mean that the developer could control that firefox shows the "open with or save as-dialog" instead of open/show the served file. For example when offering a JPEG or txt-file for download: firefox wont show the save-as-dialoge, it opens it instantly. 


And yea, the blob-object in the testcase has "text-content", so thats why ZIP fails. For this bug it doesnt matter.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> I mean that the developer could control that firefox shows the "open with or save
> as-dialog" instead of open/show the served file.

The "download" attribute does that, as far as I can tell, as long as it's either same-origin or a data: or blob: URI.  Try a recent nightly to see the behavior.

Comment 12

[Manuela Muntean [Away]]

(In reply to Boris Zbarsky (:bz) from comment #11)
> > I mean that the developer could control that firefox shows the "open with or save
> > as-dialog" instead of open/show the served file.
> 
> The "download" attribute does that, as far as I can tell, as long as it's
> either same-origin or a data: or blob: URI.  Try a recent nightly to see the
> behavior.

Reproducible on the latest Beta (BuildID: 20130206083616): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0

Reproducible on the latest Aurora (BuildID: 20130207042017): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20130207 Firefox/20.0

Reproducible on the latest Nightly (BuildID: 20130207030936): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130207 Firefox/21.0

The file is saved with this name: 50pPPpYQ.part

Comment 13

[Manuela Muntean [Away]]

Here is the regression window I have found:

Last good nightly: 2012-03-12
First bad nightly: 2012-03-13

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ec9524de1af&tochan
ge=1ca7a94573f2

After browsing through the pushlog, I think that maybe it could be possible that bug 721569 could have caused the problem.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Well, before that the testcase does absolutely nothing....

Comment 15

[Manuela Muntean [Away]]

(In reply to Boris Zbarsky (:bz) from comment #14)
> Well, before that the testcase does absolutely nothing....

I know, I have experienced the same behavior. Until the release of Firefox 13.0.1, the testcase didn't do absolutely nothing. After Firefox 13.0.1 (including it) and until the latest release, Firefox 18.0.2, the testcase works bad, as stated in comment 12.

Comment 16

[Manuela Muntean [Away]]

(In reply to Manuela Muntean [:Manuela] [QA] from comment #15)
> (In reply to Boris Zbarsky (:bz) from comment #14)
> > Well, before that the testcase does absolutely nothing....
> 
> I know, I have experienced the same behavior. Until the release of Firefox
> 13.0.1, the testcase didn't do absolutely nothing. After Firefox 13.0.1
> (including it) and until the latest release, Firefox 18.0.2, the testcase
> works bad, as stated in comment 12.

By "Until the release of Firefox 13.0.1", I mean the next releases: 4.0, 4.0.1, 5.0.1, 6.0.2, 7.0.1, 8.0.1, 9.0.1, 10.0.2, 11.0, 12.0

Comment 17

[Boris Zbarsky [:bzbarsky]]

OK, so what's going on here is that nsExternalAppHandler::SaveToDisk has code like so:

    mTempFile->GetLeafName(leafName);
    if (mSuggestedFileName.IsEmpty())
      rv = PromptForSaveToFile(getter_AddRefs(fileToUse), leafName, mTempFileExtension);

mTempFile has the .part thing, of course and in this case mSuggestedFileName is empty.

This looks like a regression from bug 395308, which added the .part to mTempFile's name but didn't change the uses of mTempFile that relied on the old name.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Attachment: Make sure to save our suggested filename before we append a .part to it so that we don't suggest filenames with .part in them. option would be to save it before we createUnique too, and just assume that this name is only used if the user really wants it

Gavin, please see the checkin comment for an alternate way to fix the weirdness.  Let me know which you prefer, ok?

Comment 19

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 711805 [details] [diff] [review]
Make sure to save our suggested filename before we append a .part to it so that we don't suggest filenames with .part in them.   option would be to save it before we createUnique too, and just assume that this name is only used if the user really wants it

bouncing over to Drew since I won't be able to look at this for a bit

Comment 20

[Boris Zbarsky [:bzbarsky]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9f9eb67458e9 though I forgot to change the "r=" bit in the commit message.  :(

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9f9eb67458e9