fix(eml-preview): recover PDF MIME type from extension when email declares octet-stream (ERMAIN-550) - #928
Merged
Merged
Conversation
…lares octet-stream When an email client sends a PDF attachment with Content-Type: application/octet-stream instead of application/pdf, the browser treats the blob URL as a binary download rather than rendering it inline in the iframe. The download filename defaults to the bare UUID from the blob URL since there is no filename metadata associated with blob:// URLs. Fix: add recoverMimeType() that uses the filename extension to upgrade a generic application/octet-stream to the specific type (pdf, eml) before creating the Blob. Apply this both to the blob itself (so the browser renders inline) and to ParsedAttachment.mimeType (so FilePreviewContent routes correctly). Applies to both EmlPreviewBody (direct attachments) and EmlThreadBody (nested thread message attachments). Fixes ERMAIN-550 Co-authored-by: Daniel <bdart@users.noreply.github.com>
PostalMime types `Attachment.filename` as `string | null`, so the helper signature broke the frontend library build and every job downstream of it. Co-authored-by: linear-code[bot] <222613912+linear-code[bot]@users.noreply.github.com>
bdart
force-pushed
the
feat/eml-attachment-mime-fix-e7cb
branch
from
August 9, 2026 15:22
39cc7bb to
86783fb
Compare
bdart
marked this pull request as ready for review
August 9, 2026 15:32
bdart
enabled auto-merge (squash)
August 9, 2026 15:40
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When viewing an EML email preview and clicking a PDF attachment listed inside the email, the browser downloads the file instead of opening a nested inline preview. The downloaded file has no extension — the filename is a bare UUID (the UUID portion of the blob URL).
Root cause: Email clients sometimes send PDF attachments with
Content-Type: application/octet-streaminstead ofapplication/pdf. WhenEmlPreviewparses such an email via PostalMime, it creates aBlobtyped asapplication/octet-stream. Browsers treat blob URLs with that content type as binary downloads rather than rendering them inline in an<iframe>. Sinceblob://URLs carry no filename metadata, the download filename defaults to the blob's UUID.Fix
Added
recoverMimeType()inEmlPreview.tsx— a small helper that upgrades a genericapplication/octet-streamMIME type to a more specific one derived from the filename extension, before the Blob is created. Currently maps:.pdf→application/pdf.eml→message/rfc822Applied in two places:
attachmentBlob()— ensures the Blob itself has the correct type, so<iframe src={blobUrl}>renders inline rather than triggering a download.ParsedAttachment.mimeType— ensuresFilePreviewContentalso receives the recovered type for routing (e.g.isPdfcheck).Both
EmlPreviewBody(direct attachments) andEmlThreadBody(nested thread message attachments) are covered.Tests
Added 4 new test cases in
EmlPreview.test.tsx:application/pdf-typed PDF shows the inline PDF viewer (file-preview-pdf) with a working back button.application/octet-stream-typed PDF (the bug scenario) also shows the inline PDF viewer — not a download.application/octet-streamPDF attachment has its MIME type recovered toapplication/pdf(directly verifies the fix prevents the browser from triggering a download).