cloudFile API: onFileDeleted no longer fired when attachments are deleted
Categories
(Thunderbird :: FileLink, defect)
Tracking
(Not tracked)
People
(Reporter: tdulcet, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [wontfix?])
Steps to reproduce:
- Install a FileLink provider add-on. I would recommend my FileLink provider for Send add-on because it displays a notification when the attachments are deleted.
- Attach a file to an e-mail.
- Link the attachment with the FileLink add-on and wait for it to upload.
- Click on the attachment and press the "Backspace" or "Delete" keys.
Actual result:
The attachment is deleted from the e-mail.
Expected result:
The attachment is deleted from the e-mail and the FileLink server.
With the latest Thunderbird 102, Beta and Daily, the files are NOT deleted from the server because the cloudFile.onFileDeleted event never fires. With Thunderbird 91, the event correctly fires and the file is deleted from the server. This could be a major privacy/security issue for users, as it can leave sensitive files/information on the server, which the user would think was deleted.
I should note that when selecting "Remove Attachment" from the context menu, the files are deleted from the FileLink server as expected.
|
Reporter | |
Updated•2 years ago
|
|
||
Comment 1•2 years ago
|
||
I cannot confirm this for "standard" usage in 102 and 106 (using the proposed FileLink provider for Send).
However, there is a special case: When the uploaded file (to be exact: its link) has been used already in a sent message (or the message has been saved as a draft), then it will not be deleted from the server if it is removed from the message, as that would invalidate the link in the already send/saved message.
Drafts are difficult, as you can
- save draft
- delete upload from message
- close without saving
- re-open draft
- link is back (and would be invalid if we had removed the upload)
I figured that keeping the file on the server in these cases is doing more good than bad (no dead links on the receiving end). Rapid auto-draft-saving could give the impression that removed uploads are never removed from the server, but that is a side effect we have to accept, I think.
|
|
||
Updated•2 years ago
|
|
|
Reporter | |
Comment 2•2 years ago
|
||
(In reply to John Bieling (:TbSync) from comment #1)
I cannot confirm this for "standard" usage in 102 and 106 (using the proposed FileLink provider for Send).
Hmm, I am not sure how this could not be a regression, as it is a difference in behavior between Thunderbird 91 and 102. It is also a difference in TB 102 between using the keyboard and context menu.
However, there is a special case: When the uploaded file (to be exact: its link) has been used already in a sent message (or the message has been saved as a draft), then it will not be deleted from the server if it is removed from the message, as that would invalidate the link in the already send/saved message.
My "FileLink provider for Send" add-on sets the reuse_uploads Manifest property to false, so uploads should never be reused in any case. The issue is that when the attachment is deleted (using the keyboard) and the links are removed from the message, cloudFile.onFileDeleted event never fires, so the file is not actually deleted from the server as the user expects.
|
|
||
Comment 3•2 years ago
|
||
I removed the regression keyword, as the change was intended and not a drive-by.
I was not (yet) able to reproduce a difference between using the DEL key and the context menu (of the attachment).
My "FileLink provider for Send" add-on sets the reuse_uploads Manifest property to false, so uploads should never be reused in any case.
Independent of that setting, a saved draft still requires the file to be kept.
Can you reproduce any of this with disabled draft-saving (just to make sure there is no draft involved) and not using an entry from the re-attach menu but picking a file from the disc? Can you give detailed steps-to-reproduce?
|
|
Reporter | |
Comment 4•2 years ago
|
||
(In reply to John Bieling (:TbSync) from comment #3)
Independent of that setting, a saved draft still requires the file to be kept.
I do not understand the reasoning for that, as a saved draft is not sent to anyone, so there is no need to preserve the file. For my add-on, once the link is removed from the message, there would be no way for the user or anyone to access the file unless they manually copied the link before it was removed.
Can you reproduce any of this with disabled draft-saving (just to make sure there is no draft involved) and not using an entry from the re-attach menu but picking a file from the disc?
No, I can no longer reproduce this after disabling that auto draft saving feature. It seems this is the regression from TB 91, that files can no longer be deleted from the server after a draft is saved.
|
|
||
Comment 5•2 years ago
•
|
||
I do not understand the reasoning for that, as a saved draft is not sent to anyone
But it can be! Just try it out please:
- open a new message
- add a cloudFile
- save as draft
- close the draft
- reopen the draft
- delete the upload
- make changes to other parts of the draft
- close without saving (simulating a "oh, I do not like these changes, lets re-start with the saved state")
- re-open the draft (link is back!)
- send the message without deleting the link
- the receiving end will be able to download the link, as it has not been deleted from the server
You may call this a change in behaviour, which you do not like, but it is not a regression.
I am open for changes to cater for security focused users, who want to enforce deletion even if it could cause dead links.
|
|
Reporter | |
Comment 6•2 years ago
|
||
(In reply to John Bieling (:TbSync) from comment #5)
You may call this a change in behaviour, which you do not like, but it is not a regression.
OK, that makes sense, thanks for explaining your logic.
I am open for changes to cater for security focused users, who want to enforce deletion even if it could cause dead links.
When editing a draft, I would propose that the file be deleted from the server when the updated draft is explicitly saved (or the message is sent). For messages with only auto saved drafts (no manually saved drafts) since the link was added, the file should also be deleted when the user clicks the "Discard Changes" button, which deletes all those drafts. This should eliminate all cases where deleted attachments are erroneously left on the server.
|
||
Comment 7•2 years ago
|
||
I would suggest this is wontfix.
Someone might create a draft just to get the file uploaded, and send the link through other means (e.g. chat). We can't know all the ways the link will be used.
|
|
||
Comment 8•2 years ago
|
||
I was thinking about an option, that the add-on could request secure delete, but I have not started to work on this. I do not mind letting this open and wontfixing it later, after I tried addressing this and we could not find a workable solution.
|
|
Reporter | |
Comment 9•2 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #7)
Someone might create a draft just to get the file uploaded, and send the link through other means (e.g. chat). We can't know all the ways the link will be used.
I was only suggesting in comment 6 that the file be deleted from the server after the user explicitly removes the attachment, which was the behavior in Thunderbird 91. I agree that simply creating and then discarding a draft should not delete the file. Anyway, your specific scenario would be fixed by Bug 783477.
Description
•