+alexmos, who has been looking at user gesture indicators with OOPIFs.

Hmm, we should not be adding new TODOs around OOPIF support at this point, since we're very close to turning them on for stable channel.  (They're already on by default on Canary and Dev, and half of Beta.)

What would be broken until this TODO is fixed?

It would only be slightly more broken than what this bit is currently used for, but possibly enough that it's blocking.

The existing logic uses UserGestureIndicator::s_processedUserGestureSinceLoad, which is process-wide. So the current users would only be broken by the TODO in cases where you had a local iframe with a remote parent and a local grandparent, such that propagating up the frame tree would stop at a remote parent. That could be easily fixed to be only as broken as the existing logic. :)

The potential breakages would be:
* Android keyboard not appearing if first tap was in iframe
* Autofill not triggering on focus in iframe
* Not on trunk yet - iframes being incorrectly blocked from navigating top, though this would require at least a 4-deep FrameTree.

Let's please resolve this TODO and make it handle OOPIFs in a reasonable manner. We are shipping to enough users that adding TODOs in new code should not be the default action.

nasko, just to double-check: Do you want me to follow alexmos's suggestion on the bug (i.e., have it be no more broken than the existing implementation), or are you proposing blocking that change on fixing OOPIF's handling of user gestures?

s/bug/codereview in Comment #5

Let's have it no more broken that today, which is what alexmos@ suggested. Since we will have to fix user gesture indicator for OOPIFs generally, I don't think it makes sense for your CL to be blocked on that.

Comment 5-7: Agreed, not making it worse is sufficient.  Thanks!

I'll be working on resolving this for RemoteFrames ASAP, but just in case I go on leave before I finish...

core/dom/DocumentUserGestureToken.h calls setHasReceivedUserGesture() in the given Document and all its local ancestors. Fixing this for remote frames should be as simple as plumbing the setHasReceivedUserGesture call over to the correct LocalFrame(s) in other processes. I don't know whether it's preferable to transfer that state per-RemoteFrame, or whether a single message should be sent to the browser process for all frames that need propagation.

Out for review: https://codereview.chromium.org/2445193005/

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

commit 74e6d69671055f435029efa126168f4370cb5d5b
Author: japhet <japhet@chromium.org>
Date: Thu Oct 27 00:44:30 2016

Route setHasReceivedUserGesture() state for RemoteFrames

This also removes the ability to clear Document::m_hasReceivedUserGesture,
which was only used for an experiment that is behind a flag and probably
shouldn't be using it anyway.

BUG= 658800 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2445193005
Cr-Commit-Position: refs/heads/master@{#427893}

[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/content/browser/frame_host/render_frame_proxy_host.cc
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/content/browser/frame_host/render_frame_proxy_host.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/content/common/frame_messages.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/content/renderer/render_frame_impl.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/content/renderer/render_frame_proxy.cc
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/content/renderer/render_frame_proxy.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/core/dom/Document.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/core/dom/DocumentUserGestureToken.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/core/dom/DocumentUserGestureTokenTest.cpp
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/core/frame/Frame.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/core/frame/LocalFrame.cpp
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/core/frame/LocalFrame.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/core/frame/RemoteFrame.cpp
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/core/frame/RemoteFrame.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/core/frame/RemoteFrameClient.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/core/loader/FrameLoader.cpp
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/web/RemoteFrameClientImpl.cpp
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/web/RemoteFrameClientImpl.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/Source/web/WebLocalFrameImpl.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/public/web/WebLocalFrame.h
[modify] https://crrev.com/74e6d69671055f435029efa126168f4370cb5d5b/third_party/WebKit/public/web/WebRemoteFrameClient.h