Let pyauto create an attached webdriver instance to manipulate web pages.

chrome/browser/automation/automation_provider.cc

Index: chrome/browser/automation/automation_provider.cc
diff --git a/chrome/browser/automation/automation_provider.cc b/chrome/browser/automation/automation_provider.cc
index 1e25d61403b85241aa0617c64ebf011f19276364..1ba30c931855bed26ef67b3f0c38d38de888260d 100644
--- a/chrome/browser/automation/automation_provider.cc
+++ b/chrome/browser/automation/automation_provider.cc
@@ -156,6 +156,7 @@ bool AutomationProvider::InitializeChannel(const std::string& channel_id) {
     automation_resource_message_filter_ = new AutomationResourceMessageFilter;
   }
 
+  base::ThreadRestrictions::ScopedAllowIO allow_io;

[Paweł Hajdan Jr., 2011/07/29 20:48:38]

Let's do it on the right thread. Who knows what races we might create otherwise.

[kkania, 2011/07/29 22:44:19]

I believe it is on the right thread.

This is only needed on POSIX when creating a MODE_NAMED_SERVER channel. When
creating a NAMED_SERVER channel, ipc_channel_posix.cc calls
file_util::CreateDirectory to ensure the channel name (which is a path), has a
parent dir. Usually an IPC::Channel is initialized only on the IO thread, so
this is fine. However, when using a ChannelProxy in SERVER mode, the channel is
created immediately to avoid a race (see ChannelProxy::Init). Thus, we end up
calling file_util on the UI thread in normal conditions. There's only 1 other
use of MODE_NAMED_SERVER, which is not in the browser process and looks like it
doesn't have any thread restrictions.

So here, I do not think this is a race. It is just a case of doing IO on the UI
thread, which you should avoid. If you agree, I see three options:
1) keep this here and comment
2) move this allow IO to ChannelProxy::Init when creating a channel immediately
3) change the IPC code to, in the case of a NAMED_SERVER, not create the channel
immediately, since this requires possibly creating a directory on POSIX

We already do ScopedAllowIO in AutomationProvider::ReinitializeChannel, as dtu
points out below, for I assume the same reason.

[Paweł Hajdan Jr., 2011/07/30 00:03:03]

Then you shouldn't need ScopedAllowIO here.
No, comment is not a fix.
I believe it's too risky, but I'm fine if ipc/ OWNERS are fine with that.
Hmm, or how about just doing the thing on the right thread?
Bleh, existing code that's bad is no excuse. Ideally we should fix both. I'd
like that. :-D

   channel_.reset(new IPC::ChannelProxy(
       effective_channel_id,
       GetChannelMode(use_named_interface),