cc'd dfried as a heads-up - this'll add additional metrics to determine tab handling behavior.

One thing I'll flag -- I was looking at the data the other day and saw a very high count of users looking at their 100+th spoke, which seems more likely a bug than reality. Possibly the counter isn't being re-set at some point?

(Let me know if I should split this into a separate bug.)

Is there documentation on this system so we can better understand how it works?

Also, let's make sure we coordinate with the folks working on tab groups so that we can capture tab group data as part of this process.

We were talking about this the other day, and revisited the code. The logic seems to be correct and we do have good code coverage unit-tests.

We're agreed that 100+th spoke is not realistic, since we did not persists anything. It does not seem to be real, if users do 100+ back and forth in a single life cycle.

wychen@ is suspected that the high number of spoke might be caused by some auto-bots. 

So there are two abnormalities in the current data:

For spoke #s that are high but <99, it is still weird to be seeing spokes on the order of 90s in the wild. And I think wychen@'s guess here about those being caused by bots is high likely to be true.

For 99 and especially, the logic is setup so that the numbers are monotonically increasing, so any errors we see around counters not being reset would be across all values rather than 100 only. 100 count being high is still a mystery, but I feel like this is related with something going wrong in our calls that collect the histogram data, rather than the count computation logic.

dfried@, I don't think we have a doc that explains the counting logic, but we should have one that describes the histograms in question here.

To quickly summarize the reasoning from starting here, this bug is more around hub and spoke usage (pogo sticking is another term for it I think) that is a back and forth navigation pattern that opens multiple pages from a hub while pruning the old navigations. We have others around tabgroup-like usage on Android that wouldn't be ready to carry to other platforms. So this looked like a good place to start.

@dfried: I've added you since your team is "the folks working on tab groups" :)

Coordination is left as an exercise for the reader ;)

Adding bsep@ who is currently the lead on tab groups, as well as tbergquist@ who wrote the design for tab scrolling, and corising@ who is spearheading hover cards.

I suspect they will all want a lot more detail on this before we merge the changes :)

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

commit 2efb9d1307eb78ac02f68c9c34ff389a655a2713
Author: Mei Liang <meiliang@chromium.org>
Date: Wed Jan 16 05:39:28 2019

[task_tab_helper] Attach TaskTabHelper to all platforms

TaskTabHelper is used to aggregate and record HubAndSpokeNavigationUsage
histograms.

Bug: 918938
Change-Id: Ia656e00832daeb402a2216ba6f5d241640331eb1
Reviewed-on: https://chromium-review.googlesource.com/c/1405703
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Bret Sepulveda <bsep@chromium.org>
Commit-Queue: Mei Liang <meiliang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623123}
[modify] https://crrev.com/2efb9d1307eb78ac02f68c9c34ff389a655a2713/chrome/browser/BUILD.gn
[rename] https://crrev.com/2efb9d1307eb78ac02f68c9c34ff389a655a2713/chrome/browser/complex_tasks/OWNERS
[rename] https://crrev.com/2efb9d1307eb78ac02f68c9c34ff389a655a2713/chrome/browser/complex_tasks/task_tab_helper.cc
[rename] https://crrev.com/2efb9d1307eb78ac02f68c9c34ff389a655a2713/chrome/browser/complex_tasks/task_tab_helper.h
[rename] https://crrev.com/2efb9d1307eb78ac02f68c9c34ff389a655a2713/chrome/browser/complex_tasks/task_tab_helper_unittest.cc
[modify] https://crrev.com/2efb9d1307eb78ac02f68c9c34ff389a655a2713/chrome/browser/ui/tab_helpers.cc
[modify] https://crrev.com/2efb9d1307eb78ac02f68c9c34ff389a655a2713/chrome/test/BUILD.gn