Speculation rules: `form_submission` field

[domfarolino]

Specification title

Speculation rules: form_submission field

Specification or proposal URL (if available)

No response

Explainer URL (if available)

https://github.com/WICG/nav-speculation/blob/main/prerendering-form-submission.md

Proposal author(s)

@robertlin-chromium

MDN URL

No response

Caniuse.com URL

No response

Bugzilla URL

No response

Mozillians who can provide input

@zcorpan

WebKit standards-position

WebKit/standards-positions#614

Other information

See https://github.com/WICG/nav-speculation/blob/main/prerendering-form-submission.md. For implementation reasons, Chromium has found it difficult to activate a prerender during a form submission navigation, since form-initiated navigations have extra state and checks associated with them that the original prerender request did not incur.

From peering into other engines's source code, we suspect other browsers may have similar limitations, so we're proposing the form_submission boolean field to indicate whether a prerender request should be processed by the browser as if it were a form submission navigation, so that it can be activated by real form submissions. We'd love to hear if Gecko's speculation rules implementation would have a similar limitation to Chromium—not being able activate a traditional prerender from a form submission navigation.

In a way, this is similar to the target_hint field that Chromium introduced, due to browser complexity of activating prerenders inside different browsing contexts than those that initiated the prerender.

Note that the need for this proposal is not entirely due to browser limitations in form navigation handling. It's also to avoid wasted prerenders when CSP would otherwise prevent form navigations. See the explainer for more details.

/cc @robertlin-chromium @tunetheweb

[valenting]

CC @smaug----

[smaug----]

@domfarolino so why isn't this thing a method on form element, something which could be triggered from JS easily?

[tunetheweb]

I’m not sure I understand the question (so I probably should leave it to @domfarolino to answer because of that, but hey ho). Are you proposing a speculation-method on the <form> element that can be triggered from JS (form.speculate())?

That could possibly be added in the future I suppose, but it would be separate to the current way speculation rules work (JSON in a special script tag added and removed by the developer) so I could see some downsides that including:

• Confusing to developers when these form-driven developments work differently.
• Incompatibility with existing tooling (e.g. Chrome DevTools has very good Speculation Rules support based on the current JSON-based scripting).
• Questions on how to cancel a form-based speculation (currently you can do that by deleting the rule from the page).
• An inability to trigger speculations independent off the form contents (e.g. you could trigger a speculation for /search?q=Common%20searxh%term on page load if that was a particularly common search term (not saying this is a good idea - but it’s possible!).

Of course the form action could insert the JSON-based rule is that’s what you’re suggestion, but at the minute the proposal is just allow add an attribute to allow matching, rather than being too prescriptive on how the speculation is triggered. If a form inserted the rule the extra attribute being proposed here would still be needed. And if it doesn’t insert but just triggers the speculation separately, then we’d need to think more about the points above.