User activation: what should happen if there is no browsing context?

[marcoscaceres]

While implementing the UserActivation interface in WebKit we ran into a case where there may be a spec issue (or maybe undefined behavior): it's unclear what should be returned if transient activation is acquired by a document, but then the browsing context is destroyed. Similarly, I guess, with sticky activation (i.e., would it reset?... probably not, but unsure).

Consider the simple case (assume top-level is "about:blank"):

const iframe = document.createElement("iframe"); 
iframe.src= "about:blank";
document.body.append(iframe)
iframe.contentWindow.onclick = function(){
   const { userActivation } =  navigator;
   // transient activation acquired 
   iframe.remove();
   console.log(userActivation.isActive);
}
await new Promise(r => (iframe.onload = r));

If an API has not been specified to check if a document is fully active (or has a browsing context), then it might be possible to invoke that API from a non-fully active document.

As a protection, I wonder if HTML should consume the transient activation when a document becomes non-fully active?

[domenic]

User activation is tied to a Window, not a browsing context, so I think the current spec has fully defined behavior here. I.e. user activation is retained even after removing the iframe or bfcaching a top-level document.

For the bfcache case, I think this was resolved in #6588 that the current behavior is what we want. So for example, having sticky activation persists across being bfcached, and if you happen to go into and out of bfcache during the transient activation duration somehow, you can still use the guarded API.

For the iframe case, I guess I'm unsure if we should change anything. Unlike bfcached top-level Windows, the Window instances from detached iframes aren't going to come back any time, so maybe clearing out their state is a good idea. But I'm not sure it's worth the extra spec code and complexity.

/cc @mustaqahmed @rakina

[mustaqahmed]

I think a detached iframe should cause the Window to clear the state to prevent any abuse. Imagine a malicious site swapping an iframe only to utilize one origin's user activation state in a different origin---@marcoscaceres: I guess this is what you wanted a "protection" against?

I don't know if some navigation-related algorithm already handles this state reset.

[domenic]

I think a detached iframe should cause the Window to clear the state to prevent any abuse. Imagine a malicious site swapping an iframe only to utilize one origin's user activation state in a different origin

That's not possible; different origins have different Window objects.

[marcoscaceres]

--@marcoscaceres: I guess this is what you wanted a "protection" against?

I was mostly just unsure what should happen (i.e., if it would reset). I guess the "protection" is for a hypothetical situation whereby an API does not check if it's fully active, but checks if has transient activation. Not checking for the fully active state would like be a bug, but it could definitely happen.

I'd be ok to stay silent in HTML around this for the reasons @domenic gave (added complexity, etc.). I was just really looking for clarification.

Should I add a WPTest for this, just for completeness?

[domenic]

A WPT is definitely good to have!

[marcoscaceres]

Ok, got around to creating the test... web-platform-tests/wpt#36684

Um... Chrome resets the values which seems to imply that transient activation in Chrome might be tied to the browsing context and not the window?

[mustaqahmed]

Um... Chrome resets the values which seems to imply that transient activation in Chrome might be tied to the browsing context and not the window?

Looks like so...we have the state stored in blink::Frame which is reset on most navigations. Let's discuss on the PR.

[mustaqahmed]

I just approved the PR because it matches the spec text. But I think the spec should require deactivating the user activation state when a Window is detached, to prevent any possibility of deliberate double consumption (see my comment here).

Thanks for spotting this!

For records, this comment from @annevk seems related: WICG/capability-delegation#22

[domenic]

It's not possible to re-attach a window after it's detached. Re-inserting the iframe creates a new Window object. So I don't think there is any problem with the current spec.