thunderbird
Send the file name with extension when sharing/opening to another app
Checklist
- [X] I have used the search function to see if someone else has already submitted the same bug report.
- [X] I will describe the problem with as much detail as possible.
App version
6.804
Where did you get the app from?
Google Play
Android version
14
Device model
No response
Steps to reproduce
- Go to an email with a PDF attachment
- Click it
- Open with a PDF viewer (google pdf viewer or GrapheneOS's PdfViewer) (https://github.com/GrapheneOS/PdfViewer/issues/334)
- Click on share and use K-9 mail, write an email and notice the attached file has no extension
if you actually send the email thinking you attached a PDF, without any file extension the recipient will not be able to use it.
Maybe this is related to https://github.com/thunderbird/thunderbird-android/issues/2789
Expected behavior
Have the .pdf extension
Actual behavior
No extension
I actually thinked it was due to GrapheneOS's PdfViewer: https://github.com/GrapheneOS/PdfViewer/issues/334 But they said it is in K-9 mail and say it also can be reproduced by using google pdf viewer
Logs
No response
The problem is not limited to a specific attachment type or viewer app.
The problem is that when opening an attachment for viewing, the app uses AttachmentTempFileProvider without setting a display name. This leads to the name of the internal temporary file the app creates when opening an attachment to be used. However, it's just a SHA1 hash without a file extension. When sharing the content to another app (or back to K-9 Mail), the viewer app simply uses the name it has (which is not the right one).
This can be fixed by adding a displayName parameter to AttachmentTempFileProvider.createTempUriForContentUri() and then changing
https://github.com/thunderbird/thunderbird-android/blob/2f279ea3ee3976518ce853d26c4c08006678f5ef/legacy/core/src/main/java/com/fsck/k9/provider/AttachmentTempFileProvider.java#L51
to
Uri tempFileUri = FileProvider.getUriForFile(context, AUTHORITY, tempFile, displayName);
Reopening this issue because PR #8048 fixes an entirely different issue.
