233914 - files downloaded to temporary location for MIME viewing should be uniquely named

Status: RESOLVED WONTFIX

(Toolkit :: Downloads API, enhancement)

Description

[Jordan Husney]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

This is a change request.  When a user opens an editable file from a URL via a
MIME viewer--such an a spreadsheet or other editable document--generally the
file viewer will allow the user to make changes to the file and commit those
changes to disk.  However, supposing the user forgot that they were working on a
temporary file and did not "Save As" there changes to another location, exited
the application, and then unassumably tried to view their changes again they
would, of course, be non-committed.  However, there is a secondary and possibly
undesired consequence.

Let us suppose that the user smacked their forhead and then said, "ah!  Of
course!! I originally opened that file via an HTTP URL!"  And happily went to go
to the place where their operating system stored the temporary file (Such as
/tmp or C:\Documents and Settings\username\Local Settings\Temp): they would
sadly be rewarded with their file having been overwritten with the file from the
 second time they tried to view the file with their web-browser.

I am that stupid person. :(

Reproducible: Always
Steps to Reproduce:
1.  Navigate to an HTTP link that opens an editable file with an external viewer
(Word, Excel, Adobe Illustrator, etc.)
2.  Make and commit changes to that file.  Exit the application.
3.  View the same file using the method in 1.
4.  Note how your changes are (of course) absent.
5.  Try to find the file in your O/Ss temporary user data location.  Open it.
6.  Notice how your changes are also absent here.
7.  Realize that the browser over-wrote your changes when you viewed the link a
second time.

Actual Results:  
The user file was overwritten.

Expected Results:  
When the file was opened in the first place, the name should have been
transformed into something unique.  Perhaps, only if the file exists: file.xls
-> file_0.xls or imediately using a convention similar to mktemp():
1234_file.xls 5673_file.xls, etc. etc.

Browser: FireFox 0.8

Comment 1

[Ali Ebrahim]

(In reply to comment #0)

> This is a change request.  When a user opens an editable file from a URL via a
> MIME viewer--such an a spreadsheet or other editable document--generally the
> file viewer will allow the user to make changes to the file and commit those

What is an editable file? Aren't all files editable? If you mean a common set of
filetypes, then the browser would have to detect these, adding unnecessary bloat.

> Expected Results:  
> When the file was opened in the first place, the name should have been
> transformed into something unique.  Perhaps, only if the file exists: file.xls
> -> file_0.xls or imediately using a convention similar to mktemp():
> 1234_file.xls 5673_file.xls, etc. etc.

To be honest, this is really a workaround fix to something that isn't really a
problem to begin with. The fact is that the file saved is still in the temp
directory, and that even if the user saves it, unless they use Save As (which
they should do in this case), it's still subject to deletion by pretty much
anything that writes to the temp area. Most users don't know this area even
exists, much less how to find it.

Also, this creates a UI issue, because if we munge filenames, then these munged
filenames get passed to applications, which creates a suboptimal user
experience. If someone clicks on a link to foo.doc, they expect Word to display
foo in the tile, not foo0 or 0_foo or whatever else.

In terms of costs vs benefits, I think the current behaviour is better than
having to munge filenames.

Marking as WONTFIX.

Comment 2

[Jordan Husney]

You are correct on many levels, filename munging does produce a tarnished user
experience.  However, do not get hung up on my lousy work-around suggestion.

There are other things that could be done such as if a file exists in a
temporary directory, munge its filename and then write the new file. 
Suprisingly, I was not the only person around the office that had been bitten by
this behavior (one would think that we would simply Save As... all the time!). 
However, if I hear anything twice, I am more liable to fix it.

If I get the chance, I'll have a look at the source and produce a patch and
submit it for reviewal.  At least this bug exists to refer back to.


Thank you for your evaluation.