NTPResourceCache don't add substitution for colorSectionBorder twice

chrome/browser/ui/webui/ntp/ntp_resource_cache.cc

Index: chrome/browser/ui/webui/ntp/ntp_resource_cache.cc
diff --git a/chrome/browser/ui/webui/ntp/ntp_resource_cache.cc b/chrome/browser/ui/webui/ntp/ntp_resource_cache.cc
index 21df0d4bdfc38284e786976630d3262ad46bebf0..29b4b89327c45a7b8ece814c4e6520e8eef0bf3e 100644
--- a/chrome/browser/ui/webui/ntp/ntp_resource_cache.cc
+++ b/chrome/browser/ui/webui/ntp/ntp_resource_cache.cc
@@ -579,8 +579,6 @@ void NTPResourceCache::CreateNewTabCSS() {
   substitutions["colorSectionBorder"] =
       SkColorToRGBAString(color_section_border);
   substitutions["colorTextLight"] = SkColorToRGBAString(color_text_light);
-  substitutions["colorSectionBorder"] =
-      SkColorToRGBComponents(color_section_border);

[Peter Kasting, 2016/10/27 22:29:10]

The first addition was as a string, this one as components.  Is it clear the
first one is the correct one?

[hans, 2016/10/27 22:44:38]

Hmm, you're right. I was assuming an RGBA string and components would be
functionally equivalent, but I don't really know that of course. The more
defensive thing would be to remove the first addition.

I'd like to hear what dschuyler thinks.

[dschuyler, 2016/10/27 23:07:34]

I think that I didn't notice that there were two
places that color_selection_border was being set previously. My apologies.

https://codereview.chromium.org/1220793010/diff/490001/chrome/browser/ui/webu...

When I ported the code to 'the new way', it brought that weird aspect forward.
IMO, the safer thing to do would be to keep the latter entry. That (I
believe) is the one that is currently active - it will have been 
stomping the former entry.

[hans, 2016/10/27 23:13:07]

Sounds good to me. New patch uploaded.

   substitutions["colorText"] = SkColorToRGBComponents(color_text);
 
   // For themes that right-align the background, we flip the attribution to the