Hi! Thanks for this. It would help us a lot if you could explain what problem you want to solve and what the use cases are? You've clearly put thought into the detail, but it's hard for us to work with that when we're not sure where on the big picture you're focusing.

Our explainer explainer might help with this.

@mustaqahmed Hmmm, we just noticed that we also have a review for #300, are these the same review? (We're just a little confused. Can we merge these reviews together?)

@travisleithead While the topics are similar Chrome expects to ship the UserActivationAPI still against the old activation system because the ouputs exposed are the same. #300 is about a JS API that you could polyfill today with the tricks I provide in the example. This issue is about a new implementation design and specification how user activation should work in browsers.

One question that I think would help our evaluation: is there a list somewhere of the behaviors that depend on the user activation state?

I ask because I wonder if they're at similar positions on the spectrum from (a) annoyance to (b) serious privacy or security violation. That is, I'm wondering whether we're now depending on the user activation concept, originally created for annoyance mitigation, for things that are actually more sensitive.

As @hadleybeeman pointed out, we'd like to see a more complete explainer, starting with a problem statement.

One question that I think would help our evaluation: is there a list somewhere of the behaviors that depend on the user activation state?

Here is a list of Chrome APIs that rely on user activation.

Note that it's a Chrome-only list, and major browsers vary significantly in exposed behavior today. For example, even for popups browsers show widely different activation behavior.

I ask because I wonder if they're at similar positions on the spectrum from (a) annoyance to (b) serious privacy or security violation. That is, I'm wondering whether we're now depending on the user activation concept, originally created for annoyance mitigation, for things that are actually more sensitive.

That's a valid question that doesn't have any answer in the Web today because of the horrible lack of interop. This proposal formalizes a core behavior for the Web, and provides the basis for answering this question individually for every dependent API in future. We hope that those dependent APIs would (try to) gradually spec their behavior around it, and it's conceivable that some of them would be considered too sensitive to rely on it.

In short, it's not our goal to fully define ~30 different API dependencies in one shot.

I have started to make my explainer more complete, will update this thread when done.

@hadleybeeman @torgo: I have updated the explainer as suggested.

The design of timing out a user activation after some period of time (a few hundred milliseconds?) seems pretty reasonable as a simplification of stack-based approaches. So I think this seems pretty reasonable to me -- and something that has the potential to lead to better interoperability. But I think actually leading to better interoperability also depends on a solid spec and tests being written. (I suspect in this case the spec may matter more, since it feels like a space where the edge cases may be hard to think of.) So as implementation progresses, I'd definitely encourage you to keep the spec up-to-date with the additional details that you learn about how it has to be done.

One thought: it's not clear to me that there's a good reason for the middle category of consumers: the ones that use the transient state but don't consume it. Is there a reason that some of them actually don't want to consume it? Or is it just that they didn't, and now the web is constrained by compatibility?

I'd be interested in answers to the questions at the end of my previous comment -- but I'm also inclined to think the TAG isn't likely to have much more feedback at this stage, but that we'd be interested in hearing more about the results of your experiments with this simplification.

So I'm thinking maybe we'd be able to close this issue relatively soon, with the possibility of reopening it later.

Tagging for discussion at our Paris face-to-face for that reason.

Thanks @dbaron, I definitely plan to update the spec and add tests as we go ahead.

Re the middle category: avoiding consumption allows possible chaining with other activation-gated APIs. E.g. a page may want to go fullscreen only if it can access current location, or only if certain Bluetooth device is present. Here is a somewhat-out-of-date list of Chrome APIs most of which don't consume at all. This is not a perfect list but it can suggest other possible ways to chain.

Another related point is that in Chrome we have seen internal "sequencing" that also points to the need for non-consuming calls (e.g. certain pre-navigation tasks are done only with transient activation, but the activation is consumed at a later stage of the navigation). I can look up some details if you want more info.

(And I don't think web compatibility is a constrain here.)

Discussed today at our Paris face-to-face meeting. We're happy closing this issue at this point, but we'd be interested in having another look once there's a merged PR to the spec (and perhaps also results from your plans to ship this in Chrome). We'd appreciate if you file another review request then to let us know.

One issue that @hober raised in today's TAG discussion was whether this leads to race conditions where pages do things that work most of the time, but when they go over the 300ms limit they start failing intermittently. (This seems to me to be something that's more likely to happen on slower devices, etc.)

This is somewhat concerning -- it reminds me of why we generally avoid time-based approaches like this in tests (since they might work most of the time, but they won't work all of the time, and we'll end up with intermittent test failures).

While we agree that a time-based activation expiry is not ideal, it seems unavoidable in practice:

• Most major browsers (Chrome, Firefox, Safari as of 2017) have been allowing popups for a window.setTimeout() delay of at most one second---even though there was no spec requirement for this.

• If we don't have an expiry time for user activation, a malicious app could open a popup or go fullscreen minutes or hours after a user interaction (say by deliberately slowing down an event handlers, or through a "slow" Promise chain). We don't find this acceptable in Chrome from security perspective, and we believe this is why most major browsers independently can up with an expiry time (see above).

• In Chrome we had quite a few popular bugs (with upto 20 stars) that remained open for many years (upto 7 years) with the hope of finding an ideal user activation model. We were able to close them this year through the simple expiry-based model of User Activation v2.

One way to mitigate the race is to make the expiry time dependent on device/network speed. For now, User Activation v2 leaves the expiry time as an implementation defined value, and we hope to come back to it if needed. We briefly discussed this idea during our TPAC session too (with, among others, engineers from Mozilla and Safari).

@dbaron: Here is an update for your comment on 2018-10-31: the PR has landed last week, we are now working on testing it without relying on activation-gated APIs.