Understanding the New <permission> Element in Chrome 126

Chrome 126 introduced a new HTML element: <permission> , which is now available for trial and being standardized. This article explains the problems with current web permission prompts and how the new element addresses them.

Problems with Web Permission Prompts

When web applications need to access advanced browser features, they must request permission from users. For example, when Baidu Maps uses the Geolocation API to get user location, the browser prompts for permission.

Permission requests are typically triggered in two ways: passive implicit triggers or active explicit triggers. For instance, Geolocation API uses implicit prompting on first use via navigator.geolocation.getCurrentPosition() . Other APIs like Notification API or Device Orientation API use explicit static methods like Notification.requestPermission() .

Websites can call methods like navigator.mediaDevices.getUserMedia() or Notification.requestPermission() immediately on load, causing permission prompts to appear before user interaction. This is permission abuse.

Additional issues include: permission prompts often appear above the "death line" (outside the visible browser window), making them easy to miss; once users deny a permission, changing it requires navigating to specific browser settings; and users often need detailed instructions to find and reset permissions.

The <permission> Element

To solve these issues, the <permission> element was introduced. It allows developers to declaratively request permissions:

<permission type="camera" />

The "type" attribute represents the permission list (multiple values can be space-separated). Currently allowed values are 'camera' , 'microphone' , and 'camera microphone' . By default, the element renders as a button with minimal user agent styling.

For permissions that allow additional parameters, the type-ext attribute accepts space-separated key-value pairs, such as precise:true for geolocation permissions.

When users interact with the <permission> element, they can cycle through various states: if they previously denied the permission, they can allow it for the current visit or permanently; if they previously allowed it, they can continue allowing or revoke it; if they previously denied, they can continue denying or allow it this time.

The element's text automatically updates based on state. For example, if permission is granted, the text changes to indicate the feature is allowed.

Events and Integration with Permissions API

The <permission> element can be used with the Permissions API. Several events are available:

onpromptdismiss : Fired when the permission prompt triggered by the element is dismissed by the user.

onpromptaction : Fired when the user takes action on the permission prompt. This doesn't necessarily mean the permission state has changed.

onvalidationstatuschange : Fired when the element switches from "valid" to "invalid", such as when it's obscured by other HTML content.

Event listeners can be registered inline in HTML or using addEventListener() :

<permission type="camera" />
<script>
  const permission = document.querySelector('permission');
  permission.addEventListener('promptdismiss', showCameraWarning);

  function showCameraWarning() {
    // Show warning that the app isn't fully usable
    // unless the camera permission is granted.
  }

  const permissionStatus = await navigator.permissions.query({name: "camera"});
  permissionStatus.addEventListener('change', () => {
    // Run the check when the status changes.
    if (permissionStatus.state === "granted") {
      useCamera();
    }
    // Run the initial check.
    if (permissionStatus.state === "granted") {
      useCamera();
    }
  });
</script>