Carry over sticky activation for same-origin navs and traversals

[domenic]

See discussion in WICG/view-transitions#239 and #11328 (comment).

This also includes an editorial update to define history-action user activation as a simple boolean, instead of using the timestamp infrastructure.

Details:

• To avoid encouraging racy code, this is sticky activation only, not transient activation. This requires adding an additional boolean to the user activation data model, but oh well.
• This does not propagate the information to iframes or parent frames. It is only for the navigated frame (which can be an iframe), and it copies from its predecessor Window in that same frame.
• This works for both traversals and push/replace navigations, and both bfcached and non-bfcached traversals. (Except for iframes, which inevitably get unloaded and then re-loaded during non-bfcache traversals that change the top-level page, and so will still lose their sticky activation state.)

---

/cc @mustaqahmed @nickcoury

---

• At least two implementers are interested (and none opposed):
  • Chromium is prototyping
  • WebKit is positive: Sticky user activation across same-origin navigations WebKit/standards-positions#547
  • There wasgeneral interest from Gecko and WebKit in Upcoming WHATNOT meeting on 2025-05-29 #11328 (comment), and they have reviewed this PR a good amount
• Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/html/user-activation/navigate-to-sameorigin.html
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/433729626
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1989152
  • WebKit: TODO
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): N/A
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): N/A
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: Update sticky activation docs for new spec changes to carry across pages mdn/content#41241
• The top of this comment includes a clear commit message to use.

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

---

/browsing-the-web.html ( diff )
/document-lifecycle.html ( diff )
/interaction.html ( diff )

[smaug----]

Hmm, is this quite right? If there is a bfcached page without sticky activation, I don't think the algorithms will set the flag on those window objects if another same origin window gets sticky activation. And I'm not sure what behavior we want there.

[domenic]

You're right, that's a great catch! I think we should carry it over to same-origin bfcached documents too, to minimize differences between cases where the bfcache is hit vs. missed.

I'll add a line to the "reactivate" algorithm similar to the one I added to the "create and initialize a new Document" algorithm.

[domenic]

This ended up being more annoying than I'd prefer, as threading things from the predecessor document to the new document seems to be surprisingly unusual. (In particular, if the browser plans to unload and destroy the previous document, we need to grab the state before it does that.)

I have a half-finished local branch with an alternate option, which, at the time we set sticky activation for one window, immediately tries to propagate it to all contiguous same-origin bfcached windows in the same navigable. But I realized that keeping track of "contiguous" would add a good amount of complexity (albeit only locally), and this probably would not be how implementations do it, so I stashed that.

Of course, there's a separate issue here where the whole user activation framework ignores the complexities of propagating the bit across processes, instead just letting people access the Window object from anywhere. That is fairly pervasive in the spec ecosystem though. (That is, although specs these days are relatively good about separating out processes, the rarer cases like this one where we need to propagate state so that it lives in multiple processes are all hand-waved. See w3c/ServiceWorker#1755 (comment) for more rambling.)

[annevk]

This looks good to me. Since it's restricted to same-origin I don't think this really increases the risk of anything bad happening.

The one thing that gives me pause, but was apparently already the case, is that these values persist "forever". But maybe that's more of a comment to be had on bfcache, that expiring after a couple of days is probably a good idea.

[domenic]

Fixed nits.

@mustaqahmed is working on web platform tests; it's been a bit tricky to test but I think we're getting close to a solution. I'll wait to merge until those are ready.

I filed Gecko and MDN bugs, but https://bugs.webkit.org/ is down at the moment so I'll have to do that later.

[annevk]

A colleague brought up some good points:

• Is this invalidated by a cross-origin redirect? When you navigate from A1 to B, but B redirects to A2. I don't think it currently is, but it probably should be.
• Should this be restricted to top-level documents? That seems reasonable given the use case.

[domenic]

• Is this invalidated by a cross-origin redirect? When you navigate from A1 to B, but B redirects to A2. I don't think it currently is, but it probably should be.

I agree with this.

• Should this be restricted to top-level documents? That seems reasonable given the use case.

I'm less sure about this. My instinct was to just do whatever was easiest to spec/implement, which in this case was to allow it to work in iframes.

[domenic]

• Is this invalidated by a cross-origin redirect? When you navigate from A1 to B, but B redirects to A2. I don't think it currently is, but it probably should be.

I agree with this.

I'm no longer sure about this.

It seems like most parts of the spec only compare the endpoint origins in A -> B -> A navigations today:

• Whether to perform a COOP BCG swap
• Whether to reuse the initial about:blank Window
• navigable target names
• navigation API keys
• Whether the navigation API fires a traverse navigate event
• Whether navigation.activation.from is non-null
• Whether to clear history.state when traversing back to an entry

There's also one cases that is confusing:

• Whether the pageswap event has a non-null activation property. It is null for A -> B -> A cases, except if bfcache is involved, in which case it's non-null.

The only case, in HTML at least, that unambiguously changes behavior for A -> B -> A cases, is unload timing info, which gets censored in those cases.

Given this situation, I'd prefer sticky activation is carried over in A -> B -> A cases. Unless we have a compelling security story for a hole that carrying it over creates.

Optionally, in the future, someone could investigate whether our choices in all the above-listed cases are coherent, and if we should move to a model that considers A -> B -> A "more cross-origin". (Although I suspect the compat implications might be bad.)

[annevk]

I don't think that's correct? We call "enforce a response's opener policy" for each response we get, which includes redirect responses as navigate doesn't follow those automatically.

The risk of exploitation seems minimal, but it's the standard confused deputy attack scenario. A navigates to B which redirects to A2. A2 doesn't think it's in a state where it can hold sticky activation, but it actually does, which results in something unfortunate.

[domenic]

I don't think that's correct? We call "enforce a response's opener policy" for each response we get, which includes redirect responses as navigate doesn't follow those automatically.

You're right, although we only do the final BCG swap checking at the end, the "COOP enforcement result" structure is modified each time through the loop in a cumulative way.

So that leaves us at 6 endpoint-only checks, 2 all-legs checks, and 1 inconsistent-depending-on-bfcache check.

Sticky activation feels more similar to things like navigation API state or history.state from the 6 endpoint-only checks, where if the user experience is A -> (invisible stuff in the middle) -> A, then the appropriate state or sticky activation bit should be propagated to give the expected user experience. But I don't claim that the existing division is the result of a clear principled approach, so I still think there's room for proceeding with this as-is and then doing a full audit and discussion afterward, to see if people agree on the current model.

[foolip]

I'd like to finish this and have read through the discussion. @annevk raised two issues in #11454 (comment). On iframes, it seems simpler to just allow those navigations to carry over sticky activation.

The remaining issue is A -> B -> A navigation where B is a redirect back to A. This PR currently does carry forward sticky activation in this case.

@annevk what is your preference, to move forward with this as proposed, or ensure that A -> B -> A does not carry forward sticky activation? In either case we should file an issue about the lack of consistency and decide on what we want the default for new things to be.

[annevk]

I would prefer not carrying it forward in those cases and testing that, to prevent potential attacks. If we can somehow find proof those attacks don't exist, maybe an exception can be made.

[foolip]

Thanks @annevk. First step is a test to confirm without a doubt what the behavior implemented in Chromium is. I've asked @mustaqahmed about that.