Fix content shell layout test failure related to Fontconfig

ui/gfx/test/fontconfig_util_linux.cc

Index: ui/gfx/test/fontconfig_util_linux.cc
diff --git a/ui/gfx/test/fontconfig_util_linux.cc b/ui/gfx/test/fontconfig_util_linux.cc
index 6f2da0be9c94017b8ad1330d9f53927b35e3ecd2..1cb3a275b5fa35fb493e5880c25047d4be70ecb1 100644
--- a/ui/gfx/test/fontconfig_util_linux.cc
+++ b/ui/gfx/test/fontconfig_util_linux.cc
@@ -64,17 +64,8 @@ const char kFontconfigMatchPatternHeader[] = "  <match target=\"pattern\">\n";
 const char kFontconfigMatchFooter[] = "  </match>\n";
 
 void SetUpFontconfig() {
-  FcInit();
-
-  // A primer on undocumented FcConfig reference-counting:
-  //
-  // - FcConfigCreate() creates a config with a refcount of 1.
-  // - FcConfigReference() increments a config's refcount.
-  // - FcConfigDestroy() decrements a config's refcount, deallocating the
-  //   config when the count reaches 0.
-  // - FcConfigSetCurrent() calls FcConfigDestroy() on the old config, but
-  //   interestingly does not call FcConfigReference() on the new config.
-  CHECK(FcConfigSetCurrent(FcConfigCreate()));
+  CHECK(FcInit());
+  CHECK(FcConfigGetCurrent());

[Daniel Erat, 2016/06/27 22:40:15]

i think that the reason for the old code was to start out with an empty config.
does that happen with this approach, or do you end up with the user's local
config? the test failures suggest that the latter may be happening.

 }
 
 void TearDownFontconfig() {