Skip to content

fix(firebase): return content type and plain file name from getFile - #947

Open
marianmoldovan wants to merge 1 commit into
mainfrom
fix/556-getfile-content-type
Open

fix(firebase): return content type and plain file name from getFile#947
marianmoldovan wants to merge 1 commit into
mainfrom
fix/556-getfile-content-type

Conversation

@marianmoldovan

Copy link
Copy Markdown
Collaborator

Fixes #556

The bug

getFile built its result with new File([blob], path), omitting the constructor's third argument. Without it File.type is "", even though the content type was already sitting on the fetched blob.

The fix

-return new File([blob], path);
+return new File([blob], fileRef.name, { type: blob.type });

Two changes, both deliberate:

{ type: blob.type } — Firebase serves the object's stored contentType as the response Content-Type, so blob.type is the stored metadata, arriving free with a response we already await. An extra getMetadata() round-trip would return the identical string.

fileRef.name instead of path — the full storage path was used as the File name, giving names like images/events/abc.png. Not cosmetic: the default filename builder composes randomString() + "_" + file.name, so re-uploading a fetched file created spurious nested pseudo-folders in Storage. fileRef.name is documented by @firebase/storage as the last path component, which avoids hand-rolling trailing-slash edge cases.

Blast radius checked first: only three getFile references exist in source (the interface, this implementation, and a throwing mock) and none reads File.name.

Not verified

packages/firebase_firecms has no test runner wired up, so no tests were added for a one-line fix. tsc --noEmit is clean for this file. Not exercised against live Firebase Storage — the blob.type behaviour rests on documented behaviour, not an observed round-trip.

🤖 Generated with Claude Code

`getFile` built its result with `new File([blob], path)`, omitting the
third `options` argument of the `File` constructor. Without it `File.type`
defaults to the empty string, so callers could not tell what kind of file
they had received even though the content type was already sitting on the
fetched `blob`.

The same call also used the full storage path as the `File` name, yielding
names like `images/events/abc.png`. A `File` name is a name, not a path,
and the slashes leak into consumers: the default filename builder in
`useStorageUploadController` composes `randomString() + "_" + file.name`,
so re-uploading a fetched file created spurious nested folders in Storage.

Pass `blob.type` through as the content type and use `fileRef.name` (the
last path component, exposed by the Storage reference) as the file name.
`blob.type` is the `Content-Type` that Firebase Storage serves for the
object, i.e. its stored `contentType` metadata, so no extra `getMetadata`
round-trip is needed.

Fixes #556

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR fixes StorageSource.getFile in the Firebase Storage implementation so returned File objects carry the correct MIME type and a plain filename (instead of the full storage path), aligning the behavior with the stored object metadata and preventing path-like File.name values.

Changes:

  • Pass { type: blob.type } to the File constructor so File.type is not empty.
  • Use fileRef.name (last path component) instead of the full storage path for File.name.
  • Add explanatory inline comments documenting the rationale for both changes.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines 137 to 138
const response = await fetch(url);
const blob = await response.blob();
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

storageSource.getFile method does not return file type

2 participants