commit ec54dafe8f1bf4164343a5967b8f28cc287d68cf
author Hiroki Nakagawa <nhiroki@chromium.org> Tue Jun 08 06:12:31 2021
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Jun 08 06:12:31 2021
tree 16d7e449d8a5c519c555d4f4c38faac58bd86716
parent b93a66938c2625cd8d37dddd5cb81e95c8e96b85

Prerender: Restructure cancellation of PrerenderHost

This is a prerequisite CL for implementing the logic of cancellation
during activation.

> Short summary

This CL...

- renames PrerenderHostRegistry::AbandonHost() to CancelHost().
- renames PrerenderHostRegistry::AbandonReservedHost() to
  OnActivationFinished().
- introduces PrerenderHostRegistry::OnTriggerDestroyed().

> Details

Cancellation of prerendering can be requested from various entities:
pages triggering prerender, pages being prerendered, and pages
activating prerendered pages. They should handle cancellation in
different ways:

A: Pages triggering prerender cancel non-reserved hosts but don't cancel
   reserved hosts. This is because cancellation from the pages should
   not be critical (e.g., removal of <script type="speculationrules">),
   and should continue the ongoing activation.
B: Pages being prerendered cancel both non-reserved and reserved hosts.
   If it's reserved, they should start fallback navigation. This is
   because cancellation from the pages should basically be critical
   (e.g., use of disallowed features in prerendered pages) and should
   not continue the ongoing activation.
C: Pages activating prerenderd pages cancel the host reserved by itself
   and start fallback navigation. It's obvious that this case should not
   continue the activation.

In addition to the above,

D: NavigationRequest for activation removes the reserved host on its
   destructor. Unlike (C), this case should not start fallback
   navigation because this happens after cancellation or completion of
   the activation.

Before this CL, PrerenderHostRegistry's APIs were divided based on
whether the host is reserved or not, that is, AbandonHost() and
AbandonReservedHost(). This required the callers to know if the host is
reserved beforehand. This made it difficult to use the APIs.

To simplify the APIs, this CL restructures them as follows:

- For now, only PrerenderProcessor::CancelPrerendering() takes (A), so
  this CL introduces PrerenderHostRegistry::OnTriggerDestroyed() that is
  specialized for that. The API only cancels non-reserved hosts.
- (B) and (C) are almost the same. These should be handled by one API so
  that the callers no longer have to manage the state of the host. This
  CL renames AbandonHost() to CancelHost() and restructures it for them.
- Regarding (D), this CL renames AbandonReservedHost() to
  OnActivationFinished() and specializes it for (D).

Bug: 1169594, 1195751
Change-Id: I8dfdd27279fddd5c69bbbd1392863d814655a5c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2942531
Commit-Queue: Hiroki Nakagawa <nhiroki@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Lingqi Chi <lingqi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#890117}