Firefox/Thunderbird attachments open in read-only mode

Confirming on 20030930 nightly trunk build, Win2k. I couldn't find an obvious
dupe of this.

Reproduced tonight. This is a "user-friendliness" issue, not a system issue.

-----------------------------------------

System specs:

WinXP pro SP1a (full patches)
Mozilla 1.5
Word (Office) 2000.

When you open an attachment in an external application, neither Mozilla nor Word
warn you that the changes are not saved to the ATTACHMENT.

Instead, Mozilla downloads the attachment to the user's designated %TEMP%
directory, and the application opens that file. When the user saves and closes,
the application correctly saves the COPY in the user's temp directory.

-----------------------------------------

Causes:

Mozilla does not open attachments by passing a link to a related file, it saves
an embedded MIME-encoded file to the temp dir. Once it saves and triggers the
3rd-party application, there is no flag sent back to mozilla to indicate any
changes.

This is not a fault of the 3rd-party application, it is opening a file as normal
and saving it to itself.

-----------------------------------------

Suggestions:

Add a popup box warning users to explicitly "Save as..." in their applications.

-----------------------------------------

Thank you.

*** Bug 244934 has been marked as a duplicate of this bug. ***

Two key questions here:

* Who deletes the temp file -- Mozilla or the OS?
* When is the file deleted -- after the user closes the 3rd party application,
or after Mozilla is closed?

If Mozilla deletes the file, or if the file is deleted only after Mozilla is
closed, then it should be possible to detect the changes, even if no explicit
flag is sent to Mozilla. In particular, either the timestamp or (on Win32) the
archive attribute can be used.

Once such a change is detected (after the 3rd part app is closed; since Mozilla
spawns that app, it should be able to detect that it was closed?) -- after such
a change is detected, Mozilla should pop up a dialog box offering the user to
save a copy (i.e., if the user approves, Mozilla should create the copy in a
location selected by the user; don't leave it as a mere "go save your file"
notification).

A special case is when the attachment was opened from a message in the Unsent
folder (see Bug 215394) -- here Mozilla should (also) offer to update the
unsent message with the new version of the attachment.

 - Tal

*** Bug 268658 has been marked as a duplicate of this bug. ***

Even this is a user-friendliness issues, this is a *major* usability error.

I wouldn't advise to use Thunderbird anyone if I knew about this error. Of
course I use Thunderbird, but two solutions are very easily implementable:
1) Make temporary file read only, so when user tries to save it (Save), Word
displays warning and offers a copy to be saved.
2) Make changes to encoded file - why is Thunderbird so stupid that it doesn't
make any changes to the attachment itself when user edits the attachment? I know
that attachment are actually stored base64 (?) encoded somewhere in one big
files, but this should be easy - just make binary comparison on file. If
differs, just recreate base64 encoded attachment in the file where all
attachments are kept encoded. Thanks.

*** Bug 265288 has been marked as a duplicate of this bug. ***

*** Bug 283405 has been marked as a duplicate of this bug. ***

I believe the default should be saving the file as Read-Only, forcing any
external changes to use a different name (shouldn't be too difficult to
implement?). However, there is the special case of attachments to unsent
messages: here, it is likely that the user will want to send the updated file
rather than the original one. See Bug 215394 (RFE).

*** Bug 257499 has been marked as a duplicate of this bug. ***

Another method would be to open documents in "template" mode---when the external application supports this. For example, OpenOffice.org has an "-n" parameter which allows document editing, but when the user saves, he is prompted to specify a name and location. (Of course, the Mozilla products would need a way of knowing these parameters.)

Also, it would be nice to see the final solution implemented in both Firefox (for web-based e-mail) and Thunderbird, but AFAICT, this issue does not apply to the web browser.

A partial workaround, as others have mentioned, might be to check the temporary file's timestamp. Compare it with the known timestamp that the file had, when it was originally downloaded.

If they are different, then assume the user has edited the file or otherwise taken action to cause it to be different from what it was when it was originally downloaded. Then, offer the chance for the user to save the file to a real location, going through the usual Save As dialog, and DO NOT DELETE the temporary file automatically!

Hopefully, that will be enough to protect users from the common mistake of editing temporary files, then having them automatically cleaned up, thus losing all of their edits....

*** Bug 325217 has been marked as a duplicate of this bug. ***

Why is Mozilla not taking this seriously? It has been reported for years, but the only way to know it is a problem is to get burned and go looking to file a bug report. I just lost hours of complicated spreadsheet work, and another hour trying to find the file and/or undelete it. Another 30 minutes hunting for the bug report and filing this comment.

It is doubly painful to find out that Mozilla has been aware of this bug for years and also aware of several work arounds. No other email client of many I have used has ever had this "feature."

The easiest fix is very easy indeed. Simply put a line of text on the file open/save window that already pops up when one double clicks an attachment. Can't be more than 5 minutes of work to add a line of text beside the open file option in the next build that states something like "WARNING: ANY CHANGES TO ATTACHMENTS OPENED IN THIRD PARTY SOFTWARE WILL NOT BE SAVED UNLESS 'SAVE AS' IS USED."

Please do at least that. I'm begging you for the sake of other users. The number of duplicate bugs here suggests this really, really needs to be addressed.

*** Bug 354599 has been marked as a duplicate of this bug. ***

*** Bug 361430 has been marked as a duplicate of this bug. ***

Updating summary, the only reasonable solution here seems to be opening the attachment in readonly mode. Then it's up to the application if it lets you edit and warns on save, or don't let you edit at all.

Some users of my network are complaining of having "lost data", they are furious.

And just because of this bug. If this bug is not solved (opening the
attachment in readonly mode, for example) we are going to convert to Thunderbird way less people, this is frustrating, they are asking me Outlook!.

This bug should really be flagged as "data loss", and the severity changed accordingly. (The "mark file as read only" solution does sound like a trivial yet effective way out.)

Not going to block the security updates for this, but would take a patch if the Thunderbird team takes this for the upcoming "2.0"

If we were to try to create the temp file "read only", we would have to do it in code shared with the browser, i.e.

http://lxr.mozilla.org/mozilla/source/uriloader/exthandler/nsExternalHelperAppService.cpp#1610

so this would affect Firefox as well, I believe.

If it only affects the temp files, then it wouldn't be a silly idea - even for Firefox.

As a supporter, I'm used to here people opening stuff in their browser/mail and hitting save, when they close the external program. They're just forgetting where the file actually is located on the disk, so usually the edited data is lost.

We can't educate non-IT people through a program, so why not help them a bit?

I didn't mean to imply that because it affected Firefox, it was silly - but it mgith be quite a bit harder to get the change approved...unless we can do it in a way that doesn't affect Firefox.

Okay, I should have chosen my words better. I'm not sure how Firefox handles temp-files, but if it's similar to Thunderbird, then it might be a good idea for Firefox too.

I do know that Thunderbird-only bugs are easier to check-in, so if it isn't the hardest bug, then it would be much appreciated in work-environments with lots of non-IT personnel.

Right now I'm trying out Readonly Attachments:
https://addons.mozilla.org/firefox/1846/
It's working fine in the nightly trunk, but sadly it doesn't support Danish charset (might be any funky-chars in general).
I made it save the Danish-attachments correctly, but then I couldn't make it open them. I haven't done that much Gecko-coding.

From the comments in bug 280419 it sounds it wouldn't be a problem getting it in if someone puts together a patch. At least on trunk...

bug 280419 tells you exactly what to change if a volunteer wanted to jump in and put together a patch. I'd suggest putting it in that bug since the helper app devs are already on that one. And it sounds like they are ok with making the files read only. At the very least it can get into the trunk so it will be fixed in tb3/fx3. might be too late for the branch.

So this won't be fixed for TB2. People don't seem to realize that this is a data-loss bug.

If the file is created as read-only and the product crashes before deleting the temp file, will the user have a harder time getting rid of it?

Re: #28: In GUI systems, this normally amounts to no more than an additional dialog box, saying (e.g., in Windows XP) "The file '...' is a read-only file. Are you sure you want to delete it? [Yes] [No]". Not what I would consider "a harder time".

In CLI systems, removing the file would require an extra command (to change its status) or else an extra argument to the deletion command. Again, not really "a harder time".

who cares about the leftovers after the Thunderbird crash - every system has some tools to clean up the TEMP files... windows does this via GUI, most linux distributions clean up the /tmp folder on shutdown...

however, this is certainly a data loss case and developers should give this priority!

I just had the unpleasant experience of telling a user that all the documents she worked on today were gone forever because of this issue. She actually broke down and cried.

Well, thank you Ryan for caring for the users. Please, continue overlooking this issue as a minor problem and certainly there will be more cases of data loss and even tech newspapers will likely mention it.

Should someone Digg this maybe to make things fixed?

As far as I understand, all occurences of 0600 should be changed to 0400 here:
http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp
simple search&replace will do here.

however the problem lies in the TB handling files on Windows:
"Jon Henry 2007-01-31 09:07:24 PST
For what it's worth, I just tried to implement BZ's suggestion from comment #3.
It did not work on Windows XP, files were still read/write."

so, is there any way to make files Read only on Windows?

(In reply to comment #32)
> Well, thank you Ryan for caring for the users. Please, continue overlooking
> this issue as a minor problem and certainly there will be more cases of data
> loss and even tech newspapers will likely mention it.

DO NOT re-request blocking flags that have already been denied unless significant new information is available about its severity (e.g. a crash that turns out to be exploitable). That a missing feature happens to annoy you personally is not significant. As far as I know, this feature has *never* existed since the Netscape days, so it's apparently not even as big a deal as you think it is.

I wonder if a Eudora-like method is better - detaching attachments and keeping them in the folder on disk that contains the mail account...of course then if you edit the attachment you no longer have the original available.

Created an attachment (id=253951)
proposed patch for Unix systems

Please review patch.

On Fedora Core 5 Linux and TB 1.5.0.9, I tested "Open With" behavior with OpenOffice.org (.doc, .xls), .jpg, .pdf, and .zip. Also, I checked that "Save to Disk" was not affected.

Bug 280419 also has a patch... (that bug will fix this one too, they really can't be fixed independently in any easy way)

(From update of attachment 253951)
Thanks for the patch. this bug is really a dupe of Bug 280419 which already has a better patch being removed by the correct module owners for exthandler.

*** Bug 369375 has been marked as a duplicate of this bug. ***

*** Bug 371220 has been marked as a duplicate of this bug. ***

This is one of those rare cases where I prefer the Microsoft solution: If one is using MS Outlook and edits an attachment and saves the changes, the attachment is changed, and one sees the changes the next time one opens that e-mail message. If Microsoft can implement this, it shouldn't be that hard for the Mozilla folks. But, regardless of which solution you choose, implementing SOME solution is LONG OVERDUE!!!

Dr. Phillip M. Feldman

*** Bug 382525 has been marked as a duplicate of this bug. ***

Having recently upgraded about 100 users in our organisation to Thunderbird 2.06, we find it entirely inappropriate for a bug of this sort to exist in our email system. Among the people who have been stung by this is our CEO, who is now putting pressure on us to fix it. Can we put a bounty on this?

Fixed by Bug 280419

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007091604 Thunderbird/3.0a1pre ID:2007091604

I've just tested the latest non-beta version of Thunderbird under Windows XP Professional. I mailed an MS Word document to myself, edited it, closed the document, and reopened it. There is no question that the bug is still there.

(In reply to comment #43)
> I've just tested the latest non-beta version of Thunderbird under Windows XP
> Professional. I mailed an MS Word document to myself, edited it, closed the
> document, and reopened it. There is no question that the bug is still there.
>

What do you mean by "latest non-beta"? Unless you downloaded a nightly build of Thunderbird 3 from the last few days, the bug would not be fixed in the build you tried.

ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk

Ah. My apologies. I have just downloaded and installed the latest nightly build using the URL that you provided. This version of Thunderbird crashes almost instantly after I launch the exe, so I can't tell whether the bug in question has been fixed.

You can try a window trunk build again now that the crasher is gone... Did bug 280419 fix it on windows and mac?

I verified that this bug is fixed in

  Thunderbird version 3.0a1pre (2007091703) [linux-i686]

and

  Thunderbird version 3.0a1pre (2007100203) [win32].

Can anyone check it on a Mac?

Is there a chance we get this patch in TB2? Could be great to have it ASAP, with a security release if this solution is confirm not to raise other problems.

*** Bug 401858 has been marked as a duplicate of this bug. ***

Bugfix needed for TB2 ASAP! Users lost serveral filechangings and working time already.
Do not mark it as solved ... it's still happening in the actual TB versions.

Give the temp files a random prefix. Even reopening the modified file destroys the changings in temp.

It's amazing that 4 1/2 years have elapsed without any fix to this. I wonder if I will see a fix in my lifetime?

It's already fixed for tb3, that's why it reads RESOLVED FIXED.

Magnus, we will praise you for that!

However, this bug is so severe, that it *must* go into TB version 2 as well.

*** Bug 418994 has been marked as a duplicate of this bug. ***

*** Bug 426531 has been marked as a duplicate of this bug. ***

Sorry to comment on this again, but:
Is there any way (without editing the sources) to restore the old behaviour again? This may seems strange, but we definitely need this "bug" as a feature.

Workflow here currently is as follows: We receive Mails with Word/OOo/RTF-Attachments. Attachments are opened with OOo, a header is added to the file with various internal info and the file is saved-as to a network share and closed.

This worked as long as we were using Ubuntu 7.04 with TB1.5. Now with Ubuntu 8.04 and TB2, the files are opened as read-only in OOo, meaning you cannot edit the file at all, but have to first save-as, then edit, then save again and close.

This might seems only a small difference, but for >100 Mails a day it really *is* unneccessary additional work.

If there's any chance, I would make this a configurable option (at least via about:config).

IMHO, this is a problem with OpenOffice.org which should allow you to easily edit read-only files, simply warning you that you'll not be able to save it at the location it is currently. But instead of 'saving as' the file to edit it, you can just click on 'File edition' (or the like) in the toolbar, between 'Mail' and 'Export to PDF'.

This didn't go into thunderbird2 (unless ubuntu snuck it in to their custom version). Therefore the following may or may not apply to you.

For thunderbird3, there is already a way to get the old behaviour (and Mac users still will have it as default).
If you set browser.helperApps.deleteTempFileOnExit to false we won't set it to readonly in the first place either. xref bug 401316.

*** Bug 439867 has been marked as a duplicate of this bug. ***

Thank you Magnus. Yes, this has indeed been backported by the Ubuntu packagers, see https://bugs.launchpad.net/thunderbird/+bug/87101

Unfortunately, they made it non-configurable.

But I agree with Milan that this is also a OOo issue. Unfortunately, clicking "File edition" does not work also; it will cause OOo to tell you that the file cannot be edited and asks if you would like to open and save a copy. So you have to first "Save as" anyway.

A user at my organization experienced this bug on TB2.

As TB3 has not yet been released, and we are currently examining alternatives for upgrading our current email environment with a fairly short timeframe for a decision, the existence of this bug is a severe mark against adoption of TB.

For anyone interested, it seems the creator of Readonly Attachments has updated it to work with TB2. (It currently only works with TB1.5.) As of 2008-07-13 it's waiting for review at AMO. See http://yergler.net/blog/2008/07/10/readonly-attachments-for-thunderbird-2/

Any way to at least get the review completed faster?

*** Bug 469980 has been marked as a duplicate of this bug. ***

Uh, TB3 isn't still out, so I was also directed by my users to this issue on the Windows TB2 version. 6 years existed this dark issue now. :-| Looking forward to TB3 then and wondering when it will be born as stable release. Anyway, thanks for this mail client.

TB 3.0 will be out in a small number of weeks - we're very close.

but what about people who want to be able to edit the OpenOffice's document immediately after clicking on the attachment? I would like to have a choice or files should be read-only or not... In TB 3.0 I have no choice?