[NTP] Fix article suggestion clicks contributing to Most Visited tiles

components/history/core/browser/history_backend.cc

Index: components/history/core/browser/history_backend.cc
diff --git a/components/history/core/browser/history_backend.cc b/components/history/core/browser/history_backend.cc
index ff46dd8c34b1032a78050d742cfe70eacf79389e..aa9e51d406fb4731216110bcefb28bf99c4b13be 100644
--- a/components/history/core/browser/history_backend.cc
+++ b/components/history/core/browser/history_backend.cc
@@ -493,10 +493,22 @@ void HistoryBackend::AddPage(const HistoryAddPageArgs& request) {
   bool is_keyword_generated = ui::PageTransitionCoreTypeIs(
       request_transition, ui::PAGE_TRANSITION_KEYWORD_GENERATED);
 
+  bool has_redirects = request.redirects.size() > 1;
+
+  // data: scheme is sometimes used in combination with AUTO_BOOKMARK to fake a
+  // redirect as way to make sure it doesn't show up in most visited. Such
+  // entries should be ignored for the purpose of history (including omnibox
+  // autocomplete and most visited).
+  if (!has_redirects &&

[sky, 2016/09/14 18:01:51]

Wouldn't this mean the page won't show up in history at all?

[mastiz, 2016/09/14 18:10:18]

The article itself (redirectee) gets listed in history, but not the dummy
'data:' redirect, according to my testing on Android. I don't however fully
understand why this case doesn't get reported as a single navigation chain (i.e.
single call to AddPage()).

[sky, 2016/09/14 18:17:49]

I believe this change would make it so data urls are never added though, right?
That isn't the case today, which would mean for users that have data urls in top
sites they would no longer end up getting them (they would slowly expire).

[mastiz, 2016/09/14 18:22:02]

More specifically, data URLs with AUTO_BOOKMARK (note for example that clicks on
actual bookmarks are marked with LINK). Your point is still valid, but it should
be rare, and the server-side implementation of Chrome Suggestions discards such
scheme. WDYT?

[mastiz, 2016/09/14 18:40:47]

Also, would it be any better if we left FROM_ADDRESS_BAR cases unaffected?

+      ui::PageTransitionCoreTypeIs(request_transition,
+                                   ui::PAGE_TRANSITION_AUTO_BOOKMARK) &&
+      request.url.SchemeIs(url::kDataScheme)) {
+    return;
+  }
+
   // If the user is navigating to a not-previously-typed intranet hostname,
   // change the transition to TYPED so that the omnibox will learn that this is
   // a known host.
-  bool has_redirects = request.redirects.size() > 1;
   if (ui::PageTransitionIsMainFrame(request_transition) &&
       !ui::PageTransitionCoreTypeIs(request_transition,
                                     ui::PAGE_TRANSITION_TYPED) &&