Histogram the scheme of an origin on the 1st navigation to it.

chrome/browser/profiles/profile_io_data.h

Index: chrome/browser/profiles/profile_io_data.h
diff --git a/chrome/browser/profiles/profile_io_data.h b/chrome/browser/profiles/profile_io_data.h
index de32c6e55625485ddd56d647c6b6293c67844bb3..85a023c8914a9c2e35f9603b5d9a029ff97357f3 100644
--- a/chrome/browser/profiles/profile_io_data.h
+++ b/chrome/browser/profiles/profile_io_data.h
@@ -9,6 +9,7 @@
 
 #include <map>
 #include <memory>
+#include <set>
 #include <string>
 #include <vector>
 
@@ -204,6 +205,12 @@ class ProfileIOData {
 
   bool IsOffTheRecord() const;
 
+  // Used when deciding whether or not to record
+  // Navigation.SchemePerUniqueOrigin[OTR]. Inserts a copy of |origin| into the
+  // set |origins_seen_|, and returns whether or not |origin| was already in the
+  // set.
+  bool HaveAlreadySeenOrigin(const url::Origin& origin);
+
   IntegerPrefMember* incognito_availibility() const {
     return &incognito_availibility_pref_;
   }
@@ -598,6 +605,9 @@ class ProfileIOData {
 
   const Profile::ProfileType profile_type_;
 
+  // Used by |HaveAlreadySeenOrigin|.
+  std::set<url::Origin> origins_seen_;

[mmenke, 2016/04/08 20:42:29]

Not a huge fan of unbounded memory use - yes, it shouldn't be a huge amount, but
it all adds up, particularly if we're going to keep this around.  I'd be fine
with an LRUCache, or something.  Admittedly, that adds a bit of complexity. 
Open to other ideas.  I assume that just tracking [non-back/forward]
cross-process navigations isn't good enough for what you want.

[mmenke, 2016/04/08 20:45:06]

Also wondering, is this really want you want?  I'm curious if number of origins
is really better than portion of navigations to HTTP pages, for your purposes.

[palmer, 2016/04/08 21:52:02]

Yes, it is. Our goal is to show a verbose security state (e.g. "foo.com NOT
SECURE", "gmail.com SECURE") on a profile's first visit to the origin
(potentially, first visit within time interval T), and on subsequent visits show
non-verbose. The purpose of this CL is to estimate how often people would
experience the verbosity, and to see if that measurement differs in OTR vs.
normal.

For portion of portion of navigations to HTTP pages, indeed,
Navigation.MainFrameScheme[DifferentPage] already does suffice, and we use it
for that. But, here we aim to measure something slightly different.

[palmer, 2016/04/08 21:52:02]

I feel that unbounded memory concern, but it's correct for our goals. An LRU
cache might suffice if the cache size were set high enough; I'll defer to felt
for a judgement on that. Seems to me like we should be able to pick a decent
size.

Do we have an LRU set class on hand? If not, I'd kind of enjoy writing one...
Right.

[mmenke, 2016/04/08 22:56:29]

Are we thinking the feature itself would work similarly, or are we just talking
histograms?  Also, if this histogram is going to only stay around for a couple
versions of Chrome, I'm less concerned about the design, but if it's going to be
a long term fixture, think we should spend some time thinking about it.
I thought we did when I made that comment, I'm less sure now.

[cbentzel, 2016/04/09 23:29:15]

Would base/containers/mru_cache.h suffice (not a set, but...)

+
   DISALLOW_COPY_AND_ASSIGN(ProfileIOData);
 };