Hi @robertlin-chromium, the TAG discussed this at a Breakout. Allowing search result pages to be prerendered looks like an important use case to us, and we'd like to see more work in this direction. We also have the following comments.

Security and privacy

We found that this feature requires more security and privacy considerations than the existing speculation rules. Form data usually contains user input, and therefore, allowing form submission navigations to be prefetched/prerendered introduces a new way to expose user's sensitive information. The situation can be even worse if autofilled data is exposed. We'd like to see the privacy and security considerations section reworked.

API design

1. It's unclear why the form_submission field is needed. The alternatives considered section gives two reasons: (1) to lift certain internal restrictions of Chrome, and (2) to avoid resource wasting. Neither requires spec changes as they can be fixed or optimized by the UA internally.

2. Backward compatibility design. When a UA that doesn't support this feature parses a rule with a form_submission field, how does it fall back? Does it ignore the field as treat it as a normal rule, or discard the rule completely?

3. The find matching links algorithm currently only covers <a> and <area>, and we need to augment it to cover form submission URLs. This is not mentioned by the explainer.

Eagerness

Unlike <a> and <area>, whose URLs are pretty much static, form submission URLs often include user input and are much more dynamic. The eagerness of such speculative loads must be carefully designed, otherwise the feature may either lead to huge resource waste or little effect.

For example, we don't want to prerender /search?q=f and /search?q=fo while the user is typing foo in the search field; but if we wait too long after the user finishes typing, they may have already hit the "Search" button and it's too late for us to start prerendering.

Since the eagerness strategy can be critical to the success of the feature, we'd like the spec to include more details instead of leaving everything as UA implementation internals.

Minor comments regarding the explainer

1. The example, with duplicate "prerender" keys, is not a valid JSON as required by the spec. We'd like to see a better example.
2. https://issues.chromium.org/issues/346555939 is filed by the Chrome team with only 2 stars. Is there a stronger reference for developer support?

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

Security and privacy As noted in the explainer, 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, 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 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) and private conversations. We can try to get people to be more public about this if necessary.