Should make downloaded files-read only

Bug #90378 reported by Nikolaus Rath
20
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
Medium
firefox (Ubuntu)
Fix Released
Wishlist
Mozilla Bugs

Bug Description

Binary package hint: firefox

When firefox downloads a file and the user chooses to open this file directly with an application (openoffice, gedit ..), the file is saved in a temporary folder. The file is removed by firefox at some later point (I couldn't figure out when exactly).

The problem is that in the application, the user is presented with a completely normal, writable file. An average user can not know that any changes he makes will be lost *even if he saves the file*, because the application does not ask for a new filename. But also as a more experienced user I often forget that I am dealing with a temporary file. I assume that my data is safe when I press save. If for some reason the data cannot be saved (because it was downloaded from the net), I expect to be asked for a new filename.

Although this is neither a real firefox nor openoffice (or gedit etc) bug, it easily leads to dataloss.

I see three options to fix this:

1) Firefox should mark downloaded files read only when they are just temporary. This will hopefully cause applications to show the correct behaviour when changes are made.

2) Firefox should not delete temporary files if they have been changed. Problem here is that the file still has an obscure name and sits in a tmp directory.

3) Firefox should tell the called application to show the data without associating it with a filename. This would be the best option, but it is most likely not possible to implement for all files.

Tags: mt-confirm
Nikolaus Rath (nikratio)
description: updated
Changed in firefox:
assignee: nobody → mozilla-bugs
importance: Undecided → Wishlist
status: Unconfirmed → Needs Info
Revision history for this message
In , Nikolaus Rath (nikratio) wrote :

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5

When firefox downloads a file and the user chooses to open this file directly with an application (openoffice, gedit ..), the file is saved in a temporary folder. The file is removed by firefox at some later point (I couldn't figure out when exactly).

The problem is that in the application, the user is presented with a completely normal, writable file. An average user can not know that any changes he makes will be lost *even if he saves the file*, because the application does not ask for a new filename. But also as a more experienced user I often forget that I am dealing with a temporary file. I assume that my data is safe when I press save. If for some reason the data cannot be saved (because it was downloaded from the net), I expect to be asked for a new filename.

Although this is neither a real firefox nor openoffice (or gedit etc) bug, it easily leads to dataloss.

I see three options to fix this:

1) Firefox should mark downloaded files read only when they are just temporary. This will hopefully cause applications to show the correct behaviour when changes are made.

2) Firefox should not delete temporary files if they have been changed. Problem here is that the file still has an obscure name and sits in a tmp directory.

3) Firefox should tell the called application to show the data without associating it with a filename. This would be the best option, but it is most likely not possible to implement for all files.

Reproducible: Always

Changed in firefox:
status: Incomplete → New
Changed in firefox:
status: Unknown → New
Revision history for this message
In , Jo-hermans (jo-hermans) wrote :

If it's in /tmp (when you open directly in an application), then it should have been solved by bug 280419. The file is also supposed to be deleted when the application exits. You should be able to control this behavior with the boolean variable browser.helperApps.deleteTempFileOnExit in about:config (doesn't exists by default, default is true, except for Mac OS X). But when the file is not supposed to be deleted, then the permissions are not set.

If the file is first downloaded in the downloads directory (or on the desktop), then it should be writable.

Revision history for this message
In , Nikolaus Rath (nikratio) wrote :

True, sorry about the dup.

*** This bug has been marked as a duplicate of bug 280419 ***

Revision history for this message
Nikolaus Rath (nikratio) wrote :

Fixed upstream and included in hardy.

Changed in firefox:
status: New → Fix Released
Revision history for this message
In , Jo-hermans (jo-hermans) wrote :

But why did you see it in Firefox 3.0 - it's supposed to have been fixed. Did you set browser.helperApps.deleteTempFileOnExit to false ?

Revision history for this message
In , Nikolaus Rath (nikratio) wrote :

I didn't see in it Firefox 3.0 but in Firefox 2.

This was originally an Ubuntu bug and I forwarded it upstream without checking if it may have been fixed since the initial report - my bad.

Changed in firefox:
status: New → Invalid
Revision history for this message
In , Stephen-donner (stephen-donner) wrote :

Verified dup

Revision history for this message
Randall (randall-songshu) wrote :

i find this highly annoying and disruptive behavior, i have 70 users depending on firefox and a web application that makes contracts, invoices, custom documents etc.... opening in openoffice.org

1 they don' t understand why their document is read-only all of a sudden
2 using the "edit" button gives two confusing messages that look like error messages
3 after they used the "edit" button and went through the two errors, the file itself is still not saved.
4 the web application gives files an understandable name, e.g contract-number-5642 (where this number is the actual contract number) and it should be saved this way, after the "edit" button it is untitled25455454545

maybe this works for others but for me it doesn 't

am i the only one?, will file a bug to find out.
in the meanwhile is there a way to change this behavior back to the way it was?

Revision history for this message
Alexander Sack (asac) wrote : Re: [Bug 90378] Re: Should make downloaded files-read only

On Tue, May 13, 2008 at 01:19:48PM -0000, Randall wrote:
> i find this highly annoying and disruptive behavior, i have 70 users
> depending on firefox and a web application that makes contracts,
> invoices, custom documents etc.... opening in openoffice.org
>
> 1 they don' t understand why their document is read-only all of a sudden
> 2 using the "edit" button gives two confusing messages that look like error messages
> 3 after they used the "edit" button and went through the two errors, the file itself is still not saved.
> 4 the web application gives files an understandable name, e.g contract-number-5642 (where this number is the actual contract number) and it should be saved this way, after the "edit" button it is untitled25455454545
>
> maybe this works for others but for me it doesn 't
>
> am i the only one?, will file a bug to find out.
> in the meanwhile is there a way to change this behavior back to the way it was?
>

This is a deficiency of the editing application that opens the
files. That application should pop up save as ... when you hit save
for a read-only file.

Without this change users regularaly loose their edited documents
...

 - Alexander

Revision history for this message
jsandeo (jsandeo) wrote :

I agree with Randall that this behaviour is quite annoying.
We also run a web application that allows us to download on-the-fly-generated OpenOffice documents, for instance packing-list documents.
A user downloads a packing-list just for printing, not for keeping the document. But sometimes, before printing, it is useful to edit the document to add some manual data. So what happens now with hardy is, the user needs to save the document, then edit, then print.
Is there any way for me to set the permissions with which firefox saves downloaded files?

Revision history for this message
Alexander Sack (asac) wrote :

On Fri, May 30, 2008 at 10:48:12AM -0000, jsandeo wrote:
> I agree with Randall that this behaviour is quite annoying.
> We also run a web application that allows us to download on-the-fly-generated OpenOffice documents, for instance packing-list documents.
> A user downloads a packing-list just for printing, not for keeping the document. But sometimes, before printing, it is useful to edit the document to add some manual data. So what happens now with hardy is, the user needs to save the document, then edit, then print.
> Is there any way for me to set the permissions with which firefox saves downloaded files?
>

its fixed in hardy (ffox 3 and tbird 2)

 - Alexander

Revision history for this message
jsandeo (jsandeo) wrote :

I must be missing something, because I actually started experiencing the problem (both in ffox3 & tbird) since I upgraded to hardy.

Revision history for this message
Eric (eric-johnson-corp) wrote :

I also find this change highly annoying. I guess I understand why people who are new to Linux would not understand that saving their important files in /tmp is bad. But to people who have used Linux for a long time and are accustom to the old functionality this is really intrusive. For myself I have lots of reports that are downloaded from the web or email. I open these reports in open office, change the sorting or formatting to take a look at the data, then close the file. I don't care about the changes that I have made, I just wanted to look at the data a different way for the moment. So it works out really well that these files are saved to /tmp and eventually automatically deleted. Since Openoffice does not allow you to change anything about a file when its read only, not even change the sort order, I have to open the file, save it (in /tmp), just to change the sort order. I am okay with the default functionality the way it is for the Linux newbies, but I need an option in both Firefox and Thunderbird that allows me to use the applications like I have for years.

Does anyone know of a way to do this?

Thanks

Eric

Revision history for this message
Nikolaus Rath (nikratio) wrote :

What about changing the OpenOffice behaviour instead? It seems to me that editing a read-only file should be possible, as long as the changes end up under a new name.

Revision history for this message
jsandeo (jsandeo) wrote :

IMHO OpenOffice is just an example of application that illustrates a use-case scenario where this "feature" proves to be flawn.
If we decide that all downloads are to be opened on read-only mode by the target application, then we have to change the behavior of all the possible target applications for a download, if we want to be able to edit the file no matter its permissions:
- OpenOffice
- Koffice
- Video-editing Sw
- Audio-editing Sw
- Plaintext editors
...
you name it

Revision history for this message
Nikolaus Rath (nikratio) wrote :

I think you're missing the point. Firefox behaves correctly, OpenOffice probably doesn't. The fact that other applications might behave wrongly as well doesn't make it less wrong.

But apart from that: have you actually checked how other applications behave? Gedit for example already allows to edit a read-only file just fine. It correctly warns that changes cannot be saved and offers to save the file under a new name.

Revision history for this message
jsandeo (jsandeo) wrote :

Well, I guess it all depends on how we look at the problem...

I can understand why you say that Firefox behaves correctly by saving downloads as read-only, but then would that mean that wget behaves wrongly by saving downloads with user-set permissions? I don't think so. It all depends on the use-case scenario, ie. it all depends on what the user wants to actually do with the file, but this is of course, we don't know.

On certain use-case scenarios, saving read-only is annoying because the target application may behave unexpectedly because of the file's permissions (the OpenOffice case, for example). Let's name this the JohnnyBrowser's use-case scenario. On other use-case scenarios, saving with write permissions can mislead the user to believe that he has saved a file that will be swept away. Say this is JohnnyKeeper's use-case scenario.

The problem here is that you must take a decision. Our goal here should be to try annoying users the least possible.

Say we save with write permissions: user JohnnyKeeper will eventually learn that if he does not "save as" his downloads to a well-known directory, he ends up loosing them. It will cost him a few data losses, but he will eventually learn and live happily ever after. User JohhnyBrowser leaves happily.
On a daily basis, here is what these 2 guys end up doing:
JohnnyKeeper opens a document, edits it, then does a "save as", chooses a new file name, saves, then closes application.
JohhnyBrowser opens a document, edits it, then closes application.

Say we save with read-only permissions: user JohnnyKeeper will eventually learn that he can't save directly, but must first do a "save as" if he wants to keep/edit the downloaded file. He will never loose data, and live happily ever after. User JohnnyBrowser will eventually learn that with certain downloads he can't edit directly, but must first do a "save as". He will never live happily, wondering why he must save and name a file he does not want to keep anyway.
On a daily basis, here is what these 2 guys end up doing:
JohnnyKeeper opens a document, then does a "save as", chooses a new file name, saves, edits the file, then saves, then closes application.
JohhnyBrowser opens a document, then does a "save as", chooses a new file name, saves, edits the file, then closes application.

If we save read-only, both users end up doing more tasks (on certain apps, of course), and in some cases they end up doing tasks that have nothing to do with their goals.

Revision history for this message
Nikolaus Rath (nikratio) wrote :

jsandeo <email address hidden> writes:
> I can understand why you say that Firefox behaves correctly by saving
> downloads as read-only, but then would that mean that wget behaves
> wrongly by saving downloads with user-set permissions? I don't think
> so. It all depends on the use-case scenario, ie. it all depends on
> what the user wants to actually do with the file, but this is of
> course, we don't know.

No, this isn't a proper comparison. If you *download* a file, firefox
behaves exactly like wget. What we are talking about is the case where
you tell firefox to *open* the file, i.e. act as a viewer.

> Say we save with write permissions: user JohnnyKeeper will
> eventually learn that if he does not "save as" his downloads to a
> well-known directory, he ends up loosing them. It will cost him a
> few data losses, but he will eventually learn and live happily ever
> after. User JohhnyBrowser leaves happily. On a daily basis, here is
> what these 2 guys end up doing: JohnnyKeeper opens a document, edits
> it, then does a "save as", chooses a new file name, saves, then
> closes application. JohhnyBrowser opens a document, edits it, then
> closes application.

I am sorry, but I can not agree with this. If something "costs a few
data losses" it can never be a viable option, no matter how happy it
may make how many people.

> Say we save with read-only permissions: user JohnnyKeeper will
> eventually learn that he can't save directly, but must first do a
> "save as" if he wants to keep/edit the downloaded file. He will
> never loose data, and live happily ever after. User JohnnyBrowser
> will eventually learn that with certain downloads he can't edit
> directly, but must first do a "save as".

He files a bug for the respective application, it gets fixed at some
point, and he lives happily ever after.

Best,

   -Nikolaus

Revision history for this message
jsandeo (jsandeo) wrote :

You are right that the wget comparison was not proper, but actually my point was: there is no such thing as right/wrong behaviour, because it all depends on what the user wants to do with the file, which we don't know. So I am not talking about bugs here, just about features.

An OpenOffice developer could reasonably argue that OpenOffice documents that have only read permissions should not be editable by default. We could probably find a use-case scenario where that makes sense and would save someone from wasting time editing a file he would never be able to modify. I would not say such a behaviour is a bug, it is just a design decision.

The key question here is which decision is less annoying for your users.

You decide that you rather go for the read-only option. That is fine, it sure makes sense. But the fact is that the consequences for your users are unavoidable. Users don't file bugs nor try to change developers' minds, they just switch applications. They won't care whether FFox3 is doing "the right thing" or not, they will just switch to FFox2, Opera, Safari or whatever if that makes their life easier.

I would not say Opera or Safari are buggy if they save temporary files with write permissions. They just made a different design decision.

Revision history for this message
Nikolaus Rath (nikratio) wrote :

Yes, I see your point.

Nevertheless, I think there is a difference between a feature being an annoyance for some use cases and a feature causing dataloss. If I understood you correctly, then we both agree that not making the files read-only (or taking one of the other measures described in the initial bug description) will result in dataloss when a (non-technical) user follows his intuitive expectations. I think that is an entirely different category than loosing a couple of seconds when the file is read-only and needs to be saved under a new name. For that reason I very much plead for the default behaviour to be read-only.

Making this configurable is something I'm not opposed to either, but I fear that the developers may be reluctant to add too many optional features.

It seems to me that we'll just have to agree to disagree on this one.

Revision history for this message
Alexander Sack (asac) wrote :

On Fri, Jun 06, 2008 at 06:08:37AM -0000, Eric wrote:
> Since Openoffice does not allow you to change anything about a file when
> its read only, not even change the sort order, I have to open the file,
> save it (in /tmp), just to change the sort order. I am okay with the
> default functionality the way it is for the Linux newbies, but I need an
> option in both Firefox and Thunderbird that allows me to use the
> applications like I have for years.
>
> Does anyone know of a way to do this?
>

This is an openoffice issue - they should reconsider how they deal
with read-only files and should offer the user to breach any kind of
"read-only" mode easily.

 - Alexander

Revision history for this message
Alexander Sack (asac) wrote :

On Fri, Jun 06, 2008 at 12:42:00PM -0000, Nikolaus Rath wrote:
>
> He files a bug for the respective application, it gets fixed at some
> point, and he lives happily ever after.
>

Right, fix the editor applications to have a sane read-only editing
behaviour. So complain there, they might be more open about fixing
this than you might expect :) ...

 - Alexander

Revision history for this message
jsandeo (jsandeo) wrote :

Yes, and uTorrent should fix their app too...
http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=65735&forumId=1

(to be continued...)

Revision history for this message
bjakeway (bruce-jakeway) wrote :

I have an application in which I users download a document, open the document, make changes to it, and upload it to a database. I would like the temporary file removed, so don't need users to save this file. The change to Firefox 3.0 prevents users from saving the file to the database once they have downloaded the file, opened it, and made their changes. Instead, the file must be saved to the file system before it can be uploaded to the database.

Thus, I disagree with the decision that temporary files should be marked as read-only.

A possible alternative solution is that when the *user* saves a downloaded file for the first time, the Save As dialog appears, even though the file already has a temporary name.

Revision history for this message
Nikolaus Rath (nikratio) wrote :

bjakeway <email address hidden> writes:
> A possible alternative solution is that when the *user* saves a
> downloaded file for the first time, the Save As dialog appears, even
> though the file already has a temporary name.

Which is exactly what is supposed to happen if the user changes a
read-only file.

Best,

   -Nikolaus

--
 <email address hidden> | College Ring 6, 28759 Bremen, Germany
 Class of 2008 - Physics | Jacobs University Bremen

 »My opinions may have changed, but not the fact that I am right.«

Revision history for this message
bjakeway (bruce-jakeway) wrote :

The problem I have with this solution is not one where I am saving to the file system. I am trying to save to a database and I get a Save-As dialog.

Revision history for this message
bettlebrox (micktimony) wrote :

How does one disable ths behaviour in Firefox?

I often have Firefox save and open files in /tmp, and I find it a real pain to have to chmod the files so I can edit them. And I find it quite useful to save files in /tmp that I want to edit but I don't want to save long term as I know they'll be deleted upon reboot (instead of having them cluttering up my Desktop or ~/Documents directory).

Revision history for this message
Nikolaus Rath (nikratio) wrote :

bettlebrox <email address hidden> writes:
> I often have Firefox save and open files in /tmp, and I find it a real
> pain to have to chmod the files so I can edit them.

This is a bug in the application that you're using to edit the files.
It'd be great if you could report it there.

> And I find it quite useful to save files in /tmp that I want to edit
> but I don't want to save long term as I know they'll be deleted upon
> reboot

Relying on this is probably a bad idea. At least my version of Firefox
deletes these files as soon as it terminates. On the other hand, files
in /tmp are also not guaranteed to be deleted upon reboot.

Best,

   -Nikolaus

--
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

Revision history for this message
bettlebrox (micktimony) wrote :

>This is a bug in the application that you're using to edit the files.
No I don't think it is a bug in the application that I'm using to edit the files, it's the behaviour of the application I'm using to download the files, in this case Firefox.

For example, if I download a word document, Firefox saves it with 644 permissions to my default download location. If instead I choose to "open" the file (using FF's "Open With" dialog window) it saves the file to /tmp with 400 permissions and the file is unwriteable. This is not the same behaviour that (I remember) with Hardy, and to me it's not a feature enhancement as it reduces my productivity. However, I do see where this could be beneficial new Linux & Ubuntu users who might be aware that the file is in /tmp and may be removed upon reboot.

I would like to have the option to change this behaviour, or at least know where this is set so I can determine how to change the behaviour myself.

>Relying on this is probably a bad idea.
It's worked OK for me for the past 10 years! ;)

/tmp normally is cleaned automatically upon reboot. The length of time files are retained in /tmp can be configured via the /etc/default/rcS configuration file. By default this is set to zero which means that no files will be retained in /tmp upon restart.

Revision history for this message
John Vivirito (gnomefreak) wrote :

You want save and openwith to work the same? save to somewhere other than /tmp? same permissions?
From what i gather from your comments this is not really a firefox issue. Open with should save to /tmp since you are not intending to keep it Until you save it in the doc viewer. When saving to disk using "save as" is saving the doc. with the intention of reading/editing later.

Revision history for this message
jzacsh (jzacsh) wrote :

I think it would be awesome if there would be a config file I could set somewhere to change this behaviour. I _hate_ having to "save as..." for a file i _don't_ want to save

Revision history for this message
pmaxx (ph-maxxcon) wrote :

I agree, there should be a config file. Here's my usecase: We use an online doc storage app. The permanent storage is in the cloud. We want to be able to download a doc, edit it, and store the edits back in the cloud. We still have to do "save as" at the end, but we are using OO and it's just plain awkward to have to click the edit button before we can save. The read only status looks like a bug to the end user.

Tools should not force the user to change their work habits to fit the tool.

Revision history for this message
pmaxx (ph-maxxcon) wrote :

Typo:

it's just plain awkward to have to click the edit button before we can save
should be
it's just plain awkward to have to click the edit button before we can edit

Changed in firefox:
importance: Unknown → Medium
status: Invalid → Unknown
Changed in firefox:
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.