Move persistent gesture state to Document, add DocumentUserGestureToken

third_party/WebKit/Source/core/loader/FrameLoader.cpp

Index: third_party/WebKit/Source/core/loader/FrameLoader.cpp
diff --git a/third_party/WebKit/Source/core/loader/FrameLoader.cpp b/third_party/WebKit/Source/core/loader/FrameLoader.cpp
index 983da54d2946b42c414fe22086963c0c496f1dbd..7ba56550c6e2e770195322252ca587a055f7fe84 100644
--- a/third_party/WebKit/Source/core/loader/FrameLoader.cpp
+++ b/third_party/WebKit/Source/core/loader/FrameLoader.cpp
@@ -395,7 +395,7 @@ void FrameLoader::setHistoryItemStateForCommit(
     HistoryNavigationType navigationType) {
   if (m_frame->settings()->historyEntryRequiresUserGesture() &&
       historyCommitType == StandardCommit)
-    UserGestureIndicator::clearProcessedUserGestureSinceLoad();
+    m_frame->document()->clearHasReceivedUserGesture();
 
   HistoryItem* oldItem = m_currentItem;
   if (isBackForwardLoadType(loadType) && m_provisionalItem)
@@ -784,8 +784,7 @@ void FrameLoader::updateForSameDocumentNavigation(
   if (!m_currentItem)
     historyCommitType = HistoryInertCommit;
   if (m_frame->settings()->historyEntryRequiresUserGesture() &&
-      !UserGestureIndicator::processedUserGestureSinceLoad() &&
-      initiatingDocument)
+      !m_frame->document()->hasReceivedUserGesture() && initiatingDocument)

[ojan, 2016/10/18 16:39:49]

What happens in this case?
1. Load a top-level page.
2. Click in an iframe.
3. The iframe gets navigated to a new URL at some point.
4. Navigate the top-level to a new URL.

I would expect to get at least one history entry (after #3), and maybe two (also
after #4)?

I think the safest thing would be having two entries as that matches what we
would do today, right?

I'm picturing a use case where someone is building a web browser type thing
where you click on links in the outer page to navigate the sub-frame, or you
click on links in one sub-frame to navigate another sub-frame. I don't know if
that case matters, but my gut feeling is that it makes sense to be a bit
conservative here.

In either case, we might want a test that covers this case.

[Nate Chapin, 2016/10/18 23:26:33]

Hrm. This should probably be using initiatingDocument for hasReceivedUserGesture
checks. That should solve the problem of gestures in one frame driving
navigations in another. Updated.

In general, on the question of 1 or 2 history entries: (3) definitely gets a
user gesture. (4) depends on how the top-level navigation triggers: it gets a
history entry if there was or is a user gesture since last commit and/or history
entry addition. Also, if there is no Document* specified as the initiator, that
means that the navigation is being triggered from a trusted source (e.g., the
address bar) and a history entry may be added.

Does that make sense?

[ojan, 2016/10/18 23:40:25]

Right. And that means it gets a history entry?
Right. Assuming no user gesture between 3 and 4, then it won't get a history
entry, right? I think we take on some risk here for the use case I was
describing. I think we might want to store a bit on Page as to whether that Page
has ever had a gesture and use that bit. Or, we can try this and see what
breaks. :)
I guess that seems reasonable.
Yup. If it's not a lot of work, I think a test is worth it, but if it's a lot of
work, don't worry about it.

     historyCommitType = HistoryInertCommit;
 
   setHistoryItemStateForCommit(
@@ -931,7 +930,7 @@ FrameLoadType FrameLoader::determineFrameLoadType(
     return FrameLoadTypeReload;
 
   if (m_frame->settings()->historyEntryRequiresUserGesture() &&
-      !UserGestureIndicator::processedUserGestureSinceLoad() &&
+      !m_frame->document()->hasReceivedUserGesture() &&
       request.originDocument())
     return FrameLoadTypeReplaceCurrentItem;