[Feature]: Controllable fake microphone input on all browsers

已关闭
  • 哪里不对？
#43,563 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
35/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
javascript, playwright, typescript
领域
backend-api-design, testing

调研方向

Read the linked requests #39297, #31158 and #27436, then inspect Playwright's browser permission and media device handling for Chromium, Firefox and WebKit. Reproduce the described getUserMedia behavior on each engine and compare it with the userland init-script example. Done means tests can control audio, playback timing and permission denial per page across all three browsers, or the issue's proposed documentation alternative is addressed.

由索引模型根据 Issue 内容生成。

描述

🚀 Feature Request

Let a test control what the page's microphone delivers, per test and per page, on Chromium, Firefox and WebKit: a tone, an audio file, start and stop at a moment the test picks, and a permission denial.

#39297 asked for this and was closed as not planned. Two narrower requests, #31158 (control when the fake audio file plays) and #27436 (a different audio file per test), were closed for low engagement with a note asking for a new issue that links them. This is that issue.

What the stock browsers do today, measured on Playwright 1.63.0, macOS:

Browser getUserMedia({ audio: true })
Chromium 153 Works with --use-fake-device-for-media-stream. The audio is fixed for the whole browser at launch, and a file starts playing when capture starts.
Firefox 155 grantPermissions(['microphone']) throws Unknown permission: microphone. With firefoxUserPrefs media.navigator.streams.fake and media.navigator.permission.disabled set to true, it resolves with a steady sine (1 kHz, or the pitch in media.navigator.audio.fake_frequency), fixed for the whole browser at launch.
WebKit 26.6, no grant Rejects with NotAllowedError.
WebKit 26.6, after grantPermissions(['microphone']) (new in 1.62 via #41836) Resolves with "Mock audio device 1", but the track is digital silence (rms 0 over 3 s through an AnalyserNode).
Example

I maintain a userland version: playwright-mock-microphone (MIT, no dependencies, about 130 lines). Its suite records the mock through MediaRecorder and checks the recorded pitch on all three engines.

import { test, expect } from '@playwright/test';
import { mockMicrophone } from 'playwright-mock-microphone';

test('transcribes what the user says', async ({ page }) => {
  const mic = await mockMicrophone(page);
  await page.goto('/record');
  await page.getByRole('button', { name: 'Record' }).click();
  await mic.play('fixtures/hello.wav');
  await mic.waitForEnd();
  await expect(page.getByRole('status')).toHaveText('hello');
});

test('shows help when the microphone is blocked', async ({ page }) => {
  const mic = await mockMicrophone(page);
  await page.goto('/record');
  await mic.deny('NotAllowedError');
  await page.getByRole('button', { name: 'Record' }).click();
  await expect(page.getByText('Allow microphone access')).toBeVisible();
});

It works by replacing getUserMedia and enumerateDevices from an init script and returning a Web Audio MediaStreamAudioDestinationNode stream. That approach has limits a built-in version would avoid: it bypasses the browser's permission layer, ignores constraints such as deviceId and echoCancellation, and leaves a global the page can see.

Motivation

Voice input is now common: speech to text, voice agents, voice memos, calls. Testing it means asserting on what the app does with known audio, so the test, not the launch config, has to choose the audio and when it plays. None of the three engines lets a test pick the audio at runtime. Chromium and Firefox fix it once per browser launch, and Firefox can only play a sine tone. WebKit, the engine iPad and Safari users run, delivers silence.

If you would rather keep this in userland, a docs note pointing to the init-script approach would still help the people who land on #2973 and #39297.

主要语言
TypeScript
星标
99.1k
派生
6.8k
平均合并
16 小时 20 分钟
30 天内合并 PR
324

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoft/playwright 的其他 Issue

查看 microsoft/playwright 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。