LGTM3

On Tuesday, April 28, 2026 at 11:23:38 AM UTC-7 [email protected] wrote:

> Please update the chromestatus entry to specify the new TAG review for 
>> <usermedia> rather than the old PEPC one, and link to the new webkit 
>> standards position.
>
> Done, thanks.
>
> Also, this I2S specifies "goals for experimentation" - why is that there? 
>> You're asking to fully ship, right?
>
> I think that's a left over we filled in in the OT request. Removed that.
>
> On Tue, Apr 28, 2026 at 5:55 PM Chris Harrelson <[email protected]> 
> wrote:
>
>> Please update the chromestatus entry to specify the new TAG review for 
>> <usermedia> rather than the old PEPC one, and link to the new webkit 
>> standards position.
>>
>> Also, this I2S specifies "goals for experimentation" - why is that there? 
>> You're asking to fully ship, right?
>>
>> On Mon, Apr 27, 2026 at 2:51 AM 'Thomas Nguyen' via blink-dev <
>> [email protected]> wrote:
>>
>>> That sounds like a solid idea. Thank you for the suggestion, Philipp; I 
>>> have noted it down.
>>> We will certainly add this to our roadmap and include the sample after 
>>> the API is merged into the media capture extensions. This will ensure 
>>> better alignment with the approved shape.
>>>
>>>
>>> On Sat, Apr 25, 2026 at 4:57 PM Philipp Hancke <
>>> [email protected]> wrote:
>>>
>>>> Looking forward to this shipping! Can you please also add a sample to
>>>>   https://github.com/webrtc/samples
>>>> which remains a go-to location for all things getUserMedia and WebRTC 
>>>> (maybe we can get it to 15k stars finally ;-))
>>>>
>>>> Am Mi., 15. Apr. 2026 um 16:39 Uhr schrieb Chromestatus <
>>>> [email protected]>:
>>>>
>>>>> *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>
>>>>>
>>>>> *Web Feature ID*
>>>>> permissions <https://webstatus.dev/features/permissions> 
>>>>>
>>>>> *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 
>>>>>
>>>>> *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
>>>>>
>>>>> *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/CA%2BoJCSxCm3w%3DJSaikf6HwAfYe%3DgwrOi7rR%2Bi3Uz2sybR_Uuhew%40mail.gmail.com
>>>  
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BoJCSxCm3w%3DJSaikf6HwAfYe%3DgwrOi7rR%2Bi3Uz2sybR_Uuhew%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/8889227c-eed8-4803-acad-4b6a4ea611ebn%40chromium.org.

Reply via email to