There is a chance we won't the bit in the IPC message when we have v2 because the receiving side may have got the info from the frame tree propagation.  Need to verify this.

Hi Devlin: any idea how to access the WebLocalFrame for the requester here?
https://cs.chromium.org/chromium/src/extensions/renderer/bindings/api_request_handler.cc?rcl=b04e162cfd5a703f8cee8586bae5941343b7a8f0&l=106

I tried accessing the script's frame through GetScriptContextFromV8ContextChecked(context)->web_frame() but the check fails here.  Not sure why.

Oof, this one will be a bit tricky.  We have blink::WebLocalFrame::FrameForContext(), which should map between v8::Context and WebLocalFrame().  However, in many unit tests, we don't set up a WebFrame at all, because setting up a WebFrame in a unittest outside of blink is Hard.  This means that if user gestures fundamentally have to be linked to a frame (which I think is one of the cruxes of User Activation v2?), we'll run into issues.

My guess is that what we may have to do here is delegate out the determination of user gesture (in the extension bindings system, most of these delegations are through callbacks).  Then, we can use ScriptContext with a render frame in most (production) cases, but stub it out for testing.  That will require a little bit more plumbing, but is the only way I can think of to handle this properly.

jbroman@ knows the blink side of things better than I do, and might have more thoughts here.

WebLocalFrame::FrameForContext naturally won't work for contexts that aren't owned by frames (IIRC extensions can also run in a service worker context?). Otherwise I don't have much to offer beyond what Devlin has said.

Service workers seems unrelated to user activation since they remain in the background and doesn't own any DOM shown to users (right?).  So an undefined Frame is acceptable in this case.

I don't know; is there any way to pass a user gesture up to a worker and then back to a frame?

In UserActivation v2, we are getting rid of the token passing altogether which gives a simple design yet easily solves many related problems (e.g. Issue 404161 and Issue 760848).

One thing I just observed is that all extension tests are passing with v2 enabled, which means not passing a frame here seems fine!  Let me double-check this.

That's surprising.  I certainly wouldn't think that we have no tests that exercise user gestures in extension functions.  If no frame is passed to IsProcessingUserGestureThreadSafe(), what's the behavior?  (From my reading of the code, it looks like it would always return false?)

Seems I was not quite correct.  We previously landed a fix in MessagingApiTest.MessagingUserGesture which is used by both:
  JavaScriptBindings/MessagingApiTest.MessagingUserGesture/0 and
  NativeBindings/MessagingApiTest.MessagingUserGesture/0 .
That fix works fine in the first test but not the second one!

Any chance the code in #c4 is about native binding (and not JS binding)?

Yes, the code in #4 is only used with native bindings enabled.

We have at least one browser test still failing because of this:
NativeBindings/MessagingApiTest.MessagingUserGesture/0

We need to find a solution here to launch UAv2.  See blocked  Issue 860509  for broken cases we found through our field trial.

- We have 14 tests blocked by this problem, see  Issue 860509 #c18.

- This test failure look isolated, doesn't call Request(): NativeBindings/MessagingApiTest.MessagingUserGesture/0.

The solution I tried before (#c4 above) now works for 13 of the 14 failing tests. 
 Yayy!  I tried both with and without NativeCrxBindings.  (However, not sure what change on the extension side caused this to work now vs in the past.)

I will send a CL out for review now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6b20212bdffccd581703de1f229921151ea4750b

commit 6b20212bdffccd581703de1f229921151ea4750b
Author: Mustaq Ahmed <mustaq@google.com>
Date: Fri Sep 14 16:55:25 2018

Fixed UserActivationV2 handling in APIRequestHandler::StartRequest.

Bug:  778769 
Change-Id: I8404561578d76a33032a21f050150d35ac0bd553
Reviewed-on: https://chromium-review.googlesource.com/1194336
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#591376}
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/bindings/api_binding_test_util.cc
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/bindings/api_binding_test_util.h
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/bindings/api_binding_unittest.cc
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/bindings/api_bindings_system.cc
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/bindings/api_bindings_system.h
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/bindings/api_bindings_system_unittest.cc
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/bindings/api_request_handler.cc
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/bindings/api_request_handler.h
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/bindings/api_request_handler_unittest.cc
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/bindings/declarative_event_unittest.cc
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/native_extension_bindings_system.cc
[modify] https://crrev.com/6b20212bdffccd581703de1f229921151ea4750b/extensions/renderer/native_extension_bindings_system.h