linux_aura: run IconLoader::ReadIcon on the UI thread.

chrome/browser/icon_loader_linux.cc

Index: chrome/browser/icon_loader_linux.cc
diff --git a/chrome/browser/icon_loader_linux.cc b/chrome/browser/icon_loader_linux.cc
index 2ee16ead8ddc2567f66433a6f09dd54959dc720f..1abf7d5104999c0565f989cbd0d3258f072f3ce9 100644
--- a/chrome/browser/icon_loader_linux.cc
+++ b/chrome/browser/icon_loader_linux.cc
@@ -24,10 +24,16 @@ IconGroupID IconLoader::ReadGroupIDFromFilepath(
   return base::nix::GetFileMimeType(filepath);
 }
 
+// static
 bool IconLoader::IsIconMutableFromFilepath(const base::FilePath&) {
   return false;
 }
 
+// static
+content::BrowserThread::ID IconLoader::ReadIconThreadID() {
+  return content::BrowserThread::FILE;

[Nico, 2014/03/11 16:26:19]

Isn't icon_loader_linux gtk too? Why would linux/aura need this but linux/gtk
wouldn't?

[davidben, 2014/03/11 16:37:13]

It's a little bizarre since linux/aura is more native than linux/gtk in this
regard.

The GTK port uses our own implementation of this, but it didn't actually work
(http://crbug.com/102211). I fixed it for Aura by having it just use the GTK
native implementation (which was too crashy originally or something?) and didn't
bother duplicating it for the GTK port. They aren't really arranged to easily be
able to share GTK code. That both fixed the problem and lets us remove our
reimplemented icon theme logic when the GTK port goes away...

...except that it introduced this threading problem.

+}
+
 void IconLoader::ReadIcon() {
   int size_pixels = 0;
   switch (icon_size_) {