Shipped, origin trial, flag, in development

A capability status is a claim about how far a feature has travelled through one engine’s release process, in one set of builds. In development, behind a flag, in an origin trial, and shipped describe release stages and enabling mechanisms. Runtime capability detection determines whether a visitor’s browser exposes the feature.

How it works

The labels are not marketing terms. They map onto named stages in the public processes each engine runs, and each stage has a record a developer can read.

The stages in Chromium’s launch process

Chromium’s launching-features document sets out the path. A ChromeStatus entry is step 0 for a web-exposed feature. At the prototyping step, the owner sends an Intent to Prototype to blink-dev and starts landing code, and the document states that any changes landing at this stage are behind a feature flag. Once the implementation is functional and reasonably complete as a runtime enabled feature, the document recommends, but does not require, proceeding to the Dev Trials stage and sending a Ready for Developer Testing email.

An origin trial is an optional later step after the flag stage. The document describes proceeding to the Origin Trial stage, generating an Intent to Experiment mail to blink-dev, and starting the trial after at least one LGTM from the API owners. Shipping is the separate gate: the document names three LGTMs from API owners on an Intent to Ship. Trials are time-boxed. An initial origin trial or experiment may only run for 12 milestones of Chromium. Each extension may only be for 6 milestones at a time and requires demonstrated progress on a draft spec, TAG review, signals requests, community outreach, and web-platform-tests.

What an origin trial actually turns on

Chrome’s origin trials guide describes the enabling mechanism. Registering a trial enables a feature for all users on the registered origin. They do not need to toggle flags or switch to an alternative build, though they may need to upgrade. The token travels either as a <meta http-equiv="origin-trial"> tag in the <head>, as an Origin-Trial HTTP response header, or injected programmatically. The framework takes the first valid token and ignores the rest. Chrome ignores invalid or expired tokens.

The guide also describes variants of origin trials. A deprecation trial, sometimes called a reverse origin trial, temporarily re-enables a feature that has been removed; the guide gives mutation events, removed starting in Chrome 127, as its example. A third-party origin trial lets a provider of embedded content use the feature across multiple sites without a separate token for each origin.

Where it is supported

Firefox records the flag stage as a preference. MDN’s experimental features page lists, per feature, the builds it is included in (Nightly, Beta, Developer Edition, or Release), whether it is activated by default, and the name of the about:config preference that enables it. Features usually appear first in Nightly and are often enabled by default there for early feedback. If no major problems are found, they reach Beta and Developer Edition. Approved features ship in the stable Release channel; once a feature is enabled by default in a release, MDN removes it from the experimental features page.

WebKit’s feature status page says it has been retired. It points readers to MDN or Can I Use for support data and to WebKit Standards Positions for the project’s positions on emerging specifications.

Mapping a status to a support decision

The practical translation is narrow. A feature flag lets a developer enable a capability in a build that includes it. An origin trial lets a registered origin enable a capability for its visitors without asking each visitor to toggle a flag or use an alternative build. Chromium’s process puts changes landed during prototyping behind a feature flag; its next stage is named “Feature Complete behind a flag and implementation refinement.”

Those states are not something a page can read. A status board is a planning input for deciding whether to write the code path at all. The final runtime result still depends on the capability exposed by the visitor’s browser, whether it comes from an enabled flag, a valid origin-trial token, or a default release, so the code path has to test the capability itself.

Warning

A status label and a standards position are different records. At the Dev Trials stage, Chromium’s launch process says to consider requesting signals from other browser vendors and the developer community. Before shipping, it says to request signals at least one month in advance if they have not already been obtained. The WebKit standards-positions issue for the Web Install API carries the label position: oppose (Web Install API, WebKit).

Examples

Runtime detection can test both the presence of a method and whether a specific payload passes that method’s validation. The first example provides a fallback when Web Share is absent; the second checks a selected file without starting a share request.

Gating on the capability at runtime

The test checks the method the feature exposes. MDN documents navigator.share() as requiring a secure context and transient activation, so the call is made from the button handler (Navigator: share() method, MDN).

<!doctype html>
<html lang="en">
  <meta charset="utf-8" />
  <title>Capability detection</title>
  <button id="share" type="button">Share this page</button>
  <p id="status" role="status"></p>
  <p id="fallback" hidden>
    Copy this link: <a id="page-link"></a>
  </p>
  <script>
    const button = document.querySelector("#share");
    const status = document.querySelector("#status");
    const fallback = document.querySelector("#fallback");
    const pageLink = document.querySelector("#page-link");

    pageLink.href = location.href;
    pageLink.textContent = location.href;

    button.addEventListener("click", async () => {
      if (!("share" in navigator)) {
        fallback.hidden = false;
        status.textContent = "Sharing is unavailable; copy the link instead.";
        return;
      }

      try {
        await navigator.share({ title: document.title, url: location.href });
        status.textContent = "share() resolved.";
      } catch (error) {
        status.textContent = `share() rejected (${error.name}).`;
      }
    });
  </script>
</html>

The branch tests the capability when the user acts. The fallback changes the page visibly and provides a usable link without calling another optional API.

Checking a file payload before offering an action

navigator.canShare() returns whether specified data can be shared with navigator.share(). Pass the selected File in the files array to test that payload (Navigator: canShare() method, MDN).

<!doctype html>
<html lang="en">
  <meta charset="utf-8" />
  <title>File share capability</title>
  <label>
    Choose a file
    <input id="file" type="file" />
  </label>
  <p id="file-status" role="status">No file selected.</p>
  <script>
    const fileInput = document.querySelector("#file");
    const fileStatus = document.querySelector("#file-status");

    fileInput.addEventListener("change", () => {
      const [file] = fileInput.files;

      if (!file) {
        fileStatus.textContent = "No file selected.";
      } else if (!("canShare" in navigator)) {
        fileStatus.textContent = "File-share validation is unavailable.";
      } else {
        const result = navigator.canShare({ files: [file] });
        fileStatus.textContent = `canShare({ files }) returned ${result}.`;
      }
    });
  </script>
</html>

The example reports only the synchronous validation result. It does not open the share sheet or claim that a share completed.

See also

• Launching features in Blink (chromium.org)
• Get started with origin trials (developer.chrome.com)
• Experimental features in Firefox (developer.mozilla.org)
• WebKit Feature Status (webkit.org)
• Web Install API (navigator.install)
• Installability criteria
• Web Share API

Specifications

Specification	Status
None.