* > Gecko: Under consideration (https://github.com/mozilla/standards-positions/issues/1245 <https://github.com/mozilla/standards-positions/issues/1245>)* This signals thread is for an earlier version of PEPC, and there was a request <https://github.com/mozilla/standards-positions/issues/1245#issuecomment-3198708478> in the thread to split out <usermedia> into a separate position thread once it's ready. Can you do that? It's not clear from the old thread that the current shape of the feature has been reviewed by Gecko.
* > WebKit: No signal* Can you request a WebKit position? Thanks, Dan On Tuesday, April 21, 2026 at 10:26:03 AM UTC-7 [email protected] wrote: > Sorry, LGTM2 % requesting the missing Testing bit in your chromestatus > entry. > On 4/21/26 10:24 a.m., Mike Taylor wrote: > > LGTM2 > On 4/21/26 6:52 a.m., Rick Byers wrote: > > Perfect, thanks for the answers and cleanups! LGTM1 to ship. > > On Mon, Apr 20, 2026 at 1:52 PM Thomas Nguyen <[email protected]> wrote: > >> Thank you for reviewing this. >> >>> Note that web-exposed features typically live under the 'Blink' >>> component, and they get some extra love (like an extra expert triage >>> rotation <https://www.chromium.org/blink/blink-triaging/>) to help >>> ensure web devs are getting fast and helpful responses and that important >>> externally-reported regressions don't get missed. Bugs under 'Internals' >>> are normally assumed to not contain important externally-reported issues. >>> As long as your team is on top of your bug triage (eg. would notice within >>> 1-2 days if someone filed a bug there saying a change broke their website) >>> then it's not a big deal, may not be worth the hassle of moving. >>> Regardless, does not need to block this intent IMHO. >> >> Thanks for the input. Component UI>Browser>Permissions>, or >> UI>Browser>Permissions>Prompts makes more sense, aligning the experience >> with the existing behavior of the <geolocation> element >> >> Since this is a distinct feature we'd want to track usage of >>> independently, it should have a distinct feature ID. Please file an issue >>> here >>> <https://github.com/web-platform-dx/web-features/issues/new?template=new-feature.yml> >>> and >>> just tag it as missing for now. >> >> Filed an issue >> <https://github.com/web-platform-dx/web-features/issues/3972>, with *feature >> definition* tag (I could not find missing tag) >> >> There's also a more specific review request >>> <https://github.com/w3ctag/design-reviews/issues/1218> a couple weeks >>> ago. Probably its the one you should list in chromestatus for this feature >>> (and it links to the related prior ones anyway). No need to block this I2S, >>> but of course we expect that you'll engage with any feedback that comes >>> there in parallel. >> >> Regarding the TAG review, thanks for catching that, I accidentally >> provided the old link. >> >> It looks like you have just a 50% pass rate (8/16) on the dashboard right >>> now. Has someone done a triage pass over these failures? Perhaps some of >>> these tests are passing in Chrome infra but failing on wpt.fyi? >>> Getting all the tests passing doesn't need to block I2S, but we want to >>> make sure we understand the current and likely future state of the tests >>> since it's a proxy for maturity and spec conformance, and is really >>> valuable for any other implementations to follow. >> >> As for the WPT results, you are exactly right. Those tests pass in Chrome >> infra but are failing on wpt.fyi (error: secure context required). I have a >> CL in progress to rename the tests to .https.html, it will likely take 1–2 >> days for the changes to sync and for the dashboard to reflect the updated >> results. >> >> On Mon, Apr 20, 2026 at 1:56 AM Rick Byers <[email protected]> wrote: >> >>> I'm excited to see this ship! I see this as another important use of the >>> PEPC technology to better enable the browser to be an effective >>> intermediary between the site and the user. Just a few nits and questions: >>> >>> On Wed, Apr 15, 2026, 10:32 a.m. Chromestatus < >>> [email protected]> wrote: >>> >>>> *Contact emails* >>>> [email protected], [email protected] >>>> >>>> *Explainer* >>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md >>>> >>>> *Specification* >>>> https://wicg.github.io/PEPC/permission-elements.html >>>> >>>> *Summary* >>>> Usermedia Capability Element, is a declarative, user-activated control >>>> for accessing the starting and interacting with media streams. This >>>> addresses the long-standing problem of permission prompts being triggered >>>> directly from JavaScript without a strong signal of user intent. By >>>> embedding a browser-controlled element in the page, the user's click >>>> provides a clear, intentional signal. This enables a much better prompt UX >>>> and, crucially, provides a simple recovery path for users who have >>>> previously denied the permission. Note: This feature was previously >>>> developed and tested in an Origin Trial as the more generic <permission> >>>> element. Based on feedback from developers and other browser vendors, it >>>> has evolved into capability-specific elements to provide a more tailored >>>> and powerful developer experience. >>>> >>>> *Blink component* >>>> Public Trackers > Chromium Public Trackers > Chromium > Internals > >>>> Permissions > PermissionElement >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Public%20Trackers%20%3E%20Chromium%20Public%20Trackers%20%3E%20Chromium%20%3E%20Internals%20%3E%20Permissions%20%3E%20PermissionElement%22> >>> >>> >>> Note that web-exposed features typically live under the 'Blink' >>> component, and they get some extra love (like an extra expert triage >>> rotation <https://www.chromium.org/blink/blink-triaging/>) to help >>> ensure web devs are getting fast and helpful responses and that important >>> externally-reported regressions don't get missed. Bugs under 'Internals' >>> are normally assumed to not contain important externally-reported issues. >>> As long as your team is on top of your bug triage (eg. would notice within >>> 1-2 days if someone filed a bug there saying a change broke their website) >>> then it's not a big deal, may not be worth the hassle of moving. >>> Regardless, does not need to block this intent IMHO. >>> >>> *Web Feature ID* >>>> permissions <https://webstatus.dev/features/permissions> >>> >>> >>> Since this is a distinct feature we'd want to track usage of >>> independently, it should have a distinct feature ID. Please file an issue >>> here >>> <https://github.com/web-platform-dx/web-features/issues/new?template=new-feature.yml> >>> and >>> just tag it as missing for now. >>> >>> *Motivation* >>>> The current web permission model for interacting with user media relies >>>> on JavaScript-triggered prompts, giving the user agent no strong signal of >>>> user intent. This results in out-of-context prompts, user frustration, and >>>> difficult-to-recover-from denial states. We propose the <usermedia> >>>> element, or a suite of elements. This will be semantic HTML control with >>>> browser-controlled content and strict styling constraints. These >>>> constraints are fundamental to the security model, ensuring a very high >>>> level of confidence in the user's intent when making a permission decision >>>> at both the site and OS level. Crucially, the <usermedia> element evolves >>>> beyond simply managing permissions; it streamlines the entire journey by >>>> also facilitating starting and interacting with media streams. This often >>>> eliminates the need for separate JavaScript API calls, simplifying >>>> implementation and creating a more seamless user flow. By providing a >>>> clear, consistent, in-page control, this element solves significant user >>>> problems related to context blindness and "permission regret," offering a >>>> simple recovery path from a previously denied state. The combination of a >>>> user-initiated element and a subsequent browser-controlled confirmation UI >>>> enhances intent capture, improves accessibility, and prevents manipulative >>>> patterns, providing a significantly better experience for both users and >>>> developers. >>>> >>>> *Initial public proposal* >>>> https://github.com/WICG/PEPC/issues/62 >>>> >>>> *TAG review* >>>> https://github.com/w3ctag/design-reviews/issues/1079 >>> >>> >>> There's also a more specific review request >>> <https://github.com/w3ctag/design-reviews/issues/1218> a couple weeks >>> ago. Probably its the one you should list in chromestatus for this feature >>> (and it links to the related prior ones anyway). No need to block this I2S, >>> but of course we expect that you'll engage with any feedback that comes >>> there in parallel. >>> >>> *TAG review status* >>>> Issues addressed >>>> >>>> *Origin Trial Name* >>>> UserMediaElement >>>> >>>> *Goals for experimentation* >>>> This Origin Trial serves two primary purposes: ensuring continuity for >>>> existing partners who have successfully integrated this pattern, and >>>> providing a platform to validate and iterate on the new, >>>> capability-specific <usermedia> element. While our previous Origin Trial >>>> for <permission> provided strong evidence for the core user-initiated >>>> model, feedback from developers and browser vendors prompted us to evolve >>>> the design. This new trial is essential for gathering insights on a >>>> refined, data-centric API shape to help us reach cross-browser consensus. >>>> To ensure a seamless transition and prevent disruption for our valued OT >>>> partners, this trial will initially launch with an API shape that is >>>> functionally equivalent to the previous <permission> trial, simply using >>>> the new <usermedia> element name. This provides a stable foundation from >>>> which we will iterate based on further discussion. Our goal is to evolve >>>> this element towards our proposed data-centric design ( >>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md). However, >>>> we recognize that this more advanced API has raised compatibility and >>>> complexity concerns with developers ( >>>> https://github.com/WICG/PEPC/issues/62). Therefore, a primary >>>> objective of this trial is to work closely with the community to address >>>> these concerns and refine the final API. TPAC WebRTC minutes >>>> https://www.w3.org/2025/11/11-webrtc-minutes.html#551 >>>> >>>> *Chromium Trial Name* >>>> UserMediaElement >>>> >>>> *Origin Trial documentation link* >>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md >>>> >>>> *WebFeature UseCounter name* >>>> kHTMLPermissionElement >>>> >>>> *Risks* >>>> >>>> >>>> *Interoperability and Compatibility* >>>> There is a risk that this feature fails to be adopted by other >>>> browsers. This can be mitigated by backwards designing a reasonable >>>> fallback mechanism so that the element can degrade gracefully if the it's >>>> in an unsupported environment. >>>> >>>> *Gecko*: Under consideration ( >>>> https://github.com/mozilla/standards-positions/issues/1245) >>>> >>>> *WebKit*: No signal >>>> >>>> *Web developers*: Positive >>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393820279 >>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393861768 >>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393911331 >>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2619657041 >>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3482975001 >>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3482981942 >>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3498355775 >>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3513734884 >>>> >>>> *Other signals*: >>>> >>>> *Ergonomics* >>>> No foreseen ergonomics risks. >>>> >>>> *Activation* >>>> A polyfill can help developers use this feature without risking broken >>>> functionality on non-supporting browsers. >>>> >>>> *Security* >>>> https://github.com/WICG/PEPC/blob/main/explainer.md#Security >>>> >>>> *WebView application risks* >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> Feature is not shipping on WebView due to it requiring permission >>>> manager embedder support. >>>> >>>> >>>> *Debuggability* >>>> The element raises issues to the devtools issues panel which help >>>> developers debug issues with their usage of the element. >>>> >>>> *Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>> No >>>> The element is not supported on Android WebView as it requires >>>> permission manager support to function and the WebView permission manager >>>> defers most permission decisions to the embedder by design. >>>> >>>> *Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>> Yes >>>> https://wpt.fyi/results/html/semantics/permission-element/usermedia >>> >>> >>> It looks like you have just a 50% pass rate (8/16) on the dashboard >>> right now. Has someone done a triage pass over these failures? Perhaps some >>> of these tests are passing in Chrome infra but failing on wpt.fyi? >>> >>> Getting all the tests passing doesn't need to block I2S, but we want to >>> make sure we understand the current and likely future state of the tests >>> since it's a proxy for maturity and spec conformance, and is really >>> valuable for any other implementations to follow. >>> >>> *DevTrial instructions* >>>> https://github.com/WICG/PEPC/blob/main/HOWTO.md#enabling-usermedia >>>> >>>> *Flag name on about://flags* >>>> *No information provided* >>>> >>>> *Finch feature name* >>>> UserMediaElement >>>> >>>> *Rollout plan* >>>> Will ship enabled for all users >>>> >>>> *Requires code in //chrome?* >>>> True >>>> >>>> *Tracking bug* >>>> https://crbug.com/443013457 >>>> >>>> *Availability expectation* >>>> Feature is available only in Chromium browsers. We are not aware of >>>> other browsers adoption. >>>> >>>> *Adoption expectation* >>>> Feature is used by specific partner(s) to provide functionality within >>>> 12 months of launch in Chrome. Partners who are tested the feature in OT >>>> are expected to continue usage. >>>> >>>> *Adoption plan* >>>> We are planning to publish on developer.chrome.com and do further >>>> partner outreach >>>> >>>> *Non-OSS dependencies* >>>> >>>> Does the feature depend on any code or APIs outside the Chromium open >>>> source repository and its open-source dependencies to function? >>>> No >>>> >>>> *Estimated milestones* >>>> Shipping on desktop 149 >>>> Origin trial desktop first 144 >>>> Origin trial desktop last 148 >>>> DevTrial on desktop 144 >>>> Shipping on Android 149 >>>> Origin trial Android first 144 >>>> Origin trial Android last 148 >>>> DevTrial on Android 144 >>>> >>>> *Anticipated spec changes* >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>> of >>>> the API in a non-backward-compatible way). >>>> This is an MVP launch. The MVP feature is fully functional and used by >>>> developers right now. We are working closely with the WebRTC on post-MVP >>>> features, the open topics will based on the foundation of the MVP, that we >>>> agreed upon with the WebRTC. Some of the open topics are for example: In >>>> the future, we might want to add a parameter to the getUserMedia algorithm >>>> so that the algorithm can determine whether the getUserMedia is called >>>> from >>>> the <usermedia> element or getUserMedia API. Potential to add additional >>>> attributes for <usermedia> interface. We're putting finishing touches on >>>> the spec now, work-in-progress PR is here, but once that lands we want to >>>> ship for M149 so wanted to start the discussion now. >>>> >>>> *Link to entry on the Chrome Platform Status* >>>> https://chromestatus.com/feature/4926233538330624?gate=6467532078841856 >>>> >>>> *Links to previous Intent discussions* >>>> Intent to Prototype: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/692719de.050a0220.17ec37.00c3.GAE%40google.com >>>> Intent to Experiment: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6942ed09.050a0220.1050d6.0961.GAE%40google.com >>>> >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com>. >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69dfa184.050a0220.c8e20.03e8.GAE%40google.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69dfa184.050a0220.c8e20.03e8.GAE%40google.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >> >> -- >> >> Thomas Nguyen >> >> Software Engineer >> >> [email protected] >> >> Google Germany GmbH >> >> Erika-Mann-Straße 33 >> >> 80636 München >> >> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >> >> Registergericht und -nummer: Hamburg, HRB 86891 >> >> Sitz der Gesellschaft: Hamburg >> >> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten >> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, >> dass die E-Mail an die falsche Person gesendet wurde. >> >> >> >> This e-mail is confidential. If you received this communication by >> mistake, please don't forward it to anyone else, please erase all copies >> and attachments, and please let me know that it has gone to the wrong >> person. >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8VX9jdKZZ_tj%2BaMzZkHeVmE7N%2BFhfcywx4qa9235m6Yw%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8VX9jdKZZ_tj%2BaMzZkHeVmE7N%2BFhfcywx4qa9235m6Yw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/24252e41-4151-4b8d-b8d5-3b0183870dacn%40chromium.org.
