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.
