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.

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).

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)