Thank you very much! I will keep an eye on the dashboard. On Tue, Aug 11, 2026 at 6:14 PM Rick Byers <[email protected]> wrote:
> Excellent, thanks Ravjit! If you say the tests are passing, that's good > enough for me (we can always backtrack if we find some surprise / bug we > can't quickly fix). So LGTM1 to ship once the test names are corrected and > assuming you'll check the wpt.fyi results after it lands and fix any issues > before it reaches stable. > > It's your call if you want to land a change to status=experimental first. > It doesn't hurt, and it might be useful if you don't immediately get 3 > LGTMs. > > Rick > > On Tue, Aug 11, 2026 at 11:55 AM Ravjit Uppal <[email protected]> wrote: > >> Hi Rick, >> >> Thomas is OOO, so let me take this. >> There was no particular reason for not changing the status to >> experimental. I will update the status to "experimental" before we switch >> it to "stable." Additionally, I will remove "tentative" from the file >> names. I expect all of them to be passing fairly consistently. >> >> Thanks! >> Ravjit >> >> >> On Tue, Aug 11, 2026 at 5:32 PM Rick Byers <[email protected]> wrote: >> >>> 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/CACfOCka43oqjNd6aWvqt-Ok47VgXMNuz4y-0sGpWncGadn-6nA%40mail.gmail.com.
