Finding a file-selection button does not authorize sending any local file. The earlier chapter covered selected-file lifetime. Here I trace how a webpage capability meets the host file grant, including whether the chooser opened behind a button really belongs to the expected frame.
A web input and a host selection are different information
The public browser.upload call accepts a current reference and fileIds, not an arbitrary local path argument. The host resolves its registered handles and checks profile and current task grants. A webpage's file input or accept attribute does not create permission to use local material.
The earlier lifetime chapter covers change and revocation at that preceding boundary. Here the resolved paths are connected internally to the current input node. Rejecting paths from the external call and proving a real selection are different questions. Passing either one does not automatically complete the other stages of the transfer.
Read a direct file input differently from a button chooser
SetFiles validates the current reference. A direct file input is resolved before DOM.setFileInputFiles; a button that opens a picker first passes pickerTarget and waits for a chooser event. A photo or video label does not make every media-panel button a chooser.
Chooser events are bound to the expected session and frameId with an actual backend node. Another frame is an error. Multiple files in single-selection mode and directory selection are separately refused. The useful evidence is which native input received the files, not merely that a plausible-looking button was clicked.
Do not infer success from an uploader clearing its input
Some uploaders copy FileList and synchronously clear input.value. An empty list afterward can mean nothing was selected or that the page already copied the selection. That single observation cannot distinguish both cases.
The current route records trusted input/change selection for the specific input in an isolated world. It reads a remaining FileList or the retained native-selection names and sizes if the page cleared it. This is not an arbitrary page variable claiming success. It remains evidence of native selection, however, not proof of the bytes received by a server.
Pair pre-dispatch checks with temporary-observer cleanup
Both direct-input and chooser routes call onDispatch and check before file assignment. TaskFiles' callback rechecks handles and metadata at that boundary. Cancellation or document change after preparation is not ignored merely because the first check passed.
Finally removes timers, polling and debugger listeners, disables chooser interception and releases temporary selection listeners and remote objects. Old observation state must not become evidence for the next selection. Cleanup does not reverse every server-side effect. Pre-dispatch refusal and verification of an already-sent file remain separate responsibilities.
Counterexamples distinguish a panel from a real chooser
The original chooser fixture separates photo/video-add controls that open an actual chooser from a button that only opens a video panel. Allowed routes separately inspect the local receiver's file result; the panel-only button must fail as a non-chooser control. Selection and server receipt are not collapsed into one verified claim.
I reviewed source and the selected test design without opening a new native chooser or operational upload. The linked file-receipt package compares synthetic bytes, granted handles and selection metadata, and operates no chooser. It shares the principle that visible webpage capability and host-authorized material need distinct checks before they meet. A future adaptation should retain the distinction in its errors: a revoked handle, an unrelated frame and a panel without a chooser require different fixes. Repeating the same click with a broader local path is not a valid substitute for any of them.