Alternative to locking file type on FileReference.save() AS3

Question

Update:

As discussed in Jacob's reply below, limiting or correcting the behaviour of FileReference.save isn't possible. Can anyone suggest an alternative (server is Apache/PHP) that matches all of my criteria from this post and avoids the pitfalls I discussed with Jacob?

End edit

I'm saving an image from my AS3 app using FileReference.save(). This is the code, which works fine:

var encoder:JPGEncoder = new JPGEncoder(80);
var byteData = encoder.encode(myBMD);  //bitmap data object created earlier
var file:FileReference = new FileReference();
file.save(byteData, "myImage.jpg");

This opens up the save file dialog as expected. I'm using this rather than sending the byteData to PHP because I want the user to have a familiar dialog box that lets them set their own file name.

The problem comes when users have their operating system configured to display file extensions, like I do. This means that in the save dialog the file name contains the extension as seen in the image below, and so it is very easy for the user to delete that extension when they rename the file. Because the default file type for this box is 'All files', if the extension is deleted the file is saved with no type.

I don't know of any way to force a file type on the save dialog (if there is one that would be my preferred route) so failing that can anyone suggest a safe way for me to do this that still allows the user to set the file name themselves using a standard dialog for their OS?

I did try putting in a call to FileReference.browse() before the save() as shown in this tutorial, but that throws an error because you can only perform one FileReference call at a time.

Answer 1

Sorry this is a known, major flash player bug with no real workaround.

Vote for it here: https://bugs.adobe.com/jira/browse/FP-2014

(Though for some reason, Adobe is calling it a feature request.)

---

Edit 2:

Fixed for FP 11.8 for Chrome, on both Mac OS and Windows.

https://bugbase.adobe.com/index.cfm?event=bug&id=2898055

---

Edit: Adding navigateTo workaround information

There is the php option of doing a navigateTo(): posting the file to a php page which has a mime-type of image/jpeg If you specify the right headers, you can get the browser to bring up the browser's native save dialog which does maintain extensions. However, there are other drawbacks to that method:

• no error handling from within flex
• additional request time
• additional server load.
• no feedback to user while the file is being uploaded and re-downloaded.
• inconsistent user experience across browser/os.
  • some browsers will actually popup a new window that disappears
  • some will leave the window.
  • some won't have any new window at all.

Answer 2

After long discussions and given our user base, our solution is:

1. detect when the problem occurs: in the FileReference SELECT event listener, check if the user has changed the file name and the extension has been dropped.
2. if the problem occured, cancel the operation. Start the operation again using the 'server bounce' method with navigateToURL()

We found that most of the time, the user did not change the name, so we rarely need to fall back on the second method which is less desirable.

Note that to mitigate the navigateURL() browser inconsistency problems mentioned earlier, we found it useful to specify "Content-disposition:attachment" in the header returned by the server.

Answer 3

Pity that this isn't available. I can understand that users what to have the freedom of saving the files the way they want. But what if you forget to add the extension? In my experience Flex then saves the file as a normal file without an extension. By doing that some users might not know what to do with the file they saved. As not every user will know what the different extensions mean/are and hope to open files with wrong extensions. I've seen it quiet often that people ask hope to open a specific file with a strange extension or no extension at all.

I partially get it why Adobe sees it as a feature request rather then a bug. But seeing how it can mess up the process of things you maybe rather want to consider it as a bug. As like I said, not every user will know how to open the file named "myfile" instead of "myfile.jpg". And how many users that do understand how to open it have set ".cow" as an extension to be opened by the imageviewer, and how will the OS respond to such strange extension? Well maybe ".cow" is a bad example, but I guess you get the point.

A work-around for this could be to create the function yourself. Meaning you give the user a pop-up window (or how you prefer it) with the option to specify the filename, get the file location and then save/cancel button. You then can check if they added an extension, filled in a filename and gave a file location (that is even correct). This combined with the FileStream function should (if I'm not mistaken) be a solution to create a similar function as the save dialog option.

Answer 4

Eduard provided a workaround in Adobe's feature request tracker for this issue: Doubling the file extension, such as "image.jpg.jpg". This is what we will do since for our users who hide extensions, the extensions gets dropped whether or not they change the file name.