Repository navigation
Screen capture #47
Description
This GitHub issue is for collecting web developer signals for Screen capture.
The navigator.mediaDevices.getDisplayMedia() method asks the user to choose a screen or portion of a screen (such as a window) to capture as a media stream.
Browser support
- Chrome 72 (Jan 29, 2019)
- Chrome Android: not supported
- Edge 79 (Jan 15, 2020)
- Firefox 33 (Oct 14, 2014)
- Firefox for Android: not supported
- Safari 13 (Sep 19, 2019)
- Safari on iOS: not supported
Give us feedback
If you're pressed for time, but you want this feature to be available in all browsers, please give this issue a thumbs up 👍 reaction.
However, a much better guide for us is to know how you'd use this feature, and what you're having to do in the meantime. This helps us judge the priority versus other features.
Copy the template below in a comment, and add the details that matter to you.
## What I want to do with this feature
<!-- Add your specific use-cases, even if they seem obvious to you. -->
## What I'm having to do in the meantime
<!--
Are you having to use another feature instead, a polyfill, or is it blocking you completely?
Why are the alternatives worse than using this feature?
-->All comments are expected to adhere to the Code of Conduct.
Learn more
You can learn more about this feature here:
Activity
Valtora commentedon Jun 19, 2026
What I want to do with this feature
I want Firefox to natively support shared tab/window/system audio capture through
getDisplayMedia()so a web app can record meeting audio together with microphone input without requiring Chrome.My use case is browser-based meeting capture and transcription. In my app, the browser records:
That lets users capture both sides of a meeting directly from a web app, without installing a native helper or joining meetings with a bot.
This is important because I want to use Firefox as my primary browser and still have access to the same browser-native capture workflow that currently only works reliably in Chromium-based browsers.
What I'm having to do in the meantime
Right now I have to tell users to switch to Chrome or another Chromium-based browser if they want this workflow.
That is worse because:
The alternatives are also poor:
ianwill93 commentedon Oct 12, 2026
What I want to do with this feature
On Android XR devices, inside of our webxr call application, there is no way to capture a portion of your screen to share with users. This is particularly an issue on Galaxy XR (Android XR).
It would be great if the user demonstrating something in the session were able to just share an open window (or their entire view) using the browser alone.
What I'm having to do in the meantime
This largely a complete blocker. If the user has a pc, they can log into the platform with a pc and share using the display attached to that device, but that means having two devices running just to temporarily share a screen.
hhkcvvbb-spec commentedon Oct 12, 2026
gsavchenko commentedon Oct 14, 2026
What I want to do with this feature
Users of our web app want to export a data table as a presentation-ready image they can drop into a slide or an email. Basically a screenshot of the table.
getDisplayMedia()is the one browser-native route I can see. You grab a frame from the stream, draw it to a canvas and save it. The browser captures the real rendered page, so fonts, badges and colours come out as users see them. As far as I can tell,preferCurrentTab(the option that offers "This Tab" up front) is only in Chromium browsers right now, so I'd like to see it work in Firefox and Safari too.What I'm having to do in the meantime
DOM-to-image libraries like html2canvas are the usual fallback. Its README says it
and its docs list CSS it doesn't support (box-shadow, filter, object-fit and more). Fonts, badges, sticky columns and tables wider than the viewport are the places I'd expect it to drift from what's on screen. It's also an extra dependency for a single menu item.
Rendering server-side with a headless browser is the other option, but that's a lot of infrastructure to photograph something the user is already looking at.
Screen capture would be simpler than either, but the user has to go through the share picker and grant permission every time, it only captures what's visible, and it's Chromium only for now. A cross-browser way to capture the current page, or one element of it, without the picker would make this much easier.