750254 - Deleting Filelinks from a message saved as a draft does not work as expected

Status: RESOLVED DUPLICATE of bug 1605931

(Thunderbird :: FileLink, defect)

Description

[Mike Conley (:mconley) (:⚙️)]

STR:

1)  Create a new message, and attach a Filelink
2)  Save the message and close it
3)  Re-open the message, and remove the attachment in the attachment bucket.

What happens?

The attachmentitem gets removed but the URL in the body of the message stays.  The file is also not deleted on the server that we uploaded to.

What's expected?

Users would probably expect this to work the same way as it did if they hadn't saved as a draft - removing the attachmentitem should remove the URL from the message body, and delete the file at the storage service.

Comment 1

[David :Bienvenu]

that makes me think that the dom nodes that are generated when we load the draft aren't the same as when we created the links in the editor in the first place, which breaks the code that tries to find the links in the compose window. My suspicion is that it will be easier to fix the latter code.

Comment 2

[Mike Conley (:mconley) (:⚙️)]

Hm.  The URL insertion code operates strictly upon DOM IDs, as opposed to held references to nodes.

So I'm more inclined to think that the problem is in the deleteFile function for both Dropbox and YouSendIt.

In both of those implementations, a _uploadInfo collection is associated with an instance of the provider, and is used to store the information that we need in order to delete a file.

When a draft is saved, and then restored, this information is lost.  Calling deleteFile for either provider fails because it doesn't have any _uploadInfo values for the file key.

Comment 3

[David :Bienvenu]

oh, you're right...we'd have to persist the itemID (for YSI) in the draft info, and restore it into the upload info when the draft is loaded. This would mean adding a parameter to the attachment object so nsMsgSend can get the itemID. We could make it a parameter to the cloud url, as long as we remember to strip it off on load.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

I think Dropbox is the same idea - we need to store the path to the file in the draft info.

Hrm.  Now we get into the tricky bit where the internals of these nsIMsgCloudFileProviders get loaded up with the draft data... how best do we do that?

Comment 5

[David :Bienvenu]

http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/mimedrft.cpp#237 is where we transition the file link info from the draft message to the compose window and here is where we go the other way - http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgSend.cpp#1185

telling the cloud file providers about the itemID/file path for drafts might require a new method on the cloud file providers. Or we could make the compose window responsible for keeping track of the item information, which would also require changing a few methods to take item ids instead of nsIFile's.

Comment 6

[John Bieling]

Working on it, but using the newer bug.