Strike databases are a way of counting “strikes” in a per-profile manner that is persisted across restarts and, due to caching, available synchronously. Strike information is not synced across devices and, depending on the chosen implementation, provides support for easily clearing it on browsing data removal.
An example use case for strikes is the address autofill: To ensure that a user does not see too many “Save address” prompts, autofill uses a strike database that keeps track of how often a user has declined to save a profile - it can do so either by tracking counting consecutive declines on a given domain or by counting how often a user has declined to save a specific address.
To use a strike database, you need to do the following:
Traits that specify how your strike database is supposed to behave, e.g., the expiry time of strikes or the maximum number of strikes before a features is blocked.SimpleAutofillStrikeDatabase<YourTraits> or HistoryClearableStrikeDatabase<YourTraits> and pass a pointer to the StrikeDatabaseBase. This is a KeyedService that you obtain in your embedder (e.g., Chrome).Note that SimpleAutofillStrikeDatabase<YourTraits> and HistoryClearableStrikeDatabase<YourTraits> contain no state beyond a pointer to the StrikeDatabaseBase. Therefore instantiating lots of strike databases across multiple tabs is cheap and they all share the same underlying database.