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
<https://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>.
