kenrb@; creis@ seemed to indicate that you were doing #1 when I chatted with him briefly. Are you able to take care of this?

kenrb: Is there already a bug for the work you're doing here?  I'm guessing this whole scenario is a little larger (ideally involving new API surface area and standards work) so maybe it should just be blocked on your bug instead of assigned to you?

IIUC, they do flow across postMessage boundaries when it is same process, but have never done so for a postMessage into a different process, which I believe your test page is illustrating. That is bug 161068.

The current plan is to move the user gesture check for blocking popups into the browser process, and make it aware of user gesture tokens and the events that generate them. The bug for doing that is 589894, which we don't consider blocking for the --isolate-extension release but will be blocking for TDI. That should make #1 feasible.

Sorry I was confused.  We have #1 already today (http://output.jsbin.com/jokawu/).  OOPIF and TDI need bug 161068 fixed to avoid breaking that.

So for this bug we should:
 - verify that it's possible to polyfill #2 today and see what browsers it works on
  - explore adding an explicit standard API for #2 so that this scenario can be supported reliably across all browsers

Based on the discussion with Dima at https://github.com/WICG/interventions/issues/12#issuecomment-252116249 it seems this is becoming pretty important for AMP.  The implementation of an API is trivial, but we need to do some spec work / consensus building (i.e. is this a global bit, or a property of MessageEvent).  Dave, do you think this is something that could fit in input-dev this quarter?

Filed https://github.com/whatwg/html/issues/1983 to specifically discuss the right API for this.

I think if we're going to pursue this, I'd prefer avoiding magical postMessage logic and give the author control. A couple possible solutions:

1. Allow the parent page to delegate that a subframe can consume it’s gestures via a Feature Policy directive. Any time the parent page has a consumable gesture, the subframe would be able to use it.

2. Allow the parent page to grab a transferable gesture token whenever it has a consumable gesture and postMessage it to the subframe.

#2 seems more predictable to me than #1 (e.g. less likely to have race conditions between the parent page and subframe), so that might be a good reason to go that route.

Hmm. Not sure if this is about gesture consumption. I think the goal here for two iframes cooperating, if the child iframe asks the parent to do something on its behalf, the parent might want to check if this request is backed by the user action.

My 2 cents: I would prefer a token based approach, because it would make a process predictable that is currently subject to heuristics like "happens within 2 seconds of". 

- it would also benefit non-iframe cases, like where a video player is lazy loaded
- it would be extendable across page loads (Pass permission to auto play with sound to next loading page)

And I also was confused. As Dima rightfully points out. There is a separate use case of wanting to know whether a child iframe executed in context of a postMessage. A token based approach would, of course, help here, too.

Having said that, I don't understand why we would not just add event.createdInContextOfUserGesture to allow user land code to implement the same restrictions that some browser APIs implement.

We (AMP) have started work on the feature that benefits the most from this  (https://github.com/ampproject/amphtml/issues/9074). AMP normally restricts many functionality to only be triggerable via user action (e.g. opening a dialog, submitting a form, show/hide content, etc...). The feature being worked on, allows iframes to trigger actions on parent page so we really need to know, with high confidence,  whether source event that started the postMessage is from a user action or not.

Anyone has any suggestions for a "light" way to polyfil this? Writing to clipboard seems too destructive as user will lose their existing clipboard data. I am hoping someone with internal knowledge of the browser stack may have a better trick for this.

Dave started working on this, thanks.