Re: [w3ctag/design-reviews] Incubation: speculation rules `form_submission` field for prerendering (Issue #1192)

robertlin-chromium left a comment (w3ctag/design-reviews#1192)

Hello TAG reviewer, thanks for the comments.
About the concerns:

**Security and privacy**
[As noted in the explainer](https://github.com/WICG/nav-speculation/blob/main/prerendering-form-submission.md#:~:text=It%20should%20be%20noted%20the%20speculation%20will%20need%20to%20be%20triggered%20by%20the%20page%20in%20some%20manner), our intention is not to automatically speculate such navigations, for some of the reasons you’ve given and others. In short the heuristics of when to speculate are not as clear as they are for links. The current scope of the feature therefore is to simply allow such prerenders to be used if they are manually triggered by developers.

So a developer could trigger prerenders with this new parameter based on their own heuristics (e.g. when typing in an input field is paused, when a search field is tabbed out of, when the Submit button is hovered… etc.) and this feature just adds the ability of any manually triggered prerenders to be used when the form is submitted. We have examples of developers attempting this and then being surprised that the prerender is not used.

We [have had requests to automatically trigger form-based speculations](https://issues.chromium.org/issues/346555939#comment6), like we do for other speculations but for the reasons discussed here, this is more complicated than for links and upon speaking to that developer they understand why this is out of scope. If we ever introduced such functionality that would be a new feature and we would raise a new request for review with TAG.

Therefore, since there is no auto-triggering of speculations, we foresee no new security or privacy issues that are not already present with developer-triggered fetch requests.

**API design**
The (2) is the case that CSP policy `form-action: ‘none’` can be set, and under the current design prerendering will always be prepared as non-form navigation, so upon prerender activation the prerendered result needs to be dropped, and this causes a waste of resource. Also we notice that in the existing spec https://html.spec.whatwg.org/multipage/browsing-the-web.html#populating-a-session-history-entry step 5.4 (should navigation response to navigation request of type in target be blocked by Content Security Policy) is run after navigation starts while CSP check for `form-action` directive is pre-navigation. Without this field, prerendering will always be prepared as non form submission and will actually break the current spec. Prerender activation needs to be started to check whether the prerendered page is eligible. For 1) this is therefore likely to affect all browsers, not just Chrome but yes there are other, potentially Chrome-specific, reasons why we are proposing this approach but there is precedence with another field to lift a Chromium internal limitation before. https://github.com/w3ctag/design-reviews/issues/931 .
As per spec, rules with new params should be dropped if params are not in the table. As this is a progressive enhancement such UAs will not benefit, it also will not waste any prerenders since they will not be initiated.
The[ find matching links](https://html.spec.whatwg.org/multipage/speculative-loading.html#find-matching-links) algorithm is for document rules, and we will only support form_submission to be used for list rules, which specify urls explicitly.

**Eagerness**
The rules will be injected into the page manually by the developer on their own heuristics (as the user types into a field, or on hovering the submit/search button). So it’s not “UA implementation internals”. We can add recommendations/warnings to the spec for developers as to when/how to use this, but this feels more appropriate for documentation/guidance than the specification.

Note, in terms of the Speculation Rules `eagerness` field, this will technically use the immediate eagerness value. The other values such as eager, moderate or conservative are for automatic triggering of links in the document which, as per above, are out of scope.

**Minor comments regarding the explainer**
Thanks for noticing that. It is fixed by https://github.com/WICG/nav-speculation/pull/427
We have more signals from places like[ WebPerf Slack (12-14 +1’s)](https://webperformance.slack.com/archives/C04BK7K1X/p1762510214257469) and private conversations. We can try to get people to be more public about this if necessary.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1192#issuecomment-3996180497
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1192/3996180497@github.com>