chrome/browser/ui: Remove use of MessageLoopProxy and deprecated MessageLoop APIs

chrome/browser/ui/webui/local_discovery/local_discovery_ui_browsertest.cc

Index: chrome/browser/ui/webui/local_discovery/local_discovery_ui_browsertest.cc
diff --git a/chrome/browser/ui/webui/local_discovery/local_discovery_ui_browsertest.cc b/chrome/browser/ui/webui/local_discovery/local_discovery_ui_browsertest.cc
index 049c95a47d50e3103e6a6d559377bfb607e98adb..9f9ba86c14c5fa720bcef9058a40ab9eafd85b83 100644
--- a/chrome/browser/ui/webui/local_discovery/local_discovery_ui_browsertest.cc
+++ b/chrome/browser/ui/webui/local_discovery/local_discovery_ui_browsertest.cc
@@ -7,8 +7,10 @@
 #include "base/callback.h"
 #include "base/command_line.h"
 #include "base/compiler_specific.h"
+#include "base/location.h"
 #include "base/memory/scoped_ptr.h"
-#include "base/message_loop/message_loop.h"
+#include "base/single_thread_task_runner.h"
+#include "base/thread_task_runner_handle.h"
 #include "chrome/browser/local_discovery/test_service_discovery_client.h"
 #include "chrome/browser/profiles/profile.h"
 #include "chrome/browser/signin/profile_oauth2_token_service_factory.h"
@@ -441,7 +443,7 @@ class LocalDiscoveryUITest : public WebUIBrowserTest {
     base::CancelableCallback<void()> callback(base::Bind(
         &base::MessageLoop::Quit, base::Unretained(

[msw, 2015/06/10 00:12:58]

Is this and base::MessageLoop::current() here and below still correct?
(keep the message_loop.h include if needed)

[Sami, 2015/06/10 12:35:34]

Yes, both MessageLoop::current and ThreadTaskRunnerHandle::Get point to the same
task queue.
Hmm, yes, looks like we still need it for all the MessageLoop references here. A
checked all the the other modified files too and fixed 5 instances where we need
to keep message_loop.h.

[msw, 2015/06/10 19:34:00]

Again, it seems odd to use inconsistent terminology and access points to work
with the same logical elements (posting MessageLoop::Quit for the
MessageLoop::current() to the SingleThreadTaskRunner held by
ThreadTaskRunnerHandle, then calling MessageLoop::current()->Run()). This new
code is more confusing than the old code (posting the same task to
MessageLoop::current()), and I feel like this isn't the only example. I hope
this refactoring doesn't leave us in a more confusing world... What is the plan
to fix cases like this? Can't we bind Quit() and call Run() on the
SingleThreadTaskRunner? Or should this instead use
MessageLoop::current()->task_runner()->PostDelayedTask()?

             base::MessageLoop::current())));
-    base::MessageLoop::current()->PostDelayedTask(
+    base::ThreadTaskRunnerHandle::Get()->PostDelayedTask(
         FROM_HERE, callback.callback(), time_period);
 
     base::MessageLoop::current()->Run();