Good catch. Unfortunately it seems rather tricky to get right. I wouldn't be surprised if some other histograms had this problem as well (for various types of client side redirects like going back).

We may need to resort to heuristics for this one. If the subsequent navigation is initiated < X ms after the commit of the current navigation, we should mark the current navigation as being a client side redirect.

Time after commit, coupled with a check for (GetPageTransition() &  ui::PAGE_TRANSITION_CLIENT_REDIRECT) != 0 on the page being navigated to, seems like it could be a good heuristic. I'd be open to using a reasonably long time delay for this, such as any time in the first 500ms after commit, to make sure we filter out particularly slow cases. Maybe we could add UMA to get a better sense for what the threshold should be.

One challenge here is that it's difficult to distinguish between a redirect and a client-side navigation.

For example, if a page loads, the user reads the content, then some time much later the page navigates to a different page using a client-side navigation technique such as window.location='http://example.com/';, this shouldn't be considered a redirect.

Heuristically, if the page navigates before or around the time of first paint, it seems reasonable to classify that navigation as a client-side redirect.

It's unclear, though, what the threshold should be in terms of delay between first paint and navigation to classify the navigation as a client side redirect.

To start, I'd like to add UMA to measure the distribution of delays between first paint and client-side redirect. I'll put together a basic patch for this and send for review.

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

commit 37f1e97746ee9257aac5c353b6b264f61b5ed172
Author: bmcquade <bmcquade@chromium.org>
Date: Thu Jun 30 00:27:45 2016

Add a histogram for delay between first paint and client side redirects.

This will help us to choose a good heuristic value for distinguishing
client-side redirects from other client-side navigations.

BUG= 613634 

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

[modify] https://crrev.com/37f1e97746ee9257aac5c353b6b264f61b5ed172/components/page_load_metrics/browser/metrics_web_contents_observer.cc
[modify] https://crrev.com/37f1e97746ee9257aac5c353b6b264f61b5ed172/components/page_load_metrics/browser/metrics_web_contents_observer.h
[modify] https://crrev.com/37f1e97746ee9257aac5c353b6b264f61b5ed172/tools/metrics/histograms/histograms.xml

bmcquade@ : Could you please help with the steps to verify if it can be verified from TE end and if its fixed.

This is not yet fixed. The CL only added provisional data collecting to see how common this might be.

bmcquade@ : Thanks for the quick update, assuming this is not required to verify from TE end.

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

commit 09b1ee4df148f93c4a8f7f7f3d64a80a3479f0f1
Author: bmcquade <bmcquade@chromium.org>
Date: Tue Jul 19 02:26:21 2016

Split redirect delay metrics into separate histograms.

In https://codereview.chromium.org/2103153004/, a histogram was added
to track the time between a page painting, and initiating a client-side
redirect.

Additionally, a zero value was recorded in the following two cases:
* the page initiated a client-side redirect, then painted
* the page initiated a client-side redirect, but never painted

It turns out to be important to distinguish these cases. Distinguishing
these cases will let us understand how frequently a page may initiate a
redirect, paint, then have the redirect commit. In this case, we may want
to suppress the paint notification since it ends up being more of an
interstitial paint while navigating to the actual destination page, rather
than what we'd consider an actual first paint. In order to decide whether
we should add logic to suppress, this change separates the histogram into
two so we can understand how common this case is.

BUG= 613634 

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

[modify] https://crrev.com/09b1ee4df148f93c4a8f7f7f3d64a80a3479f0f1/components/page_load_metrics/browser/metrics_web_contents_observer.cc
[modify] https://crrev.com/09b1ee4df148f93c4a8f7f7f3d64a80a3479f0f1/tools/metrics/histograms/histograms.xml

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Archiving P3s older than 1 year with no owner or component.