feat: add POST /tabs/:tabId/set_input_files endpoint

[MrReasonable]

Why

AI agents using camofox-browser often need to apply for jobs or submit documents on behalf of users. Many job sites and portals use <input type="file"> elements for CV/resume uploads — but browsers intentionally block JavaScript from setting file inputs, so a standard type or click action cannot attach a file. This endpoint fills that gap by exposing Playwright's privileged setInputFiles channel via the REST API.

What

Adds POST /tabs/:tabId/set_input_files to programmatically attach files to <input type="file"> elements.

• Accepts either a snapshot ref (preferred, with automatic stale-ref refresh) or a CSS selector to target the file input
• File paths are sandboxed to a configurable uploads directory (CAMOFOX_UPLOADS_DIR, default /home/node/cv-uploads) to prevent the endpoint being used to read arbitrary files from the container
• Emits a tab:set_input_files plugin event consistent with the rest of the interaction surface
• Full OpenAPI/Swagger documentation included

Test plan

• Attaches file via CSS selector — filename appears in snapshot
• Attaches file via element ref — filename appears in snapshot
• Rejects paths outside the uploads directory with 400
• Rejects request with neither ref nor selector with 400
• Returns 404 for unknown tab ID
• Full e2e test suite passes (npm run test:e2e)

🤖 Generated with Claude Code

[SSOURABH58]

Thanks for putting this together! I've been testing file uploads and found some edge cases that we should consider handling here to make this endpoint more robust.

The Issue:
Currently, the PR relies solely on locator.setInputFiles() / page.setInputFiles(). This approach works for simple file inputs but has limitations:

1. It can fail/500 if the <input type="file"> element is hidden.
2. It silently fails on custom dropzones (e.g., react-dropzone). On these custom widgets, the site typically reads the file from the trusted file-chooser event payload rather than directly from the hidden input element. setInputFiles directly on the input bypasses this payload.

Proposed Improvement:
To support both plain inputs and custom dropzone widgets, we can update the set_input_files implementation in server.js (around the withTabLock block) to use a two-path approach.

We can enable file chooser interception and attempt to click the element to trigger the chooser event, falling back to direct setInputFiles if that fails.

Here is a conceptual example of how we can update the logic:

// Inside withTabLock, before interacting:
await tabState.page.setFileChooserInterceptedBy(true);

const fileChooserPromise = tabState.page.waitForEvent('filechooser', { timeout: 3000 }).catch(() => null);

// Try clicking the visible dropzone wrapper or the input itself (not the hidden input if possible)
// (We could potentially auto-detect the nearest clickable ancestor or accept a dropzone selector)
await locator.click({ force: true }).catch(() => {});

const fileChooser = await fileChooserPromise;

if (fileChooser) {
  // Intercept the filechooser and set the files via the chooser element.
  // Since the server FileChooser might lack .accept(), use element().setInputFiles
  await fileChooser.element().setInputFiles(resolved, { timeout: 10000 });
} else {
  // Fallback: Direct target.setInputFiles for plain inputs if no chooser was triggered
  await locator.setInputFiles(resolved, { timeout: 10000 });
}

This ensures we intercept the trusted chooser event for modern upload widgets while preserving the direct fallback (Plan A) for simpler inputs.

(Also referencing #3115 as this relates to similar input interaction logic.) Let me know what you think!

[MrReasonable]

Thanks @SSOURABH58 — this is a genuinely good catch. You're right that direct setInputFiles on the hidden input silently no-ops for widgets (react-dropzone et al.) that read from the trusted file-chooser event, and that's worth handling.

I've pushed a change that adds this as an opt-in second path rather than replacing the default (68ba18a):

• Direct input stays the default. ref / selector still set files straight on the <input type="file"> via setInputFiles — deterministic, works on hidden inputs (Playwright bypasses the visibility actionability check for file inputs), and adds no latency for the common case.
• New dropzoneRef / dropzoneSelector target the visible dropzone element. When supplied, the server registers a filechooser waiter, clicks that element, and feeds the chooser via fileChooser.setFiles(...).

A couple of implementation notes vs. the sketch:

• I went with Playwright's implicit chooser interception — attach a page.waitForEvent('filechooser') listener before the click and it intercepts automatically; there isn't a page.setFileChooserInterceptedBy(...) on the API surface, and fileChooser.setFiles() takes the paths directly.
• Rather than auto-detecting the clickable ancestor (which is guesswork and can force-click the wrong element / trigger navigation), the caller names the dropzone explicitly. Force-click is used only as a fallback for a blocked/timed-out click, so strict-mode violations and detached nodes still surface honestly.
• Security: the file-chooser path feeds the same CAMOFOX_UPLOADS_DIR-sandboxed paths as the direct path (now checked on the realpath, so an in-dir symlink can't escape the allowlist), and it returns a clear 400 if the click opens no chooser, pointing plain-<input> callers back to ref/selector.

Tests cover both dropzone paths (selector + ref) against a react-dropzone-style page, sandbox enforcement on the new path, and the no-chooser case.

One thing on the #3115 reference: it already prototypes this file-chooser approach with the correct APIs (waitForEvent('filechooser') + chooser.setFiles()) — worth a look — but its /upload endpoint overlaps this one and doesn't sandbox the file paths, so I'd be wary of landing them in a way that reintroduces arbitrary-file access. Happy to reconcile if a maintainer wants a single endpoint.

[skyfallsin]

Thanks for the upload work.

This PR’s user-facing need is now covered by the production upload endpoint:

POST /tabs/:tabId/upload

It supports upload-root containment, symlink-safe path checks, direct file inputs, ref/selector triggers, native filechooser fallback, and post-upload ref refresh.

The branch is now conflicting and contains many unrelated server, Docker, auth, and infrastructure changes. Maintaining a second upload route would duplicate the current API and increase drift risk.

I am closing this PR as superseded. If there is a specific upload case that /upload does not handle, please open a small focused issue or PR against the current implementation.