[MCP]: Add optional atomic upload action for file chooser triggers
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 38/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- playwright, typescript
- Lĩnh vực
- testing-qa, tooling
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- TypeScript
- Star
- 98k
- Fork
- 6.6k
- Merge trung bình
- 17 giờ 15 phút
- Pull request đã merge (30 ngày)
- 321
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của microsoft/playwright
-
[Feature]: Set `this.name` in `TargetClosedError` constructorCó thể làm lại được @LeonxLJX đã nhận 47 ngày trước và không có pull request nào đang mở. Đang mởP3-collecting-feedback
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 86/100
microsoft/playwright#42522 · 7 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
microsoft/playwright#43553 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 73/100
microsoft/playwright#43549 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[internal] remove PLAYWRIGHT_FIREFOX_LEGACY_DOWNLOADSCó thể đã có người làm @dgozman đã nhận hôm nay. Đang mởbrowser-firefox v1.65
microsoft/playwright#43547 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 1-2 ngày Mức phù hợp với người mới 52/100
microsoft/playwright#43545 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của microsoft/playwright
Issue tương tự
-
skillopt: success-reflect prompt omits the edit schema, so every success-only edit is droppedĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Workspace secrets/constants containing "$" are corrupted when resolved in data source optionsĐang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
mobile-next/mobile-mcp#526 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
e2e-failure ready-to-code
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 73/100
redhat-developer/rhdh-plugin-export-overlays#4470 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày