Hi Dan, thank you for the reminder, here are the standard positions requests
- https://github.com/WebKit/standards-positions/issues/651 - https://github.com/mozilla/standards-positions/issues/1392 Best, Minh On Wednesday, April 22, 2026 at 10:43:40 PM UTC+2 Thomas Nguyen wrote: > Sorry, LGTM2 % requesting the missing Testing bit in your chromestatus >> entry > > Thanks. I have flipped the Testing bit in ChromeStatus and added more WPT > coverage. > > > On Tue, Apr 21, 2026 at 7:25 PM Mike Taylor <[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> >> . >> >> > > -- > > 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/b73e814e-f945-4a3d-a9bc-dc01cf73a9c6n%40chromium.org.
