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