Where
Layout-first start (preview/layout-first.html + layout-first.js), the P0 placement surface (#1131, #1026).
Problem
To put a video into a layout slot the creator has two options: drag-and-drop a file, or use the small native file input rendered low in each slot ("Choose host video"). The slot itself — the large, obvious target in the layout — is not clickable. So a creator who isn't drag-dropping has to find and hit the small file control inside each slot.
#1131 prioritizes PRs that let users place actual video sources into visible layout slots from the preview. Clicking the slot is the most natural way to do that and is currently unsupported.
Expected
Clicking anywhere in an empty, visible slot opens that slot's file picker — the same picker the file input opens — so the whole slot is a placement target. Filled slots keep their video and Remove control; drag-and-drop and the file input keep working; keyboard users keep using the focusable file input as today.
Proposed fix
Add a click handler on each .drop-zone that opens the slot's file input when the slot is empty and visible (ignoring clicks on the input itself so it doesn't double-open, and leaving filled slots alone), plus a pointer cursor on empty slots. No change to placement validation, preservation, the duplicate/empty guards, or the Continue gate.
Where
Layout-first start (
preview/layout-first.html+layout-first.js), the P0 placement surface (#1131, #1026).Problem
To put a video into a layout slot the creator has two options: drag-and-drop a file, or use the small native file input rendered low in each slot ("Choose host video"). The slot itself — the large, obvious target in the layout — is not clickable. So a creator who isn't drag-dropping has to find and hit the small file control inside each slot.
#1131 prioritizes PRs that let users place actual video sources into visible layout slots from the preview. Clicking the slot is the most natural way to do that and is currently unsupported.
Expected
Clicking anywhere in an empty, visible slot opens that slot's file picker — the same picker the file input opens — so the whole slot is a placement target. Filled slots keep their video and Remove control; drag-and-drop and the file input keep working; keyboard users keep using the focusable file input as today.
Proposed fix
Add a click handler on each
.drop-zonethat opens the slot's file input when the slot is empty and visible (ignoring clicks on the input itself so it doesn't double-open, and leaving filled slots alone), plus a pointer cursor on empty slots. No change to placement validation, preservation, the duplicate/empty guards, or the Continue gate.