Skip to content

Carry over sticky activation for same-origin navs and traversals #11454

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Carry over sticky activation for same-origin navs and traversals #11454

Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
361b667
Carry over sticky activation for same-origin navs and traversals
domenic Jul 15, 2025
ad0e6b8
Simplify per code review, also for history
domenic Aug 20, 2025
fae6b36
Minor cleanups noticed while in the area
domenic Aug 22, 2025
3939d91
Carry it over during bfcache restoration
domenic Aug 22, 2025
7e5c107
Fix build oops
domenic Aug 22, 2025
be03fd6
Fix nits
domenic Sep 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 16 additions & 5 deletions source
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -80190,8 +80190,8 @@ interface <dfn interface>VisibilityStateEntry</dfn> : <span>PerformanceEntry</sp

<h4 id="user-activation-data-model">Data model</h4>

<p>For the purpose of tracking user activation, each <code>Window</code> <var>W</var> has two
relevant values:</p>
<p>For the purpose of tracking user activation, each <code>Window</code> <var>W</var> has the
following relevant values:</p>

<ul>
<li><p>A <dfn>last activation timestamp</dfn>, which is either a
Expand All @@ -80201,6 +80201,8 @@ interface <dfn interface>VisibilityStateEntry</dfn> : <span>PerformanceEntry</sp

<li><p>A <dfn>last history-action activation timestamp</dfn>, which is either a
<code>DOMHighResTimeStamp</code> or positive infinity, initially positive infinity.</p></li>

<li><p>A <dfn>sticky activation override</dfn>, a boolean, initially false.</p></li>
</ul>

<p>A user agent also defines a <dfn>transient activation duration</dfn>, which is a constant
Expand All @@ -80217,12 +80219,14 @@ interface <dfn interface>VisibilityStateEntry</dfn> : <span>PerformanceEntry</sp
<dt><dfn export>Sticky activation</dfn></dt>
<dd>
<p>When the <span>current high resolution time</span> given <var>W</var> is greater than or
equal to the <span>last activation timestamp</span> in <var>W</var>, <var>W</var> is said to
have <span>sticky activation</span>.</p>
equal to the <span>last activation timestamp</span> in <var>W</var>, or <var>W</var>'s
<span>sticky activation override</span> is true, <var>W</var> is said to have <span>sticky
activation</span>.</p>

<p>This is <var>W</var>'s historical activation state, indicating whether the user has ever
Copy link

@smaug---- smaug---- Aug 21, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

interacted in <var>W</var>. It starts false, then changes to true (and never changes back to
false) when <var>W</var> gets the very first <span>activation notification</span>.</p>
false) when <var>W</var> gets the very first <span>activation notification</span>. It is also
carried over between windows for same-origin navigations and traversals.</p>
</dd>

<dt><dfn export>Transient activation</dfn></dt>
Expand Down Expand Up @@ -106369,6 +106373,13 @@ location.href = '#foo';</code></pre>
<var>realmExecutionContext</var>, <var>navigationParams</var>'s <span
data-x="navigation-params-reserved-environment">reserved environment</span>,
<var>topLevelCreationURL</var>, and <var>topLevelOrigin</var>.</p></li>

<li><p>If <var>navigable</var>'s <span data-x="nav-window">active window</span> has
<span>sticky activation</span>, and <var>navigable</var>'s <span data-x="nav-document">active
document</span>'s <span data-x="concept-document-origin">origin</span> is <span>same
origin</span> with <var>navigationParams</var>'s <span
data-x="navigation-params-origin">origin</span>, then set <var>window</var>'s <span>sticky
activation override</span> to true.</p></li>
</ol>

<p class="note">This is the usual case, where the new <code>Document</code> we're about to
Expand Down