Actually, it isn't clear for me what's expected here.

In my investigation, it's always false on all kind of reloads from UI for mobiles and desktops.

When should it be true?

This question comes from a code review; https://codereview.chromium.org/2028953002/

Let me set the Android bit.
I do not have a confidence, but some code exist inside #if defined(OS_ANDROID).

Let me CC some members who may know about the flag well or who reviews my CL.

Hum... actually, mail thread might be better than crbug.com entry, but anyway.

Let me copy and paste useful comments by Bryan from the codereview.


Here's code on the Java side that handles the pull to refresh gesture:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/android/jav...

This calls through to NavigationControllerImpl::ReloadToRefreshContent on the
C++ side, which drives a reload navigation which eventually creates a
NavigationRequest via NavigationRequest::CreateBrowserInitiated:
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr...

CreateBrowserInitiated initializes has_user_gesture to false:
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/fr...

It appears that has_user_gesture can only be set to true for renderer-initiated
navigations in the current implementation, in
NavigationRequest::CreateRendererInitiated.

NavigationRequest is only used in PlzNavigate. For the current architecture, you want to look at how it is set in RenderFrameImpl.

That said, ultimately the behavior is the same between the current implementation and PlzNavigate. I think it would make more sense to have the has user gesture set to true for browser-initiated navigations as well. Currently what we're doing in several places in content/ is treating browser-initiated navigations as having a user gesture. It'd be simpler if the user gesture is properly set in the first place.

Change the summary and set status to Available.
Charles looks starting a project that may need this fixed?

Yeah my plan was to do as clamy@ suggested and just assume all browser-initiated navigations were user initiated. I can take ownership of this bug and actually set the bit appropriately.

clamy@, do you have any ideas about how to deal with prerender? I think most prerenders can be considered as having a user gesture, but not necessarily link rel=prerender.

qinmin@, can you confirm that if we implement this then we can remove all the android specific code added here:
https://codereview.chromium.org/1243253004/

clamy@, I was planning on moving the user gesture bit to the CommonNavigationParams, and follow a similar path to the navigation_start timestamp. 

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

commit 386a541edc81f7e9302009e0122e07a467754767
Author: bmcquade <bmcquade@chromium.org>
Date: Fri Nov 11 14:32:01 2016

Improve tracking of user initiated page loads.

* consider all browser initiated navs to be user initiated
* get rid of special case tracking of user initiated aborts

BUG=617904

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

[modify] https://crrev.com/386a541edc81f7e9302009e0122e07a467754767/chrome/browser/page_load_metrics/metrics_web_contents_observer.cc
[modify] https://crrev.com/386a541edc81f7e9302009e0122e07a467754767/chrome/browser/page_load_metrics/observers/aborts_page_load_metrics_observer.cc
[modify] https://crrev.com/386a541edc81f7e9302009e0122e07a467754767/chrome/browser/page_load_metrics/observers/core_page_load_metrics_observer.cc
[modify] https://crrev.com/386a541edc81f7e9302009e0122e07a467754767/chrome/browser/page_load_metrics/observers/core_page_load_metrics_observer.h
[modify] https://crrev.com/386a541edc81f7e9302009e0122e07a467754767/chrome/browser/page_load_metrics/page_load_metrics_observer.cc
[modify] https://crrev.com/386a541edc81f7e9302009e0122e07a467754767/chrome/browser/page_load_metrics/page_load_metrics_observer.h
[modify] https://crrev.com/386a541edc81f7e9302009e0122e07a467754767/chrome/browser/page_load_metrics/page_load_tracker.cc
[modify] https://crrev.com/386a541edc81f7e9302009e0122e07a467754767/chrome/browser/page_load_metrics/page_load_tracker.h

Moving bmcquade to owner.

I've been working on a longstanding UI feature request ( Issue 575305 ) and ran into the problem that NavigationHandle::HasUserGesture always returns false for browser-initiated navigations, regardless of whether --enable-browser-side-navigation is specified.

At this point I'm blocked on having this flag working properly, so could I either take over this bug, or could it be prioritized and implemented both for the current navigation flow as well as PlzNavigate?

Thanks.

My focus was on addressing this for page load metrics specifically.

To fix the issue in content more generally, you'd want to work with clamy@.

Reassigning to clamy@ to investigate addressing this in content generally.

From a brief email with jam@ it sounds very difficult if not impossible to do this for non-PlzNavigate, and trivial to do with PlzNavigate. So it's OK from my standpoint to wait until PlzNavigate ships in order to ensure that this flag is set correctly.

#14: it is very simple to do with PlzNavigate. In fact this is what we wanted to do from the start in PlzNavigate, since it makes more sense, but we had to match the existing behavior.

Maybe we should do it early in the M61 milestone, so we can discover any potential issues early on and not add more uncertainty closer to branch point?

Now that PlzNavigate has shipped, can we make progress on this issue? Once again blocking a bug that needs the HasUserGesture flag set for user- and browser-initiated navigations on this one.

Actually, clamy@'s suggestion to look for browser-initiated navigations worked to unblock  Issue 575305 . Thanks.