Add top-level site and cross site ancestry to storage key

[kyraseevers]

Add top-level site and cross-site ancestry to Storage Key in the Storage spec.

This is taking over #144, and should be landed with or after the "cross site ancestry" is added to the environment in whatwg/html/pull/11133.

• At least two implementers are interested (and none opposed):
  • Chrome
  • WebKit
  • Gecko
• Tests are written and can be reviewed and commented upon at:
  • There are many tentative tests which use a partitioned storage key (local storage, web locks, etc.). The CL to remove this tentative status is at: https://chromium-review.googlesource.com/c/chromium/src/+/6729734
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/u/2/issues/40177656?pli=1
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1977899
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=296135
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

This looks good to me modulo some minor nits. Thanks again for tackling it!

You can consider WebKit interested.

What's remaining:

1. Filing bugs against Gecko and WebKit and linking them from OP.
2. You can mark the MDN checkbox and say N/A.
3. Have you checked whether all the dependencies of this specification are holding the storage key correctly or are any doing something special with the origin field, for instance?
4. Is there a PR to rename the tests away from .tentative? (Assuming that there's nothing further that needs updating in the relevant specifications.)
5. The HTML PR needs to land first. I haven't really checked what's blocking that one yet.

cc @asutherland

[annevk]

Let's rename this to "has cross-site ancestor" to align with what HTML ended up with.

[annevk]

@domenic @bvandersloot-mozilla now that has cross-site ancestor is no longer on environment, how is this going to work here?

[domenic]

Um. I think it just never came up in whatwg/html#11133, when I convinced @bvandersloot-mozilla to switch to ESO, that we were hoping to use this for storage keys.

I noticed that we already have a branch in https://storage.spec.whatwg.org/#obtain-a-storage-key-for-non-storage-purposes which treats ESOs specially. Would that work here? Probably not. It would give the wrong answer during the phase when only an environment exists, but not an ESO, such as when navigation has started but not yet gotten as far as creating a Window object. I could see that phase as needing to look at the storage key, e.g., for service worker lookups.

So... unless there's something that's missing, I think I really screwed up here, and we should go back to @bvandersloot-mozilla's original approach. It is much more complex, but it seems to be necessary, if we're planning to use this during the liminal pre-ESO time.

[annevk]

It's been a long time since I looked at all this, but I think pre-ESO is important for service worker allocation.