1134859 - Support domain wildcards in password manager recipes

Status: NEW

(Toolkit :: Password Manager, enhancement, P3)

Description

[Matthew N. [:MattN]]

There are times when we may want a recipe to apply to all subdomains of a domain (e.g. *.okta.com) so it would be good if we didn't have to enumerate all of the subdomains we know about in the recipe.

We should probably make sure that wildcards aren't for a whole eTLD (e.g. don't allow *.co.uk).

Some things to decide:
* How do we know which recipe to use when there are multiple e.g. if there are recipes for a.sub.example.com, *.sub.example.com and *.example.com and the user is on a.sub.example.com.
** Proposal 1: Let each recipe hook/method decide what to do. e.g. for username/password field overrides we may want to use the most-specific field override that applies
** Proposal 2: Only consider the most-specific recipe (regardless of the type of hook being considered). Example: if a.sub.example.com doesn't specify a username field override but has a different override (e.g. for multi-stage) while *.sub.example.com has a username field override. We wouldn't use the username field override since we already found a recipe that applied to our form.
* How do we handle multiple recipes for the same host but with different path regexes? Longest match? e.g. different overrides for a login page vs. a registration page.