Add wasConsumed

[phistuck]

Sometimes there is a user activation, but it was consumed by a powerful API call already (so the next call could be blocked) -

// Somewhere before this code window.open('/'); was called.
if (userActivation.isActive && !userActivation.wasConsumed)
{
 window.open('!'); // This will not be blocked, woo hoo!
}

[dtapuska]

What would be the use case for this? The isActive can't definitively tell you that it actually allows the gesture to occur because of out of process iframes. Basically the two iframes can race to consume the gesture.

[phistuck]

The isActive can't definitively tell you that it actually allows the gesture to occur because of out of process iframes.

Exactly, but the combination it and wasConsumed should. At least with a quite good confidence.

It is not about racing, though, but about unrelated code parts that happen to do something powerful.
Also, if the time has passed and the user activation is irrelevant anymore in terms of what the browser lets you do (you click, but the system is loaded, so the browser only tries to open the window after a second, thus blocking the popup), it is still a user activation, but it is not a powerful one anymore (it was consumed by the browser).

[dtapuska]

It is unclear what the lifecyle of isActive and wasConsumed would be. Can you draw a state diagram? And I think this information would be available to an event listener if it used say a capturing event listener in the beginning read the value, then did stuff and then re-read the isActive flag.

I'm just trying to understand what value this adds if you still need to deal with the failure case anyways.

[mustaqahmed]

Here are my thoughts from User Activation v2 perspective:

• One of the goals of our UAv2 project is to implement (then propose) a simple alternative. For compat reasons, we already have two "levels" of activation (transient vs sticky). Adding more "levels" would make the interface more complicated for developers with more state combinations. E.g. would we have both the states (isActive && wasConsumed) and (!isActive && wasConsumed)? And this would potentially add more racy corners.
• To me, it's not clear why an iframe would need to distinguish between consumption by other invisible frame (e.g. a parent frame) vs by the browser through timeout. Any use-case?
• Finally note that we are aware of the 1sec expiry problem with low-speed networks, and we plan to have at least 10sec expiry in UAv2.