cros: Replace BrowserThread::FILE in InputServiceProxy

chrome/browser/chromeos/login/bluetooth_host_pairing_browsertest.cc

Index: chrome/browser/chromeos/login/bluetooth_host_pairing_browsertest.cc
diff --git a/chrome/browser/chromeos/login/bluetooth_host_pairing_browsertest.cc b/chrome/browser/chromeos/login/bluetooth_host_pairing_browsertest.cc
index f86c942311dd625619be3cdb9ba3aab3e14ae292..c662be27af8e349bf4e5f3337b1154ce102623b6 100644
--- a/chrome/browser/chromeos/login/bluetooth_host_pairing_browsertest.cc
+++ b/chrome/browser/chromeos/login/bluetooth_host_pairing_browsertest.cc
@@ -67,7 +67,7 @@ class BluetoothHostPairingNoInputTest : public OobeBaseTest {
   using InputDeviceInfo = device::InputServiceLinux::InputDeviceInfo;
 
   BluetoothHostPairingNoInputTest() {
-    InputServiceProxy::SetThreadIdForTesting(content::BrowserThread::UI);
+    InputServiceProxy::SetUseUIThreadForTesting(true);

[achuithb, 2017/06/19 22:34:42]

Do you know why we use the UI thread here (and in the other browser test)
instead of a blocking thread? 

[xiyuan, 2017/06/19 23:00:26]

I did not look closely. Think it makes it easier to manipulate fake devices in
tests. InputDeviceLinux can only be accessed from one thread. This call
essentially creates InputDeviceLinux on the UI thread. Then test can call
AddDeviceForTesting directly without the need to ping-pong with a background
thread.

[achuithb, 2017/06/20 08:36:48]

Ok, I'm just wondering if we can get away from using this on the UI thread at
some point and just massaging the test. But it's not really important for the
purpose of this CL (which is to migrate away from BrowserThread::FILE).

     device::InputServiceLinux::SetForTesting(
         base::MakeUnique<device::FakeInputServiceLinux>());