Omnibox - Mark As Duplicates URLs that only differ by a trailing slash

components/omnibox/autocomplete_match.cc

Index: components/omnibox/autocomplete_match.cc
diff --git a/components/omnibox/autocomplete_match.cc b/components/omnibox/autocomplete_match.cc
index d19f8e9b56031961555e2f2db05fc075080bfaa3..242caf71fd5570fd1075254aa3a5b9b98a1d99fa 100644
--- a/components/omnibox/autocomplete_match.cc
+++ b/components/omnibox/autocomplete_match.cc
@@ -415,6 +415,16 @@ GURL AutocompleteMatch::GURLToStrippedGURL(
     needs_replacement = true;
   }
 
+  // Add a trailing slash if the path does not have one.

[Peter Kasting, 2015/06/11 23:05:37]

Nit: I might add "It's OK if this adds a slash even where one would be
inappropriate if we were really going to navigate to this URL, e.g.
"foo.com/index.html/"."

[Mark P, 2015/06/12 17:25:57]

Done.  (I thought it was clear from preexisting comments that we never use the
stripped_destination_url as a destination as it may often be non-navigable. 
Nonetheless, added this comment here because it cannot hurt.)

[Peter Kasting, 2015/06/12 17:49:04]

It's clear we're not going to navigate there -- but the other changes at least
look like plausible sorts of transforms to the URL, whereas appending a slash
sometimes makes no sense at all (except in terms of dupe elimination).

For this reason I'd actually prefer to always strip the slash than always add
one.  That's a more plausible-looking transform and I don't think would need an
extra comment.  The only reason I didn't suggest this is that you can't strip
the slash if it's the only thing in the path, and I was worried that the
inconsistency there might be confusing.

But if you think you could feasibly remove slashes (except for lone ones) as
easily as add them, I'd go with that.  It has the added bonus that you won't
have to allocate space for a new string and copy the existing path, too (yay
efficiency).

[Mark P, 2015/06/12 18:04:59]

I think the problem with lone slashes cannot be easily fixed.  I too wanted to
strip
the slash rather than add one, but thought of the lone slash issue.  I could fix
that issue by not stripping lone slashes, but I think the "path non-empty"
restriction only applies to certain types of URLs (http and the like), not all
kinds.
Indeed, that's why I asked on the bug whether you wanted to do this for all
protocols.  Given that you said yes, I thought adding the "/" was the safer,
better
thing to do.

[Peter Kasting, 2015/06/12 18:25:37]

Well, just because another protocol may allow an empty path doesn't mean that
having a slash in that case would be unsafe or break anything.

The logic could be something like this:

if (!path.empty() && path.back() == '/')
  strip slash;
if (path.empty())
  path = '/';

This ensures no paths have trailing slashes except the empty path, and also
ensures that "" and "/" both get transformed to "/".  (You could easily write a
single-conditional form of the logic that guaranteed the first condition, but
not the second.)

I think that would be fine for all protocols.

+  const std::string& path = stripped_destination_url.path();
+  // |path_with_extra_slash| lives at this scope rather than inside the if
+  // statement because it has to live until the ReplaceComponents() call below.
+  std::string path_with_extra_slash(path + '/');
+  if (path.empty() || (path.back() != '/')) {
+    replacements.SetPathStr(base::StringPiece(path_with_extra_slash));
+    needs_replacement = true;
+  }
+
   // Replace https protocol with http protocol.
   if (stripped_destination_url.SchemeIs(url::kHttpsScheme)) {
     replacements.SetScheme(url::kHttpScheme,