Should last activation timestamp be reset after navigation?

[rakina]

Currently each Window has a last activation timestamp that never gets reset afterwards, except when the user activation is consumed (but that sets the timestamp to negative infinity, so sticky activation isn't affected). This means once any user activation happened, sticky activation will be true forever for that Window. If a user navigates away from a document and it gets stored in the back-forward cache and it later gets restored when the user navigates back to the document, the sticky activation stays true, so sticky activation-gated APIs can still run even if the activation was done before the navigation.

I'm not sure how bad this is, since we also have transient activation which is less affected due to expiry. The only usage of sticky activation in the HTML spec is in prompt to unload, which can be annoying I guess (clicking an iframe once means it can always send the beforeunload dialog on future navigations where we reuse the document?).

If it sounds OK, maybe we can just leave a note in the spec to make people more aware of this. If it sounds bad, maybe we can reset the last activation timestamp in unloading document cleanup steps.

cc @mustaqahmed @domenic

[annevk]

Nice catch! I suspect we should reset this.

cc @EdgarChen

[mustaqahmed]

Thanks for filing this. If I recall correctly, we didn't consider the reloading-from-cache case when defined the initial value.

In my opinion, the term "cache" implies the browser is supposed to restore page states in a reasonable way, so resetting the sticky state on reload seems questionable. Consider the following scenario, which I believe can easily happen in reality: when a page is open in a tab for months, the sticky state is preserved; but even a accidental/short-lived navigation away would lose the state if we reset on cache-reload. This doesn't sound like a reasonable cache behavior to me.

Wondering if any other states in Window or Document are spec-ed to be reset-on-cache-reload. They could be a good guide for this discussion.

[rakina]

Sorry for the late reply! I went searching and found two examples of document/window states:

• Screen Wake Lock API releases the Wake Lock when the document loses full activity (~ when we navigate away)
• Focused area is kept (and no focus/blur events are fired) even when the "fully active" state changes (both directions)

I wonder what's the worst that can happen in both options?

• If we keep the timestamp: All sticky-activation gated APIs won't need reactivation after the first activation, even if it happens a few navigations ago. Maybe less secure?
• If we clear the timestamp: Needs reactivation for both sticky-activation and transient-activation-gated APIs. Maybe some sticky-activation-gated APIs do not expect that its activation can be lost and might behave weirdly?

I guess keeping the timestamp might be slightly better, because "sticky activation" is already somewhat weak anyways?

[annevk]

Do we know what APIs build on sticky? It could be weird that your restored document is no longer able to call an API it already has a handle on. (But I also think it could be weird from a user perspective that seemingly equivalent actions result in different behavior. As in, we would reset this on a full reload or a fresh navigation to the same URL. And to the user that is not necessarily different from going back and forward.)

[rakina]

Looks like nothing currently references "sticky activation gated-APIs" (how can I find references from other specifications?), and the only usage of "sticky activation" is for checking whether an unload prompt can be shown, which is a one-time thing, so clearing the timestamp might be OK here (and would prevent annoying unload prompts?)

Maybe @mustaqahmed can point to some usage of sticky activation?

[annevk]

(There is no good way to find backreferences unfortunately. It's a problem.)

[rakina]

Revisiting this again now, I think it is better to keep the sticky user activation even after a BFCache restore, as it is more consistent with the way we keep other states (like focus) on the document. From looking at the usages of sticky activation in Blink, I don't think it's too problematic (it's mostly for showing UI elements like beforeunload prompt/virtual keyboard/etc?).

@mustaqahmed @EdgarChen @annevk if there's no concern here, I'll add a note about this behavior near this section.

[domenic]

BTW we can now find cross-spec references: https://dontcallmedom.github.io/webdex/s.html#Sticky%20activation%40%40html%25%25dfn