[Bug] 2.1.0 手势控制/摄像头交互被权限门禁拦截:NotAllowedError Permission denied(附根因与本地补丁)

[Bug] 2.1.0 手势控制 / 摄像头交互被应用自身权限门禁拦截:NotAllowedError: Permission denied(附根因分析与本地补丁)

版本:Mineradio 2.1.0 · Windows 11(26200)· 官方安装包(未改源码时复现)

现象

开启「手势控制」或 FX 面板「摄像头交互」后弹出:

Failed to acquire camera feed: NotAllowedError: Permission denied

应用内提示「手势启动失败 (需要摄像头权限)」。

与 #39 / #61 / #11 的关系

那几条记录的旧版症状是「摄像头能开但选到手机摄像头」;本条是 2.1.0 起完全无法获取任何摄像头的回归,根因不同,已定位到具体代码。

已排查排除

• Windows「隐私与安全 → 相机」全局与桌面应用均为 Allow,非系统拦截;
• Windows 相机隐私面板从未出现 Mineradio 的请求记录——因为 Chromium 权限层直接拒绝,根本没走到系统层(易误导排查方向)。

根因

desktop/main.js 的 configureLocalAppPermissions():

// setPermissionCheckHandler 与 setPermissionRequestHandler 中
if (permission === 'media') return isTrustedWallpaperEnginePreparationMediaPermission(webContents, origin, details);

而该函数(~853 行)要求存在有效的 Wallpaper Engine 画面捕获 grant(getWallpaperEngineCaptureGrant() 有效且 wallpaperEngineCapturePreparationOperation === grant.operation),即只在「选取窗口/桌面作为壁纸画面」的准备流程内放行。

手势控制(public/js/modules/10-shell/00-gesture-control.js 的 startGestureControl())与摄像头交互走 MediaPipe Camera(jsdelivr 的 @mediapipe/camera_utils),在本地页面 http://127.0.0.1:3000 主窗口直接 getUserMedia({ video })——此时没有任何 WE grant,被门禁拒绝。

疑似 2.1.0 收紧 WE 场景/桌面采集的权限边界时,把门禁范围扩大到了 media 整体,误伤了本地页面自己的摄像头请求。

复现

1. 打开 Mineradio 2.1.0
2. 启动「手势控制」或 FX「摄像头交互」
3. 出现上述 Permission denied 对话框

期望

本地页面(主窗口、本地 origin、仅 video)的摄像头请求应放行;麦克风、远程网页、子框架维持现有拒绝策略。

建议修复(已在本地验证可用)

在 media 分支追加一个「本地应用纯视频请求」放行:

if (permission === 'media') {
  return isTrustedWallpaperEnginePreparationMediaPermission(webContents, origin, details)
      || isLocalAppCameraRequest(webContents, origin, details);
}

isLocalAppCameraRequest 条件:webContents === mainWindow.webContents、isLocalAppUrl(origin)、isMainFrame、且 mediaType / mediaTypes 仅含 video 不含 audio(实现可与 isTrustedWallpaperEngineDisplayCapturePermission 同构,去掉 grant 要求)。

说明

本地已对 resources/app/desktop/main.js 应用上述补丁,手势控制与摄像头交互恢复正常;因客户端整包更新会覆盖改动,希望上游修复能进下一版。需要的话我可以提 PR。