[MCP]: Add optional atomic upload action for file chooser triggers
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 38/100
- issue の種類
- 機能追加
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- playwright, typescript
- 領域
- testing-qa, tooling
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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:
browser_click({ element: "Choose file", target: "e2" })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_navigateandbrowser_snapshot: succeed.browser_clickon the upload trigger: succeeds; response reports[File chooser]modal state.browser_snapshotwhile that chooser is pending: returnsTool "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
targetusing the existing browser target resolution and validatepathsusing 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_clickandbrowser_file_uploadunchanged 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
- 主要言語
- TypeScript
- スター
- 98k
- フォーク
- 6.6k
- 平均マージ
- 16時間 1分
- マージ済み PR（30日）
- 309
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/playwright のほかの issue
-
[Feature]: Set `this.name` in `TargetClosedError` constructor再び着手できるかも @LeonxLJX が 47 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンP3-collecting-feedback
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
microsoft/playwright#42522 · コメント 7 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
microsoft/playwright#43564 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
microsoft/playwright#43563 ·
メンテナーはふだん 1 日以内に返信
-
[Bug]: `request.response()` never resolves for a service worker's own script when many contexts register service workers at once対応中かも @pavelfeldman が今日担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
microsoft/playwright#43562 ·
メンテナーはふだん 1 日以内に返信
-
[Bug]:オープン
難易度 3/5 1〜2日 初心者へのやさしさ 25/100
microsoft/playwright#43559 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
microsoft/playwright の issue をすべて見る
似ている issue
-
agent/scanner help wanted hive/claimed-by-scanner kind/bug stage/020-claimed
難易度 2/5 1〜3時間 初心者へのやさしさ 90/100
hivecommons/rationguard#315 ·
メンテナーはふだん 1 日以内に返信
-
agent-ready area: ui-sdk priority: p3 type: chore
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
schlessera/brain-kit#2534 ·
メンテナーはふだん 1 日以内に返信
-
bug lane:gh-5
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
LLM-4-People/bridlewise-testing#122 ·
メンテナーはふだん 1 日以内に返信
-
bug priority: P2
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
enhancement priority:low ready-for-dev
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
メンテナーはふだん 1 日以内に返信