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

commit 88fcb3a6899d77b64195423333ad81a00803f997
Author: Mustaq Ahmed <mustaq@google.com>
Date: Wed Feb 14 16:20:06 2018

Move user activation check to RemoteFrame::Navigate's callers.

Currently RemoteFrame::Navigate is the user of
Frame::HasTransientUserActivation that passes a RemoteFrame*, and
it seems wrong because the user activation (user gesture) needed by
the navigation should belong to the LocalFrame that initiated the
navigation.

Follow-up CLs after this one will update UserActivation code in
Frame to take a LocalFrame* instead of a Frame*, and get rid of
redundant IPCs.

Bug:  811414 
Change-Id: I771c1694043edb54374a44213d16715d9c7da704
Reviewed-on: https://chromium-review.googlesource.com/914736
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536728}
[modify] https://crrev.com/88fcb3a6899d77b64195423333ad81a00803f997/third_party/WebKit/Source/core/frame/RemoteFrame.cpp
[modify] https://crrev.com/88fcb3a6899d77b64195423333ad81a00803f997/third_party/WebKit/Source/core/html/forms/HTMLFormElement.cpp
[modify] https://crrev.com/88fcb3a6899d77b64195423333ad81a00803f997/third_party/WebKit/Source/core/page/DragController.cpp

Looks like we have two other users of RemoteFrame's user activation:

[A] WebFrame::Swap() which seems like an indirect user (merely a setter):
  https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/exported/WebFrame.cpp?rcl=0f8cefda01ab4f2281e11da181d863a342ebc51d&l=129

[B] AutoplayPolicy's HasBeenActivated() checks all ancestor frames of a given LocalFrame, which contradicts the assumption we made for subframe visibility of UserActivationV2.  Yikes!
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/media/AutoplayPolicy.cpp?rcl=226e3d9e2242c82571ee6f5a7c1a0319cf1a90af&l=79

mlamouri@:  What am I missing for [B]?  May be this is V1 specific?

Oh, just realized re [B] that this is about sticky frame state so old vs new UserActivation doesn't make a difference.  Also the ancestry check is because of that particular FP.

Re the use of RemoteFrame in [B], I see in the design doc link below that the goal is to check all ancestor frames:
https://docs.google.com/document/d/1EH7qZatVnTXsBGvQc_53R97Z0xqm6zRblKg3eVmNp30/edit#heading=h.l5cxp223oy0l
so just checking the state in an ancestor RemoteFrame doesn't help because if that RemoteFrame's corresponding LocalFrame had seen a user gesture, the info didn't reach the RemoteFrame.  In other words, this is not ready for OOPIFs.

Here is an informed explanation of [B]: it relies on replication of a LocalFrame's user activation state to all corresponding RemoteFrames.
https://cs.chromium.org/chromium/src/content/browser/frame_host/render_frame_host_manager.cc?rcl=980bc8e740e7aa845a18f18f0f2cdf5f4ce4c45c&l=758

This "expensive" replication, triggered through Frame::NotifyUserActivation makes reading the states easy, w/o hopping back to browser process.

While this is correct, it could be worse for UserActivationV2 for more involved tree state update, so we will switch to "easy write" and "expensive read".  I will outline the details in a design doc.

The crack we currently have with autoplay feature policy will be fixed through  Issue 780556 , without removing RemoteFrame states.

We need no more cleanups here.  See the design doc in  Issue 780556 : we have a design for v2 state propagation across frames where RemoteFrame states serve as a cache to ease state "reading" cost.