Confirmed users
360
edits
No edit summary |
|||
Line 1: | Line 1: | ||
This page is not comprehensive. Right now, think of it as a place where we put answers to questions that are asked when they are asked. If you know the answer to a question, or think you know, please just update this page! Just put who is answering the question and when they are answering it in parens. If you know there is a bug filed on implementing something, or even a WONTFIX bug, please update the page! Thanks! | This page is not comprehensive. Right now, think of it as a place where we put answers to questions that are asked when they are asked. If you know the answer to a question, or think you know, please just update this page! Just put who is answering the question and when they are answering it in parens. If you know there is a bug filed on implementing something, or even a WONTFIX bug, please update the page! Thanks! | ||
Also note that all of these values are based on the code that is in the official Mozilla tree. Actual shipping devices may have altered some constants, although hopefully that's not the case. | |||
Line 10: | Line 12: | ||
=== Sending Attachments === | === Sending Attachments === | ||
* Maximum | * Maximum aggregate size of all attachments: | ||
** Future: {{bug| | ** Future: {{bug|1040861}} will raise the sending limit to 25 MiB. This should probably happen in v2.1 but is not guaranteed. | ||
** v1. | ** v1.4+: 5 megabytes. {{bug|982779}} fixed the memory-backed blob issues (and other blob issues), so this should all work quite well. | ||
** v1.1-v1.2: | ** v1.3, v1.3t: 5 megabytes. Memory usage should be reduced from this version onwards because {{bug|871897}} implemented send streaming. Because of {{bug|982779}} large memory-backed (as opposed to Device-Storage/IndexedDB file-storage-backed) Blobs may pose a problem, but the Camera app has been fixed in these releases so no built-in apps have this problem. | ||
** v1.1-v1.2: 5 megabytes, memory usage will be high. | |||
** v1.0.1: No size limit, likely to crash on 256MB devices if aggregate attachment size exceeds 5 megabytes. | ** v1.0.1: No size limit, likely to crash on 256MB devices if aggregate attachment size exceeds 5 megabytes. | ||
* Attachment types supported | * Attachment types supported | ||
Line 28: | Line 31: | ||
** Images (image/*): '''YES''', v1.0.1 onwards | ** Images (image/*): '''YES''', v1.0.1 onwards | ||
** Audio files (audio/*): '''YES''', v1.1 onwards. | ** Audio files (audio/*): '''YES''', v1.1 onwards. | ||
** Video | ** Video files (video/*): '''YES''', v1.1 onwards | ||
** PDF files, other file types: '''NO''' | ** PDF files, other file types: '''NO''' | ||
* Maximum allowed size of a single attachment to be downloaded. Note that per the next point, large message downloads may still crash the email app, depending on device memory! | |||
** v2.0+: 20 MiB. This is nearly no limit. Most mail providers limit mail sizes to 25 MB. We will raise this when we raise the send limit. | |||
** v1.4: no limit | |||
** v1.3t: 1 MiB | |||
** v1.0.1-v1.3: no limit | |||
* Downloading large attachments | * Downloading large attachments | ||
** v1.3+: A single huge download may crash the app depending on available device memory. {{bug|871897}} improved our cache management of downloaded attachments, but {{bug|943798}} which is dependent on platform improvements means that single attachment downloads may still cause problems. | |||
** v1.0.1-v1.2: A single huge download or multiple downloads of any size across multiple messages in succession may crash the app if the user does not switch folders or scroll the message list sufficiently to cause the cache to flush the downloaded message. | ** v1.0.1-v1.2: A single huge download or multiple downloads of any size across multiple messages in succession may crash the app if the user does not switch folders or scroll the message list sufficiently to cause the cache to flush the downloaded message. | ||
* Caveats | * Caveats |