Dispatch all WebDriverCommands on the session thread.

Break Session off into a separate Automation class, which is just focused on controlling Chrome. Have Session create its own thread which automation messages are executed on.
BUG=none
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=73670

[jleyba, 2011-01-28 00:22:04]

http://codereview.chromium.org/6306013/diff/40001/chrome/test/webdriver/dispa...
File chrome/test/webdriver/dispatch.cc (right):

http://codereview.chromium.org/6306013/diff/40001/chrome/test/webdriver/dispa...
chrome/test/webdriver/dispatch.cc:256:
response->set_status(kInternalServerError);
Use the SET_WEBDRIVER_ERROR from commands/response.h.

This will include the __FILE__ and __LINE__ info so user's can include that when
reporting bugs.

http://codereview.chromium.org/6306013/diff/40001/chrome/test/webdriver/sessi...
File chrome/test/webdriver/session.h (right):

http://codereview.chromium.org/6306013/diff/40001/chrome/test/webdriver/sessi...
chrome/test/webdriver/session.h:29: // of |Init|.
Can you expand this comment for why Init is the exception?

[kkania, 2011-01-28 22:34:57]

http://codereview.chromium.org/6306013/diff/40001/chrome/test/webdriver/dispa...
File chrome/test/webdriver/dispatch.cc (right):

http://codereview.chromium.org/6306013/diff/40001/chrome/test/webdriver/dispa...
chrome/test/webdriver/dispatch.cc:256:
response->set_status(kInternalServerError);
On 2011/01/28 00:22:04, jleyba wrote:
> Use the SET_WEBDRIVER_ERROR from commands/response.h.
> 
> This will include the __FILE__ and __LINE__ info so user's can include that
when
> reporting bugs.

Done.

http://codereview.chromium.org/6306013/diff/40001/chrome/test/webdriver/sessi...
File chrome/test/webdriver/session.h (right):

http://codereview.chromium.org/6306013/diff/40001/chrome/test/webdriver/sessi...
chrome/test/webdriver/session.h:29: // of |Init|.
On 2011/01/28 00:22:04, jleyba wrote:
> Can you expand this comment for why Init is the exception?

I removed this exception.

[jleyba, 2011-01-31 17:54:48]

Just two last comments, then LGTM

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
File chrome/test/webdriver/commands/command.h (right):

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
chrome/test/webdriver/commands/command.h:22: enum DispatchThreadType {
DispatchThreadType sounds redundant.  Can this just be "DispatchThread"?

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/sessi...
File chrome/test/webdriver/session_manager.h (right):

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/sessi...
chrome/test/webdriver/session_manager.h:45: base::Thread* thread;
This should be a member of Session.

[Joe, 2011-01-31 23:40:51]

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
File chrome/test/webdriver/commands/create_session.cc (right):

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
chrome/test/webdriver/commands/create_session.cc:33:
thread->message_loop_proxy()->PostTask(FROM_HERE, NewRunnableMethod(
Are you always guaranteed a valid message_loop_proxy if the thread is valid?
It seems you might dereference a NULL pointer so a check with a Debug statement
might be useful.

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
File chrome/test/webdriver/commands/response.h (right):

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
chrome/test/webdriver/commands/response.h:111: 
Can you remove this blank line

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/serve...
File chrome/test/webdriver/server.cc (right):

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/serve...
chrome/test/webdriver/server.cc:118: if (cmd_line.HasSwitch("root"))
Add a small comment explaining the purpose of "root"

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/serve...
chrome/test/webdriver/server.cc:132: mg_set_option(ctx, "root", root.c_str());
can you add an else statement stating that the root was not set

[kkania, 2011-02-01 01:54:47]

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
File chrome/test/webdriver/commands/command.h (right):

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
chrome/test/webdriver/commands/command.h:22: enum DispatchThreadType {
On 2011/01/31 17:54:48, jleyba wrote:
> DispatchThreadType sounds redundant.  Can this just be "DispatchThread"?

Done.

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
File chrome/test/webdriver/commands/create_session.cc (right):

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
chrome/test/webdriver/commands/create_session.cc:33:
thread->message_loop_proxy()->PostTask(FROM_HERE, NewRunnableMethod(
On 2011/01/31 23:40:51, Joe wrote:
> Are you always guaranteed a valid message_loop_proxy if the thread is valid?
> It seems you might dereference a NULL pointer so a check with a Debug
statement
> might be useful.

if the thread has started, which happens in SessionManager::Create, you will
always get a non-NULL here

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
File chrome/test/webdriver/commands/response.h (right):

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
chrome/test/webdriver/commands/response.h:111: 
On 2011/01/31 23:40:51, Joe wrote:
> Can you remove this blank line

Done.

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/serve...
File chrome/test/webdriver/server.cc (right):

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/serve...
chrome/test/webdriver/server.cc:118: if (cmd_line.HasSwitch("root"))
On 2011/01/31 23:40:51, Joe wrote:
> Add a small comment explaining the purpose of "root"

Done.

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/serve...
chrome/test/webdriver/server.cc:132: mg_set_option(ctx, "root", root.c_str());
On 2011/01/31 23:40:51, Joe wrote:
> can you add an else statement stating that the root was not set

Done.

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/sessi...
File chrome/test/webdriver/session_manager.h (right):

http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/sessi...
chrome/test/webdriver/session_manager.h:45: base::Thread* thread;
On 2011/01/31 17:54:48, jleyba wrote:
> This should be a member of Session.

Is there a strong reason why you see this as better fitting under Session?

I started with it under there because they have a 1:1 correspondence, but I like
the idea of creating a session on a session thread vs. creating a session which
creates a thread.

My idea is that Session should have all the fundamental methods to automate the
browser, and little else. Our Commands should convert the WebDriver JSON
interface into various calls on Session. For example, the ValueCommand should
parse the given string and call Session::SendKeyEvent for each appropriate key
in the given string. This leaves the option open of later creating a
ChromeSession and ChromeFrameSession, which both would inherit the Session
interface. For some methods in Session we would defer to the particular kind of
Session.

Also, if the Session does have the Thread, it forces us to call the Session
destructor on the request thread (because destructing the Thread causes the
calling thread to wait for it to join). This may cause us some problems with
shutting down with the automation proxy/UITestBase, but I don't know for sure.

[Joe, 2011-02-01 01:58:40]

LGTM, I am also fine with the session manager handling the threads

On 2011/02/01 01:54:47, kkania wrote:
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
> File chrome/test/webdriver/commands/command.h (right):
> 
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
> chrome/test/webdriver/commands/command.h:22: enum DispatchThreadType {
> On 2011/01/31 17:54:48, jleyba wrote:
> > DispatchThreadType sounds redundant.  Can this just be "DispatchThread"?
> 
> Done.
> 
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
> File chrome/test/webdriver/commands/create_session.cc (right):
> 
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
> chrome/test/webdriver/commands/create_session.cc:33:
> thread->message_loop_proxy()->PostTask(FROM_HERE, NewRunnableMethod(
> On 2011/01/31 23:40:51, Joe wrote:
> > Are you always guaranteed a valid message_loop_proxy if the thread is valid?
> > It seems you might dereference a NULL pointer so a check with a Debug
> statement
> > might be useful.
> 
> if the thread has started, which happens in SessionManager::Create, you will
> always get a non-NULL here
> 
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
> File chrome/test/webdriver/commands/response.h (right):
> 
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/comma...
> chrome/test/webdriver/commands/response.h:111: 
> On 2011/01/31 23:40:51, Joe wrote:
> > Can you remove this blank line
> 
> Done.
> 
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/serve...
> File chrome/test/webdriver/server.cc (right):
> 
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/serve...
> chrome/test/webdriver/server.cc:118: if (cmd_line.HasSwitch("root"))
> On 2011/01/31 23:40:51, Joe wrote:
> > Add a small comment explaining the purpose of "root"
> 
> Done.
> 
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/serve...
> chrome/test/webdriver/server.cc:132: mg_set_option(ctx, "root", root.c_str());
> On 2011/01/31 23:40:51, Joe wrote:
> > can you add an else statement stating that the root was not set
> 
> Done.
> 
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/sessi...
> File chrome/test/webdriver/session_manager.h (right):
> 
>
http://codereview.chromium.org/6306013/diff/63001/chrome/test/webdriver/sessi...
> chrome/test/webdriver/session_manager.h:45: base::Thread* thread;
> On 2011/01/31 17:54:48, jleyba wrote:
> > This should be a member of Session.
> 
> Is there a strong reason why you see this as better fitting under Session?
> 
> I started with it under there because they have a 1:1 correspondence, but I
like
> the idea of creating a session on a session thread vs. creating a session
which
> creates a thread.
> 
> My idea is that Session should have all the fundamental methods to automate
the
> browser, and little else. Our Commands should convert the WebDriver JSON
> interface into various calls on Session. For example, the ValueCommand should
> parse the given string and call Session::SendKeyEvent for each appropriate key
> in the given string. This leaves the option open of later creating a
> ChromeSession and ChromeFrameSession, which both would inherit the Session
> interface. For some methods in Session we would defer to the particular kind
of
> Session.
> 
> Also, if the Session does have the Thread, it forces us to call the Session
> destructor on the request thread (because destructing the Thread causes the
> calling thread to wait for it to join). This may cause us some problems with
> shutting down with the automation proxy/UITestBase, but I don't know for sure.

[jleyba, 2011-02-01 17:49:36]

http://codereview.chromium.org/6306013/diff/5003/chrome/test/webdriver/dispat...
File chrome/test/webdriver/dispatch.cc (right):

http://codereview.chromium.org/6306013/diff/5003/chrome/test/webdriver/dispat...
chrome/test/webdriver/dispatch.cc:271: thread->message_loop_proxy()->PostTask(
Suppose the server receives two requests:

DELETE /session/foo
GET /session/foo/url

The first command will delete the session and shutdown the AP (see
commands/session_with_id.h).  What happens with the second command if it has
already been posted to the session thread's message loop?  Ideally the server
should return a 404 since the session is no longer exists.

It would be great if we could cover this by a test.

[kkania, 2011-02-03 01:22:47]

sorry this has grown so big. I decided I didn't like the idea of dispatching
commands to different thread, so I made session handle its own thread. Commands
now live on the request thread. The part of session that controls the automation
proxy is broken off into a separate Automation class, which the session owns.
This is a nice separation of logic, but I also did it to make room for the
possibility of having a separate Automation for ChromeFrame.

I added the test case that you wanted and merged in ones from
webdriver_tests.py. Once this is committed I already have the infrastructure
ready to run these tests on the pyauto waterfall.

[kkania, 2011-02-03 03:53:18]

Remove the cleanup and test stuff from this CL.

[jleyba, 2011-02-03 19:01:22]

LGTM, just a few remaining comments.

http://codereview.chromium.org/6306013/diff/66022/chrome/test/webdriver/autom...
File chrome/test/webdriver/automation.cc (right):

http://codereview.chromium.org/6306013/diff/66022/chrome/test/webdriver/autom...
chrome/test/webdriver/automation.cc:56: *success =
tab_->ExecuteAndExtractString(wide_xpath, wide_script, &wide_result);
Line > 80

http://codereview.chromium.org/6306013/diff/66022/chrome/test/webdriver/autom...
chrome/test/webdriver/automation.cc:83: *url = gurl.possibly_invalid_spec();
If we get a URL from the tab, shouldn't it always be a valid URL spec?

[kkania, 2011-02-03 19:07:01]

http://codereview.chromium.org/6306013/diff/66022/chrome/test/webdriver/autom...
File chrome/test/webdriver/automation.cc (right):

http://codereview.chromium.org/6306013/diff/66022/chrome/test/webdriver/autom...
chrome/test/webdriver/automation.cc:56: *success =
tab_->ExecuteAndExtractString(wide_xpath, wide_script, &wide_result);
On 2011/02/03 19:01:22, jleyba wrote:
> Line > 80

Done.

http://codereview.chromium.org/6306013/diff/66022/chrome/test/webdriver/autom...
chrome/test/webdriver/automation.cc:83: *url = gurl.possibly_invalid_spec();
On 2011/02/03 19:01:22, jleyba wrote:
> If we get a URL from the tab, shouldn't it always be a valid URL spec?

probably, but I'm not sure. Some special pages may give us problems (like
about:blank)?  Instead of investigating if its ok, I thought to save time to
just return whatever it has and be safe.

[jleyba, 2011-02-03 19:07:45]

http://codereview.chromium.org/6306013/diff/66022/chrome/test/webdriver/autom...
File chrome/test/webdriver/automation.cc (right):

http://codereview.chromium.org/6306013/diff/66022/chrome/test/webdriver/autom...
chrome/test/webdriver/automation.cc:83: *url = gurl.possibly_invalid_spec();
On 2011/02/03 19:07:01, kkania wrote:
> On 2011/02/03 19:01:22, jleyba wrote:
> > If we get a URL from the tab, shouldn't it always be a valid URL spec?
> 
> probably, but I'm not sure. Some special pages may give us problems (like
> about:blank)?  Instead of investigating if its ok, I thought to save time to
> just return whatever it has and be safe.

SGTM