Front components: <input type="file"> opens the picker but the selected File never reaches the component (no change event / files not marshaled through Remote DOM)

[pankaj-mgd]

Bug / feature gap

In an application front component (twenty-sdk), an <input type="file"> renders and the native file picker opens on click — but after the user selects a file, nothing reaches the component: the onChange handler never fires (or fires without target.files), so the File object is unreachable from app code.

Environment

• Self-hosted, twentycrm/twenty:latest (pulled 2026-08-05, image c98904f79a2d) — also reproduced on the June 2026 image
• twenty-sdk 2.27.0
• Front component mounted as a FRONT_COMPONENT widget in a RECORD_PAGE page-layout tab

Repro

const Picker = () => (
  <input
    type="file"
    onChange={(e: any) => {
      // never reached after choosing a file
      console.log(e.target?.files?.[0]);
    }}
  />
);

1. Mount in a record-page tab, click the input → OS file dialog opens ✅
2. Choose any file → no change event, no files, no error ❌

Tried: visible input, label-wrapped hidden input, transparent overlay input — picker always opens, the file never crosses the sandbox boundary. File is structured-cloneable, so marshaling target.files through the Remote DOM event bridge (or exposing a host API to read picked files) seems feasible.

Use case

A WhatsApp-conversation tab on a CRM record: users want to pick a file inside the chat and have it uploaded/attached/sent. Everything else works (uploads via MetadataApiClient/server-side work fine once bytes are available) — only the in-component file pick is impossible, forcing a detour through the native Files tab.

Ask

Marshal FileList/File objects through the sandbox for file inputs (change event and/or drag-drop dataTransfer.files), or provide a host command like pickFile() returning the bytes.

[sonarly]

🟠 Sonarly Analysis — High Severity

File contents are dropped across the front-component bridge

Front components can open the native file picker, but the sandbox bridge only forwards file metadata, not the selected file or its bytes. This blocks uploads that must read the selected file inside the component.

Root Cause

The proximate cause is a deliberate loss of file content at the host-to-worker serialization boundary.

The native input is rendered as a normal host <input> because file is not included in the text-like input types, so the picker itself can open. The host then handles the native change event through the existing allow-listed change bridge. However, serializeEvent extracts target.files with serializeFileList, which creates only:

{
  name,
  size,
  type,
  lastModified,
}

It does not forward the File object, arrayBuffer(), stream(), text(), or any file bytes. The remote event type is correspondingly limited to files?: SerializedFileData[], and the worker-side target shim assigns that metadata array to event.target.files before dispatching a synthetic CustomEvent [ref:origin-main-serialize-event] [ref:origin-main-serialized-event-type].

The original implementation commit explicitly describes this boundary: it added “file input metadata” and states that reading file contents was intentionally out of scope because it would require a separate host API bridge [ref:git-show-75c22a211979]. The commit also added the file-input Storybook coverage, which verifies metadata (name and type) rather than readable file contents [ref:origin-main-file-story]. Therefore, the component may receive a change event containing metadata, but it cannot obtain the File required for upload.

The triggering cause is the first content-dependent use of this interface: the application selected a local file and then attempted to read or upload it from the worker. The deployed bridge contract supports picker configuration and metadata inspection, but not content access. This is not a traffic spike, tenant data condition, rate limit, or server-side upload failure. The exact first occurrence and whether the reported “no change event” symptom is caused by a stale or mismatched deployed bundle are unknown because no runtime telemetry or browser trace is available. Repository history shows no subsequent commit adding file contents between the metadata feature and the reported 2.27.0 environment [ref:git-log-file-bridge].

Blame commit: 75c22a21 by charlesBochet — feat(front-component-renderer): forward file input metadata (#20458)

Suggested Fix

Changed file-input event serialization to forward the actual selected File objects instead of metadata-only copies. This preserves the existing name, size, type, and lastModified behavior while allowing front components to call File APIs such as text() or arrayBuffer() after selection. Added Storybook coverage that reads and renders the selected file contents from the worker-side event detail.

---

Analyzed by Sonarly · View full analysis