gdata: Fix a bug that caused a deadlock when "Google Docs" is clicked

chrome/browser/chromeos/gdata/gdata_file_system.cc

Index: chrome/browser/chromeos/gdata/gdata_file_system.cc
diff --git a/chrome/browser/chromeos/gdata/gdata_file_system.cc b/chrome/browser/chromeos/gdata/gdata_file_system.cc
index eb7bdb5599d23bd058c4b3323de94155dc2f74a1..a8f6cc9483070d5e8a9d802932e950012d3409fe 100644
--- a/chrome/browser/chromeos/gdata/gdata_file_system.cc
+++ b/chrome/browser/chromeos/gdata/gdata_file_system.cc
@@ -524,9 +524,15 @@ void GDataFileSystem::FindFileByPathAsync(
     LoadFeedFromServer(search_file_path, callback);
     return;
   }
-  GDataFileSystem::FindFileByPathOnCallingThread(
-      search_file_path,
-      callback);
+
+  // Post a task to the same thread, rather than calling it here, as
+  // FindFileByPathAsync() is asynchronous.
+  base::MessageLoopProxy::current()->PostTask(

[Ben Chan, 2012/03/26 16:28:42]

Let's look into a better way to handle the lock business... preferably no lock
once after we clean up the thread interactions.

+      FROM_HERE,
+      base::Bind(&GDataFileSystem::FindFileByPathOnCallingThread,
+                 GetWeakPtrForCurrentThread(),
+                 search_file_path,
+                 callback));
 }
 
 void GDataFileSystem::FindFileByPathOnCallingThread(