compose.ComposeAttachment should contain a cloudFile status
Categories
(Thunderbird :: Add-Ons: Extensions API, enhancement)
Tracking
(Not tracked)
People
(Reporter: je, Unassigned, NeedInfo)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
- Add an attachment to a message
- Get the attachment's properties, eg via compose.listAttachments
- Upload the attachment to a Filelink provider (which triggers events of the cloudFile API).
- Get the attachment's properties again
Actual results:
The properties of the attachment are identical before and after the upload.
Expected results:
It should be possible to determine, if an attachment has been uploaded to a Filelink provider.
Suggestion: Add a cloudFileStatus property to the compose.ComposeAttachment type. It should have 5 states:
- local (or regular or normal) for an attachment not handled by cloudFile
- uploaded after a successful upload
- uploading, if a cloudFile.onFileUpload event is pendig for this attachment
- aborting, if a cloudFile.onFileUploadAbort event is pendig for this attachment
- deleting, if a cloudFile.onFileDeleted event is pending for this attachment
An additional property might be useful that contains points to the cloudFile account that's handling this attachment. It could be 0, undefined or null if cloudFileStatus==local and contain the accountId otherwise.
|
||
Comment 1•4 years ago
|
||
This sounds reasonable and necessary to me.
|
|
||
Comment 2•4 years ago
|
||
Geoff, fyi, this sounds like a reasonable and well-thought-out proposal to me. Reporter filed a cluster of related bugs which I linked up in see also, and you've commented on Bug 1669829 Comment 3.
|
Reporter | |
Comment 4•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #3)
IIRC progress data is not internally available either.
Do you mean uplaod progess? That's because the API doesn't define a way for a Filelik provider to inform Thunderbird about its progress. See the documentation of the cloudfile API.
|
||
Comment 5•4 years ago
|
||
Correct.
|
|
Reporter | |
Comment 6•4 years ago
|
||
This is especially bad in Thunderbird 82+ which explicitly allows Addons to modify attachments in an on BeforeSend handler. But the modified attachment is ignored because it is not uploaded again or sent with the message.
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 7•3 years ago
|
||
Maybe instead of a state variable it could be implemented as an isCloudfile() function that returns a Promise? It would resolves to false for a regular attachment and to true after the pending cloudFile events for this attachment are handled. It would basically reproduce the state of the icon in the attachment pane (after bug 1667652 is fixed), not resolving while the spinner is there.
|
|
Reporter | |
Comment 8•3 years ago
|
||
What should ComposeAttachment.getFile()do for an uploaded CloudFile attachment?
- Return the file that was originally uploaded? Is that guaranteed to be identical to the file on the server?
- Fetch the file via the url that
cloudFile.onFileUploadreturned? Timing? - Return null or some other kind of error?
|
|
Reporter | |
Comment 9•3 years ago
|
||
(In reply to Johannes Endres from comment #7)
Maybe instead of a state variable it could be implemented as an
isCloudfile()function that returns a Promise? It would resolves tofalsefor a regular attachment and totrueafter the pending cloudFile events for this attachment are handled. It would basically reproduce the state of the icon in the attachment pane (after bug 1667652 is fixed), not resolving while the spinner is there.
Or reduce to three states: (local, uploaded, neither) with the third state returned while the spinner is spinning.
|
||
Updated•3 years ago
|
|
|
||
Comment 10•3 years ago
|
||
(In reply to Johannes Endres from comment #6)
This is especially bad in Thunderbird 82+ which explicitly allows Addons to modify attachments in an on BeforeSend handler. But the modified attachment is ignored because it is not uploaded again or sent with the message.
This has been fixed by bug 1669829.
(In reply to Johannes Endres from comment #7)
Maybe instead of a state variable it could be implemented as an
isCloudfile()function that returns a Promise? It would resolves tofalsefor a regular attachment and totrueafter the pending cloudFile events for this attachment are handled. It would basically reproduce the state of the icon in the attachment pane (after bug 1667652 is fixed), not resolving while the spinner is there.
I was planing to expose the cloudFile account ID as part of the ComposeAttachment type. If it is not specified, it is a "local" attachment. At a later time, there will be more things one could do with the cloudFile account IDs, like converting attachments to/from/between cloudFile accounts.
(In reply to Johannes Endres from comment #8)
What should
ComposeAttachment.getFile()do for an uploaded CloudFile attachment?
- Return the file that was originally uploaded? Is that guaranteed to be identical to the file on the server?
- Fetch the file via the url that
cloudFile.onFileUploadreturned? Timing?- Return null or some other kind of error?
It returns the original file stored in the attachment (it is still "there" while composing or saving it as a draft, only during send it gets removed). The cloudFile provider should never change the file behind a link, to not invalidate attachments/links in already send messages. Manually replacing files on the server, which have been uploaded by the cloudFile provider, is a very bad idea and I do not want to add code to actually support such thing. So adding a fetch to download the file from the server each time the attachment is requested is not something I want to add. Do you agree?
(In reply to Johannes Endres from comment #9)
Or reduce to three states: (local, uploaded, neither) with the third state returned while the spinner is spinning.
Hm, a file being uploaded is still considered local. Only after the upload finished and succeeded, its metadata is updated to represent a cloudFile. What use case do you have in mind, where the uploading state could be of interest?
Description
•