Thanks Thomas! Looks like the tests are all failing upstream on wpt.fyi <https://wpt.fyi/results/html/semantics/permission-element?label=master&label=experimental&aligned>, presumably because the feature is only status=test, not status=experimental. Is there a reason the feature wasn't flipped to status=experimental? To what extent do you expect the tests to pass upstream on wpt.fyi once you flip to status=stable?
Also can you now please remove the 'tentative' from your test filenames? Since there is a specification for them, the 'tentative' label <https://web-platform-tests.org/writing-tests/file-names.html> is no longer accurate. Thanks! Rick On Mon, Aug 10, 2026 at 3:52 PM Philipp Hancke < [email protected]> wrote: > https://webrtchacks.github.io/chromestatus/?buckets=1401,1402 > -- 0.25% of pageloads ;-) > > Am Mo., 10. Aug. 2026 um 21:06 Uhr schrieb Alex Russell < > [email protected]>: > >> Thanks for filing those. >> >> I'm excited that we're adding HTML elements for common behaviours. Along >> those lines, do we have an analysis of how common camera and mic requests >> are today? I.e., can we make the case that this is so common that it >> deserves an HTML element? >> >> Best, >> >> Alex >> >> On Friday, August 7, 2026 at 4:22:43 AM UTC-7 [email protected] wrote: >> >>> Thanks for taking a look. >>> I have filled in the missing bits (regarding wpt, linking the tests and >>> platforms supported). Please let me know if you still have any concerns. >>> >>> On Wednesday, July 29, 2026 at 5:06:59 PM UTC+2 [email protected] >>> wrote: >>> >>>> Was just looking at this and had the same questions Yoav. Here's what >>>> I've found so far: >>>> >>>> On Wed, Jul 29, 2026 at 10:22 AM Yoav Weiss (@Shopify) < >>>> [email protected]> wrote: >>>> >>> On Wednesday, July 22, 2026 at 11:47:33 PM UTC+2 Chromestatus wrote: >>>>> >>>> *Contact emails* >>>>> [email protected], [email protected] >>>>> >>>>> >>>>> >>>>> *Explainer* >>>>> https://github.com/w3c/mediacapture-extensions/blob/ >>>>> main/media-capture-elements-explainer.md >>>>> >>>>> *Specification* >>>>> https://w3c.github.io/mediacapture-extensions/#the-camera-html-element >>>>> >>>>> *Summary* >>>>> The <camera> and <microphone> capability elements are declarative, >>>>> user-activated HTML controls that share the same underlying mechanism as >>>>> the <usermedia> MVP element, with one key distinction: they are designed >>>>> to >>>>> request a single capability. The <camera> element specifically requests >>>>> video capture, while the <microphone> element specifically requests audio >>>>> capture. Like the <usermedia> MVP, they embed a browser-controlled, >>>>> strictly styled UI into the page, ensuring a strong, intentional user >>>>> signal (a click) before a permission prompt is triggered or a stream is >>>>> started. The <camera> and <microphone> elements provide a dedicated, >>>>> semantic HTML control for these single-capability use cases. They maintain >>>>> the identical security model, strict styling constraints, and built-in >>>>> permission recovery path as the <usermedia> MVP, but offer a more tailored >>>>> and ergonomic API for developers who do not need mixed media access. >>>>> >>>>> *Blink component* >>>>> UI>Browser>Permissions>Prompts >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22UI%3EBrowser%3EPermissions%3EPrompts%22> >>>>> >>>>> *Web Feature ID* >>>>> permissions <https://webstatus.dev/features/permissions> >>>>> >>>>> *Motivation* >>>>> In M151, we shipped the <usermedia> element (MVP) to solve the problem >>>>> of out-of-context, JavaScript-triggered permission prompts. By requiring a >>>>> direct, in-page user click on a browser-controlled element, we ensure a >>>>> strong signal of user intent before requesting media access. Based on >>>>> feedback and the WICG specification, we are expanding this MVP model in >>>>> M152. The <camera> and <microphone> elements use the exact same mechanism, >>>>> security constraints, and UI behavior as the <usermedia> MVP, but are >>>>> strictly scoped to single-capability capture. This provides a more >>>>> ergonomic, semantic API for developers building applications that only >>>>> require video or audio, streamlining the implementation while preserving >>>>> our high-confidence intent capture. >>>>> >>>>> *Initial public proposal* >>>>> *No information provided* >>>>> >>>>> *TAG review* >>>>> https://github.com/w3ctag/design-reviews/issues/1218 >>>>> >>>>> *TAG review status* >>>>> Issues addressed >>>>> >>>>> *Goals for experimentation* >>>>> None >>>>> >>>>> *Risks* >>>>> >>>>> >>>>> *Interoperability and Compatibility* >>>>> *No information provided* >>>>> >>>>> *Gecko*: No signal >>>>> >>>>> *WebKit*: No signal >>>>> >>>>> >>>>> Do we have a signal for the broader "permission elements" concept? >>>>> >>>> No response from WebKit or Mozilla yet unfortunately: >>>> https://github.com/WebKit/standards-positions/issues/651 >>>> https://github.com/mozilla/standards-positions/issues/1392 >>>> >>>> With that, I don't see the point of asking for a separate position on >>>> this variation (the tradeoffs are very similar). >>>> >>>> >>>>> >>>>> >>>>> *Web developers*: No signals >>>>> >>>>> *Other signals*: >>>>> >>>>> *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? >>>>> *No information provided* >>>>> >>>>> >>>>> *Debuggability* >>>>> *No information provided* >>>>> >>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>> No >>>>> >>>>> >>>>> More details on that one? >>>>> >>>> >>>> I believe it's all platforms except WebView >>>> >>>> >>>>> >>>>> *Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>> Yes >>>>> >>>>> >>>>> Link to the tests? >>>>> >>>> >>>> I hear they're in progress but haven't landed yet. So given that this >>>> is a rather big feature, I'd like to see the tests on wpt.fyi before I give >>>> my approval. Otherwise looks great to me, I'm excited to see this ship! >>>> >>>> >>>>> *Flag name on about://flags* >>>>> CameraAndMicrophoneElements >>>>> >>>>> *Finch feature name* >>>>> *No information provided* >>>>> >>>>> *Non-finch justification* >>>>> *No information provided* >>>>> >>>>> *Rollout plan* >>>>> Will ship enabled for all users >>>>> >>>>> *Requires code in //chrome?* >>>>> False >>>>> >>>>> *Tracking bug* >>>>> https://b.corp.google.com/issues/531672795 >>>>> >>>>> *Launch bug* >>>>> https://launch.corp.google.com/launch/4486395 >>>>> >>>>> *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 update 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 desktop152 Shipping on Android152 >>>>> >>>>> *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 extension of <usermedia> 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. The open >>>>> topics >>>>> are listed under WebRTC working group's github repo's issue. Once this >>>>> lands we will start the post-MVP discussion. >>>>> >>>>> *Link to entry on the Chrome Platform Status* >>>>> https://chromestatus.com/feature/5153829504024576?gate= >>>>> 6067694366490624 >>>>> >>>>> 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/f0bc1deb-4ab2-4b12-a17a-7fea26deebc4n%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0bc1deb-4ab2-4b12-a17a-7fea26deebc4n%40chromium.org?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/4e0e9e38-fbf8-40aa-964d-787882e8a4f7n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4e0e9e38-fbf8-40aa-964d-787882e8a4f7n%40chromium.org?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/CAFUtAY_5T58jMzALyD9b-788BFibRaczOCrSGb20FQ0WuWN1uw%40mail.gmail.com.
