22b164bab0deaa615bfbd39d0eade32cf0ef5035
1
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
5f3746ead8 |
fix(stage-tamagotchi): grant screen capture through the media permission (#2178)
## Description Screen capture in Stage Tamagotchi is denied before it ever reaches the desktop picker: `navigator.mediaDevices.getDisplayMedia()` resolves with `NotAllowedError: Permission denied`, so the vision screen-capture panel can list sources but never start a stream. The cause is in `shouldGrantElectronPermission`. Electron reports **screen capture as the `media` permission**, not as `display-capture`, and it only appends `audio`/`video` to `details.mediaTypes` for *device* capture — so a `getDisplayMedia()` request arrives as `media` with an **empty** `mediaTypes` list ([`web_contents_permission_helper.cc#L249-L274`](https://github.com/electron/electron/blob/v41.2.1/shell/browser/web_contents_permission_helper.cc#L249-L274)). The handler took an early return for every `media` operation and required audio-only details, so display capture was rejected before the allowlisted `display-capture` entry could be consulted: ```ts if (permission === 'media') return shouldGrantAudioCapturePermission(webContents, permission, requestingOrigin, details) return LOCAL_APP_PERMISSION_NAMES.has(permission) && shouldGrantLocalAppPermission(...) ``` The fix resolves a `media` operation that declares no device media type back to `display-capture`, so the existing allowlist and local-frame checks decide the outcome — which is what `LOCAL_APP_PERMISSION_NAMES` already intended: ```ts const allowlistPermission = isDisplayCaptureMediaPermission(permission, details) ? 'display-capture' : permission return LOCAL_APP_PERMISSION_NAMES.has(allowlistPermission) && shouldGrantLocalAppPermission(webContents, requestingOrigin, details) ``` Camera and microphone operations always report their device media type (`['video']`, `['audio']`, `mediaType: 'audio'`), so they never take this path and stay exactly as strict as before. Remote frames are still rejected, because the local-frame check is unchanged and still applies to display capture. Three regression tests are added: screen capture from a local page is granted, screen capture from a remote page is rejected, and a camera request is still denied now that it shares the `media` permission. ## Linked Issues Closes #2177 ## Additional Context - **Regression range.** This was introduced by #2002 (`5e8bf75`, 2026-07-10), which added the permission allowlist. Nothing on the failing path is platform-specific — the `media` vs `display-capture` mismatch is in Electron's browser process — so although the issue was reported on Windows, screen capture has been broken on macOS and Linux since that commit too. Worth noting for anyone triaging similar reports. - **Detection signal.** The predicate keys on `mediaTypes.length === 0` rather than on the absence of the field, so a `media` operation with *no* `mediaTypes` at all (e.g. permission *checks*, which send `mediaType: 'unknown'` instead) is not silently promoted to display capture. That keeps the change to exactly the shape Electron documents for `getDisplayMedia()` requests. - **Deliberately out of scope.** #2104 (camera snapshot denied) is a policy decision — whether the camera should join the allowlist — not this bug, and #2132 (`systemPreferences.getMediaAccessStatus` undefined on Linux) is unrelated. Happy to follow up on either if you'd like them addressed. - **Second layer still applies.** `setDisplayMediaRequestHandler` in `packages/electron-screen-capture` is only installed inside the `setSource` mutex window, so a grant here still requires the renderer to have selected a source first. This change does not widen that. - **Verification.** `media-permissions.test.ts` goes 16/16 → 19/19; with only the tests applied, the new local-screen-capture case fails as expected. Type checking and the repo ESLint config both pass clean on the two touched files. --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com> |