Open Bug 1856232 Opened 2 years ago Updated 1 year ago

cloudFile API: Allow consolidation of multiple attachments into a single cloudFile link

Categories

(Thunderbird :: Add-Ons: Extensions API, enhancement)

Product:
Thunderbird
Component:
Add-Ons: Extensions API
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: tdulcet, Unassigned)

Details

When the user attempts to upload multiple attachments at once, FileLink add-ons should have the option of consolidating (e.g. compressing or zipping) them into a single file, which results in just a single link that is added to the message. This is what many users already expect to happen automatically and it is one of the top requested features of my FileLink provider for Send add-on (implements Bug 1516252), as the web UI for Send already does this. This also make it much easier and faster for the recipients to download all the attachments, especially if a password is required.

FileLink add-ons could consolidate the attachments into a single file using the new (as of Firefox/Thunderbird 113) Compression Streams API or an external library. However, there is currently no way for add-ons to tell Thunderbird from the cloudFile onFileUpload event to add just a single link to the message for all of those attachments, so this results in duplicate links for each attachment and incorrect filenames/sizes. FileLink add-ons could instead abort the upload for all but one of the attachments, but would still result in an incorrect filename/size and the user would then likely presume that the other files failed to upload.

A potential solution may be for Thunderbird to detect duplicate URLs returned by the onFileUpload events and then only add a single link for those attachments. Additionally, new keys would likely need to be added to the CloudFileTemplateInfo object to specify the filename and size of the resulting compressed file.

Thanks for the suggestion. I tried to come up with a workflow, which would minimize the required code changes:

  • user adds attachments as standard attachments
  • user selects multiple attachments and finds a new context menu entry: "compress attachments into single zip file attachment"
  • the attachments will be zipped, removed from the message and the new zip file is added
  • the zip file can be converted to a cloudFile attachment
  • note: after the zip file has been created, the user could be prompted to select a cloudFile provider for upload, to reduce mouse clicks

This would add general zip capabilities to the composer and would not require changes to the cloudFile code.

How does that sound?

(In reply to John Bieling (:TbSync) from comment #1)

How does that sound?

Thanks, that sounds great and better than my proposal, as it would then give all users the ability to zip their attachments, while not requiring any additional work for each cloudFile extension developer.

Maybe TB could automatically prompt the user in the notification bar to zip their attachments when they add more than one file that is not already compressed. This would be similar to the existing suggestion to use FileLink when adding more than 5 MiB total of attachments (by default).

Note that while the majority of users would likely want to use zip, as it is widely supported, some advanced users might want to select a different (more efficient) compression algorithm to use, especially when working with very large files. The Compression Streams API I mentioned supports both gzip and deflate. I am not sure what other implementations TB might have access to internally (if any).

Most providers actually reject messages with zipped attachments. And since you need a decompression software on the receiving end, I would not make it a proposed action. Unzipping something on a phone is not so easy.

We might end up with limiting this to cloudFile, by naming the menu entry "Zip and send to cloudFile" and do all steps in one go (zip, replace attachments in messages, convert zip to cloudFile).

I will discuss this with product management.

Feedback from the team:

  • general support for merging attachments before uploading
  • we do not want to expose a stand-alone zip feature without using a cloud file provider, because users may run into mail server rejections, which could worsen their overall user experience

Things to consider:

  • should the large attachment prompt offer this as an option?
  • we seem to not be able to create zip files larger than 2GB
  • how to deal with hitting a cloud provider upload limit (let's say limit is 50MB, 4 files of 20MB each will work, but a single zip file of 51MB will fail)

(In reply to John Bieling (:TbSync) from comment #4)

  • we do not want to expose a stand-alone zip feature without using a cloud file provider, because users may run into mail server rejections, which could worsen their overall user experience

Interesting, I have never personally experienced a rejection due to attaching a zip file (same with bug 1830941), so I still believe allowing users to consolidate regular attachments would be a useful feature for most users, even if Thunderbird did not prompt to do so automatically. Actually, zipping attachments is sometimes needed work around server file type restrictions. Of course, limiting this functionality to FileLink provider add-ons (this bug) would still be a major improvement.

  • should the large attachment prompt offer this as an option?

Yes, if there is more than one attachment.

  • we seem to not be able to create zip files larger than 2GB

Most Send service instances support files up to 5-10 GiB and some up to 100 GiB, so maybe consider using the Firefox Send zip library, which I do not believe has any such limitations and being part of a Mozilla product is already licensed MPL.

  • how to deal with hitting a cloud provider upload limit (let's say limit is 50MB, 4 files of 20MB each will work, but a single zip file of 51MB will fail)

This is more tricky, as it is likely not possible to know in advance how large the resulting zip file might be without actually performing the compression, which could of course be computationally expensive (take a nontrivial amount of time). Maybe if the user asks to zip their attachments before upload and resulting zip file ends up being too large, just show an error message and ask if they want to upload their files individually instead.

You need to log in before you can comment on or make changes to this bug.