It's unclear to me what the right cost/benefit tradeoff is here.  Getting all engines to align on a single, simple, well-specified behavior without substantial loss of UX quality is likely a pretty large undertaking.  At a minimum we should use this bug to track specific instances of developer pain to help us identify and prioritize any low-hanging fruit.

To get started, it would be useful if someone would compare the spec and implementation and list all of the differences. It could be that there are some minor things that would be trivial to fix, and just a few large issues where the cost/benefit tradeoff is uncertain.

> Domenic@ has done a bunch of work in HTML to capture the basic notion an action that is "triggered by user activation": 

Let me lighten that statement a bit :). The spec there is largely inherited from ye olden days. It has recently been revised to add a few extra events, but it isn't really the result of a bunch of solid investigatory work and testing.

The upside being, we should feel free to make changes to it, if we can back them up with cross-browser agreement and (probably manual) web platform tests.

Mustaq, do you have some spare cycles in this Q (or next) to do some investigation here?

I finally got around to writing up my thoughts on what we should do with user gestures. I think if we got support from other vendors for this change and proved that it is web compatible then we wouldn't need to do the work to figure out current browser behavior since this proposal would replace all of that with a much simpler system.

https://docs.google.com/document/d/1pX8DN4iBNkl-OWA8Gv89a4oir1BBJXxlkn3O2bH1N4Q/edit#

Thoughts welcome. I'd also welcome someone taking over that doc and driving standards discussion around it. I just wrote it up to have a place to have a coherent discussion about it, not because I can own driving this. :)

I'm a big fan of that proposal. The only part I'm worried about is taking a dependency on feature policy. That section implies things will break under the new proposal, and if sites move to start using some feature policy stuff we add, maybe they can un-break themselves. Are we OK with that kind of disruption?

What would be the next step here? I'd guess getting Blink buy-in, before moving on to trying to persuade others to follow.

There's def some compatibility risk due to the postMessage thing. We might need to make the proposal a bit less pure due to real world web compat (e.g. maybe postMessage grants the active user gesture bit to subframes), but that's hard to know without just trying it.

I think the next steps are:
1. Get Blink buy-in. I think, in practice, this means getting buy-in of the input team (input-dev@chromium).
2. Start a discussion with other vendors. I think the major point of contention will be whether it's OK to get rid of the the 1 second limit. Other than that, I expect it's just a matter of web compat concerns.
3. Try to ship and see what breaks. I expect that if we successfully ship something, that will sufficiently address web compat concerns that other vendors will ship shortly thereafter.

Domenic, seems like you're interested in this space. Would you want to take on 1+2? Or all 3 if you want to take a stab at making some Blink changes. :)

I can look into aligning/modifying our current implementation to Ojan's proposal in Q2 if Domenic is unavailable.

ojan@: do you think we should try a (say) 50/50 trial to assess possible breakages?

I can help start discussion with other vendors but I'd like a collaborator to help get Blink buy-in and do implementation work.

Maybe mustaq@ and I can work together on an intent to implement some kind of trial? Or should we send a design doc to blink-dev first? I feel like this ideally needs the expertise of people who know how to make potentially-disruptive changes, like the interventions folks, even if it's not really an intervention.

Another concern is whether there are any parties within Blink who would not be OK with this proposal even if it is compatible. (For example, because it might make it easier to show popups.)

If we can get the proposal to the point of "if it's web compatible, ship it" then we're in good shape and can start the cross-browser discussion. But until then we should iterate internally.

Any thoughts on how to draw out such objections? blink-dev is again my instinct.

Re #9: I can advise from a web compat perspective (this could obviously be really valuable for predictability).

Re #10: I suggest  asking OWP security folks (jochen@, mkwst@) for feedback on the proposal.  From my previous discussions with them I don't expect this proposal to be too concerning (the timeout is a heuristic after all, and same-origin abuse is not something we worry about), but it's definitely worth a chat.

Then I think an intent to implement on blink-dev is a good next step.  Ideally we'd come up with some UMA metrics to help quantify the impact and risk (how much more often do requests for gesture requests succeed / fail).  But based on my experience in  issue 611981 , it may be hard to get really useful metrics that provide a tight bound on the risk.  

I'd also research the Edge behavior a bit.  I believe they do something simpler and seem OK with it.

Anyway I agree that if we can show that this proposal is web compatible and doesn't immediately result in additional annoyance (eg. due to abuse/bugs that were previously being blocked) then shipping it and getting some spec consensus around it (probably post-ship) shouldn't be too hard.

Whatever happens here will probably influence issue 621631.  Perhaps they should be tackled together?

Ditto what Rick said.

I took another pass through the doc I linked to and resolved questions and added a few bits.

Sounds like the best thing here is to have Mustaq own driving this with Domenic as API mentor.

Re: testing the web compatibility, I don't think a 50% trial really makes sense. I think we just enable it and see what breaks. 50% trials make it easy  to accidentally WontFix bug reports because they're hard to reproduce. It's much easier if a given Chrome version behaves the same in order for finding compat bugs.

Marking as Started since Mustaq is actively working on this.

Mustaq has a design doc here: https://docs.google.com/document/d/1erpl1yqJlc1pH0QvVVmi1s3WzqQLsEXTLLh6VuYp228/edit#

A quick update on User Activation v2: in this quarter we are focusing on field trial, spec and intent to ship.

Here is a short explainer for the feature with a demo:
  mustaqahmed.github.io/user-activation-v2.

Note that User Activation v2 is already available since M67+ through chrome://flags/#user-activation-v2 or the command-line flag --enable-features=UserActivationV2 ( Issue 772432 ).

What kept us busy over the last two quarters: we have made our implementation ready for OOPIFs ( Issue 780556 ), done multiple passes of test fixing (mostly through  Issue 802294 ), and resolved various impl cracks.

All related issues now have label:UserActivation.

Yikes, got a new blocker through the field trial.

As of today, the only real blocker seems be  Issue 867599  (which is caused by an old app, btw).  This is the only such case we found in our Canary/Dev finch trial, so we believe the root cause (trying to popup from sibling frame) is not common in the Web today.

One good news is that we have came up with a reasonable way ( Issue 897829 ) to use-count those sibling-popup cases.  We will keep an eye on the counters from next week's M71 beta.

- If the counters show that compat impact is negligible, we will ship UAv2 as per proposed spec in M72.

- Otherwise, we have a two-phase backup plan:
  - Phase1: M72 will ship UAv2 with a UAv1-like relaxation that same-process sibling frames can see activation.  This will fix prominent blocked bugs like Issue 161068 and Issue 404161 in M71 while not exposing  Issue 867599 .
  - Phase2: M73 will fix  Issue 867599  and drop the above relaxation to make UAv2 fully in-line with the proposed spec.

We are turning on UAv2 today, yayy!!!

We have resolved all blocker bugs, and today reached a no-test-regressions state ( Issue 802294 ).

Launch bug: Issue 908841
Intent to ship: https://groups.google.com/a/chromium.org/d/msg/blink-dev/nkTDR8AUlwM/xsPcojA5BAAJ

I think comment #57 has the wrong launch bug.

Launch bug: Issue 904991 (correction to #c57, thanks peconn@).