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.

---

Points from our discussion and how this PR addresses them:

• 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 ended up being most natural and simplest, but we could potentially discuss alternatives.
• This works for both traversals and push/replace navigations. This is nice because bfcache already preserves user activation state, so now non-bfcache traversals match bfcache traversals. (Except for iframes, which inevitably get unloaded and then re-loaded during non-bfcache traversals, and so in this version will lose their sticky activation state.)

/cc @mustaqahmed @nickcoury

---

• At least two implementers are interested (and none opposed):
  • Chromium is prototyping
  • There was tentative interest from Gecko and Mozilla in Upcoming WHATNOT meeting on 2025-05-29 #11328 (comment), but we should get them to review this specific formulation
• Tests are written and can be reviewed and commented upon at:
  • TODO
• Implementation bugs are filed:
  • Chromium: TODO
  • Gecko: TODO
  • 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: TODO
• The top of this comment includes a clear commit message to use.

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

---

/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.)