Speculation rules: form_submission field

at a glance

Syntax

The field lives inside a prerender rule in a <script type="speculationrules"> block. Per the open PR's spec-preview diff of prerendering.html, the rule parser accepts a form_submission member only when its value is a boolean; for a non-boolean value, the user agent may report a console warning and the individual rule parser returns null. The explainer says the intended form-submission use is restricted to list rules (explicit urls) because document rules match links, not submit buttons. However, the current open PR diff parses the member generically and propagates it through the predicate/document-rule candidate path; it does not visibly add a list-only rejection. Treat that as unresolved proposal text, not a settled parser guarantee.

// Two prerendered candidates: one prepared as a form submission, one ordinary.
// A navigation that matches the parameters activates the matching one.
{
  "prerender": [
    {
      "form_submission": true,
      "urls": ["/expect_form_submission.html"]
    },
    {
      "urls": ["/not_expect_form_submission.html"]
    }
  ]
}

Why it exists

Prerendering loads a page before the user navigates so the navigation is instant. But form submissions are special navigations: they carry state ordinary navigations lack, and at least Chrome runs extra checks on them that a prerendered page never went through. So a prerender prepared the ordinary way can never be activated by a form submission — and without an eligibility check, the browser could waste resources prerendering a page CSP would reject anyway (via form-action). Developers asked for this specifically for search-style GET forms (crbug.com/346555939). The proposal addresses both halves: a candidate marked for form submission can run the additional eligibility checks while being prepared, and a later form submission can activate it only if the browser created and retained an eligible prerender and the activation navigation matches.

Prefetch rules are unaffected: prefetch only downloads HTML without starting a navigation, so form navigations already work without this field.

In the proposal's parsing changes, a prefetch rule that does specify form_submission is discarded rather than rejected as a whole rule set — the field is a prerender concept, and a prefetch cannot carry it.

Lifecycle and context

Preparing is not activating. Marking a candidate form_submission only prepares the prerender; the candidate is then retained, and activation happens later, if at all, when a navigation arrives that matches the retained record. The explainer is explicit that the proposal “does not add functionality to trigger the speculation”, so a rule that is never matched is never activated.

The proposal's own review records one of these lifecycle questions as not applicable — prerendered pages cannot be kept in BFCache — and answers another factually: speculative loading does not work in disconnected documents. On context, the proposal does not distinguish first-party from third-party use, behaves the same in private browsing, and — because a speculatively loaded page is itself a waste of resources — speculative loads are skipped inside a page that is already prerendering.

Examples

// Simple GET search form: decide WHEN to speculate yourself.
// `debounce` is an application helper, omitted here for brevity.
const form = document.querySelector("#search");
let rulesScript;

function speculate() {
  // Build the same URL this simple GET form will submit, including its query.
  const target = new URL(form.action, location.href);
  target.search = new URLSearchParams(new FormData(form));

  rulesScript?.remove(); // replace the old candidate instead of accumulating rules
  rulesScript = document.createElement("script");
  rulesScript.type = "speculationrules";
  rulesScript.textContent = JSON.stringify({
    prerender: [{ form_submission: true, urls: [target.href] }]
  });
  document.head.appendChild(rulesScript);
}

form.querySelector("input").addEventListener("input", debounce(speculate, 300));
// Submission can activate only if an eligible prerender was created, retained,
// and matches the eventual form navigation.

Browser compatibility

There is no browser-compat-data (BCD) entry for this field (BCD's html/elements/script.json covers speculationrules but not form_submission, checked 2026-07-25), so the table below is an interim view built from ChromeStatus ship data and public signals — not from BCD.

Web developers: “In development” is recorded on ChromeStatus (web_dev_views = 2).

Security and privacy

The explainer records no new accessibility, privacy or security considerations on top of the existing ones for speculative loads in general, and answers the W3C TAG security and privacy questionnaire: the field exposes no information and deals with no sensitive or personal data, creates no state that persists across browsing sessions and no temporary identifiers, does not expose platform information, does not access device sensors or other devices, does not enable a new script execution or loading mechanism, does not downgrade any default security protection, and works the same in private browsing. The larger Speculation Rules specification carries the Security considerations and Privacy considerations sections that this field inherits.

The eligibility check this field enables is a resource argument rather than a privacy property, and is framed that way in the explainer: preparing the prerender as a form submission lets the browser run the form-action CSP check up front, so a page whose policy would reject the submission is never prerendered. The explainer's security and privacy section records no considerations for the feature beyond those already existing for speculative loads in general, and describes the check only as avoiding wasted resources.

Specifications

See also

• WICG — Speculation Rules form submission explainer
• WICG nav-speculation issue #322 — initial proposal
• crbug.com/346555939 — developer request for GET-form prerendering
• chrome.dev — prerender GET-form demo
• Design doc (Google Docs)
• Chrome Platform Showcase — Speculation rules: form_submission field (also: feature detect)