While trying to fix a failing test, I discovered this top-frame navigation problem: it seems we wanted to disable top-frame navigation w/o an active user gesture:
https://www.chromestatus.com/feature/5851021045661696

But in reality we are relying on the sticky gesture bit (instead of "currently active" state) in Frame::CanNavigate():
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/Frame.cpp?rcl=5edc11d84b550e8b8eef08979a3cc7517000b939&l=175


Is this deliberate?  I would love to say "no" but the discussion we just had in a related intent (by csharrison@) implies this would be hard:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/kPli8ZCUeok/WgB3iRpJBAAJ


Does it look like a valid use of the "sticky" user activation state?  Do we know the original use-case/bug we wanted to address?

I think using the sticky bit was deliberate [1], japhet and ojan know for sure.

[1] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Xi8-y4ySjA4/Eb1sBWH8BQAJ PTAL at the end of the thread:

"FYI, Ojan and I have talked about this a bit more and agree that it makes sense to have this intervention be narrower than it is currently, given the amount of legitimate content it's breaking. The tentative plan is to allow navigating the top frame if the cross-origin iframe has *ever* processed a user gesture, instead of requiring it to *currently* be processing a user gesture. https://codereview.chromium.org/2392773002 is the work in progress for this."

Thanks Charlie, it makes sense now.  I will then focus on only hiding Frame::NotifyUserActivation.

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

commit d80ac2659ee658369e254c61898db67473c93cb2
Author: Mustaq Ahmed <mustaq@google.com>
Date: Wed Oct 25 13:39:49 2017

Hide Frame::NotifyUserActivation.

LocalDOMWindow was the only external caller of this method.  It seems
that making the UGI creation in PostMessageTimerFired conditional
shouldn't change anything since creating an UGI on null token is like
having no UGI at all.

Bug:  776508 
Change-Id: I099907f7fbae2e3b03173a002b553e328e492a9f
Reviewed-on: https://chromium-review.googlesource.com/729130
Commit-Queue: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Reviewed-by: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511437}
[modify] https://crrev.com/d80ac2659ee658369e254c61898db67473c93cb2/third_party/WebKit/Source/core/frame/Frame.h
[modify] https://crrev.com/d80ac2659ee658369e254c61898db67473c93cb2/third_party/WebKit/Source/core/frame/LocalDOMWindow.cpp

As per #c3, hiding NotifyUserActivation is all we can do here.  We shouldn't remove the update to sticky bit.  Marking the bug as WAI.

The intention was that a postMessage done in response to a user gesture would set the sticky bit in that iframe. *Not* that any postMessage would do so. I'm not sure from the description here which behavior we have.

What we do here is as follows:  at the moment LocalDOMWindow::PostMessageTimerFired is invoked (in response to a user gesture or not), the iframe would have the sticky bit set if there is an active user gesture (within the 1 sec expiry time).  So yes, this is not ideal for our existing model.

I marked it as WAI because we haven't seen any issues with it, and also because this non-ideal behavior is closer to what we plan for our UserActivation v2.