Re: [whatwg/storage] Add top-level site and cross site ancestry to storage key (PR #182)

@domenic commented on this pull request.



> @@ -239,7 +238,18 @@ anticipated that some APIs will be applicable to both <a>storage types</a> going
  <a>environment settings object</a>; otherwise <var>environment</var>'s
  <a for=environment>creation URL</a>'s <a for=url>origin</a>.
 
- <li><p>Return a <a>tuple</a> consisting of <var>origin</var>.
+ <li><p>Let <var>topLevelOrigin</var> be <var>environment</var>'s
+ <a for=environment>top-level origin</a>.
+
+ <li><p>If <var>topLevelOrigin</var> is null, then set it to <var>origin</var>.
+
+ <li><p>Let <var>topLevelSite</var> be the result of <a>obtaining a site</a> given
+ <var>topLevelOrigin</var>.
+
+ <li><p>Let <var>crossSiteAncestry</var> be <var>environment</var>'s
+ <a for=environment>cross-site ancestry</a>.

Um. I think it just never came up in https://github.com/whatwg/html/pull/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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/storage/pull/182#discussion_r2238567911
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/storage/pull/182/review/3065524299@github.com>

Received on Tuesday, 29 July 2025 05:28:33 UTC