Closed Bug 220808 Opened 21 years ago Closed 17 years ago

should open attachments readonly mode - changes to attachment are lost if user does not a explicit "save as..."

Categories

(MailNews Core :: Attachments, defect)

Product:
MailNews Core
Component:
Attachments
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: marco, Assigned: mscott)

References

Details

(Keywords: dataloss)

Attachments

(1 file)

proposed patch for Unix systems
877 bytes, patch
mscott
: review-
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6a) Gecko/20030930 If a (unaware) user opens an attachment directly from the mailclient in an external application (eg. MS-Word) and does not save the changes with "save as..." but by pressing the "save" button, as he is used to, all changes are lost (maybe many hours...), because the temporary file will be deleted without a warning, when he exits mozilla. Reproducible: Always Steps to Reproduce: 1. Open Word-Attachment by double-clicking it 2. Make some changes to it 3. Press the "save" button 4. Exit Word and mozilla Actual Results: All changes made to the document are lost. Expected Results: Mozilla should tell Word to open the document in read-only mode. (Outlook behaviour) - or - Mozilla should notice (eg. at exit) that a temporary saved attachment has changed and give the user the possibility to save it or to discard the changes.
Confirming on 20030930 nightly trunk build, Win2k. I couldn't find an obvious dupe of this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Product: MailNews → Core
*** 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. ***
Assignee: sspitzer → nobody
QA Contact: stephend → attachments
*** 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.
Summary: Changes to attachment are lost if user does not a explicit "save as..." → should open attachments readonly mode - changes to attachment are lost if user does not a explicit "save as..."
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!.
Flags: blocking1.8.1.2?
Flags: blocking1.8.0.10?
Flags: blocking-thunderbird2?
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"
Assignee: nobody → mscott
Flags: blocking1.8.1.2?
Flags: blocking1.8.1.2-
Flags: blocking1.8.0.10?
Flags: blocking1.8.0.10-
Keywords: dataloss
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...
Depends on: 280419
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.
Flags: blocking-thunderbird2? → blocking-thunderbird2-
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.
Flags: in-testsuite+
Flags: blocking1.8.1.3?
Flags: blocking1.8.1.2?
Flags: blocking1.8.1.2-
Flags: blocking1.8.0.11?
Flags: blocking1.8.0.10?
Flags: blocking1.8.0.10-
Flags: blocking-thunderbird2?
Flags: blocking-thunderbird2-
Flags: in-testsuite+
Flags: blocking1.8.1.3?
Flags: blocking1.8.1.2?
Flags: blocking1.8.0.11?
Flags: blocking1.8.0.10?
Flags: blocking-thunderbird2?
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.
Attached patch proposed patch for Unix systems — — Splinter Review
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.
Attachment #253951 - Flags: review?(mscott)
Bug 280419 also has a patch... (that bug will fix this one too, they really can't be fixed independently in any easy way)
Comment on attachment 253951 [details] [diff] [review] proposed patch for Unix systems 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.
Attachment #253951 - Flags: review?(mscott) → review-
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
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
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
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.
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.
Flags: blocking1.8.1.13?
Flags: blocking1.8.1.13?
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.
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.
Product: Core → MailNews Core
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?
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?
They can still edit it, but OpenOffice will prevent them from saving the file to a temp folder. ATM, you have to click on a toolbar button to go to editing mode before doing changes, but that's an OpenOffice implementation detail/flaw.
No, actually starting from OpenOffice 3.0 they can't - OO 3 won't allow to edit read-only documents. Only after saving it to a different location (or under different name), it allows user to edit it. It says "(Read only)" in the document title in the main window tab.
Hmm... Maybe is there any way to change the temporary folder for opening files from the attachment?
(In reply to comment #67) But with TB 2.0 ant OOo 3 this problem not exist...
It exists with other software than OOo3 as well. i.e. Open xls file form a mail edit it save it and reopen from the mail and all changes are gone.
(In reply to comment #70) No, it's not what I mean. OpenOffice prevents any action on the file marked "read only", for an inexperienced user it is very good(!), but what about the users aware that they working on file in the temporary folder?
I just think that it would be nice if it included somewhere in about:config option to enable the behavior of the attachments as is in TB2
tomi: OO.o 3 has an "Edit document" toolbar button that does what you are requesting. In any case, that's OpenOffice's problem, not Thunderbird's.
experienced users(In reply to comment #71) > No, it's not what I mean. OpenOffice prevents any action on the file marked > "read only", for an inexperienced user it is very good(!), but what about the > users aware that they working on file in the temporary folder? experienced users rather figure out that they just have to use the "save as..." function an can edit the program like normal. or the would do this anyway before editing. I think you could also do it like Outlook: Take the edited file back into the mail, but also keep the old version stored.
Hold it, this is not a fix, this is building in a bug. I've worked fine with Thunderbird 2 for many years and all of a sudden I can't open attachments in editable mode anymore. It's been clear that this was stored in a temp folder to every halfway intelligent person out there. Restricting to read only is the worst bug 'fix' I've ever seen. Especially with the drag and drop not working any longer (#377621) it makes TB3 almost unusable.
(In reply to comment #75) > Hold it, this is not a fix, this is building in a bug. I've worked fine with > Thunderbird 2 for many years and all of a sudden I can't open attachments in > editable mode anymore. It's been clear that this was stored in a temp folder to > every halfway intelligent person out there. Restricting to read only is the > worst bug 'fix' I've ever seen. Especially with the drag and drop not working > any longer (#377621) it makes TB3 almost unusable. And what'S the problem with clicking "save as" in the program that opened the file? Then you can edit it and do anything else. If you know what a temp-directory is then youa lso should know about that I think. But not the other way round.
Oh dear, the correct solution is quite clear: obviously there is a list of created temp-files. This list has to be extended by the creation date of each file. If the file-modification-date is the original creation date, clear the file on exit, otherwise leave it or (that would be the cherry on the cake) list it and let the user decide.
I agree to Marco - it should be easy to improve that solution so that everyone is happy.
See Also: → https://launchpad.net/bugs/87101
I agree with #75 - this is a terrible change. If I open a spreadsheet in OpenOffice I can't even adjust the width of the columns to where I can see all of the data -- not without having to save the file, which I don't even need to do. If you want a really simple fix, simply show an alert to the user, letting them know that attachments are in a temp folder etc etc. Have a checkbox "Do not remind me again". Problem solved.
Jeremy: see comment 73. OpenOffice.org, which is the main culprit here, now has a toolbar button to make the document editable. I've opened bug 605417 on the alternative fix. But I'm not totally sure it's the right thing myself. Gerv
Another (more difficult) way is to first launch the attachment as editable and then set the readonly flag 10 seconds later. That will trick the application in thinking it is editable, and when it comes time to save, OOO will fail and prompt the user. It will also allow me to rotate images in Windows XP Picture Viewer to be right-side-up in the first 10 seconds that I open the photo.
(In reply to em_te from comment #81) > Another (more difficult) way is to first launch the attachment as editable > and then set the readonly flag 10 seconds later. This is more likely to confuse apps and users than anything. OpenOffice should be fixed to have a easier to understand GUI.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: