[Feature]: Support transferable & cloneable entries via postMessage, with same-origin restriction

[jimmywarting]

Hi,

I'd like to propose an enhancement to the Entries API: enable FileSystemEntry objects — including FileSystemFileEntry and FileSystemDirectoryEntry — to be transferable or at least structured cloneable so they can be sent via postMessage, within the same origin.

Problem

Currently, FileSystemEntry objects cannot be passed via postMessage because they are neither Transferable nor StructuredCloneable. This limits their usability in modular or multi-context applications.

Use cases like transferring directory trees or file references between iframes, web workers, or different windows (all same-origin) require awkward workarounds such as serializing file paths or re-requesting entries.

Proposal

Make FileSystemEntry objects structured cloneable (and optionally transferable) so they can be sent with postMessage. To ensure user privacy and security:

• They should only be cloneable/transferable within the same origin
• Attempts to send to another origin (cross-origin messaging) should throw or fail silently

This would align well with other origin-bound objects (e.g. MessagePort), and preserve the safety guarantees expected of file-related capabilities.

Benefits

• Enables better architecture between UI and worker/iframe contexts
• Reduces need for global state or redundant entry resolution
• Promotes more seamless drag-and-drop or directory processing experiences

Example use cases

• A worker script that walks a directory tree from entries obtained in the main thread
• Sharing directory entries between windows or tabs of the same app (via postMessage, etc.)

I believe this change would significantly improve the ergonomics of working with entries in complex web applications, while maintaining safe origin boundaries.

Thanks for your consideration!