Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[MCP]: Add optional atomic upload action for file chooser triggers

Aperta
  • Qualcosa non va?
#43,546 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
playwright, typescript
Ambito
testing-qa, tooling

Direzione di ricerca

Start with packages/playwright-core/src/tools/backend/files.ts and tool.ts, then read tests/mcp/files.spec.ts to understand upload handling, modal guards, and the two-step flow. The proposal requires coordinating chooser timing, existing target and file validation, failure cleanup, and tests. Done means an optional atomic upload action works with deterministic errors and preserves the existing APIs and access restrictions.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What's going on?
Feature request: optional one-call file picker upload

The current Playwright MCP workflow for an element that opens a native file chooser is intentionally two-step:

  1. browser_click({ element: "Choose file", target: "e2" })
  2. browser_file_upload({ paths: ["/workspace/example.txt"] })

While the chooser is pending, the MCP backend correctly restricts other tab tools. This is not a report of a broken modal guard. I'd like to propose an optional atomic action that performs both steps within one tool invocation, without changing existing APIs.

Reproduction / motivation

Tested on @playwright/[email protected] (current published npm version on 2026-10-20), Node.js 22 and Chrome in an isolated headless browser. The page was served locally and contained only a button that clicks a hidden <input type="file">, a harmless second button, and a status text node.

  • browser_navigate and browser_snapshot: succeed.
  • browser_click on the upload trigger: succeeds; response reports [File chooser] modal state.
  • browser_snapshot while that chooser is pending: returns Tool "browser_snapshot" does not handle the modal state. (7 ms).
  • Clicking the unrelated button: similarly blocked (14 ms).
  • browser_file_upload({}): clears the modal state; the next snapshot succeeds.
  • Reopen chooser, call browser_file_upload({ paths: [file] }): file selected and the next snapshot succeeds.

This confirms expected current behavior, not a reproduced upstream hang. The remaining gap is orchestration: when an agent's upload steps are interrupted, retried, or interleaved with another tool call, it can be left in a chooser-only state requiring separate recovery. This is particularly awkward for long-running agent workflows and extension-connected tabs.

Proposal

Consider an opt-in browser_upload_files tool (name/API flexible), roughly:

{ "element": "Choose file button", "target": "e2", "paths": ["/workspace/example.txt"] }

Expected behavior:

  • Validate target using the existing browser target resolution and validate paths using the existing workspace/file-access restrictions.
  • Click the target and wait for the newly opened file chooser within a bounded timeout.
  • Set files using the existing upload implementation and return the resulting snapshot/status.
  • If no chooser opens, fail with a clear error; do not consume an unrelated previously pending chooser. Define safe, deterministic cleanup/retry semantics for failure.
  • Preserve browser_click and browser_file_upload unchanged for backwards compatibility. No relaxation of browser permissions or file access.

The existing defineTabTool modal guard and tests already cover the two-step flow; this proposal would add an optional higher-level operation, not remove the guard. See packages/playwright-core/src/tools/backend/{files.ts,tool.ts} and tests/mcp/files.spec.ts.

Could maintainers advise whether this belongs upstream? I can contribute a focused implementation and tests if this issue is approved/assigned, per the contributing guidelines. No production website or private user data was used for the reproduction.

Version

@playwright/mcp 0.0.83 (npm); upstream main 27219bd2cc94e1ebceec58f188760a6bf458c192

Lingua principale
TypeScript
Stelle
98k
Fork
6.6k
Merge medio
17h 15m
PR unite (30g)
321

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/playwright

Tutte le issue di microsoft/playwright

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.