Refactor automation messages.

Refactor automation messages.

automation_messages used to live in chrome/test/automation, when it's needed by
browser and chrome_frame. When I started lifting code out of headers and into
implementation files, I was getting link errors and temporarily solved the
problem by compiling the cc files manually into libbrowser.a. Now this is part
of chrome/common/ which is included by all targets needed.

While doing this, discover that automation IPC redefines the ContextMenuParams struct. Rename it to MiniContextMenuParams.

BUG=51409
TEST=none

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

[Elliot Glaysher, 2010-10-28 18:08:16]

Automation messages progressively get better. The history:

1) Everything is in a header. Everybody reaches into chrome/test/ to get access
to the automation messages.
2) The code is no longer all in a header. Each project includes the cc file
directly into their target.
3) Now everyone can just include chrome/common/ instead.

[Ben Goodger (Google), 2010-10-28 18:37:17]

http://codereview.chromium.org/4200007/diff/2002/10023
File chrome/common/DEPS (right):

http://codereview.chromium.org/4200007/diff/2002/10023#newcode28
chrome/common/DEPS:28: # (Also: the only thing used from these headers are
enums.
you don't close the paren. Did you mean to say more? You don't mention why
tab_contents is needed here.

http://codereview.chromium.org/4200007/diff/2002/10026
File chrome/common/automation_messages.h (right):

http://codereview.chromium.org/4200007/diff/2002/10026#newcode202
chrome/common/automation_messages.h:202: struct
ParamTraits<NavigationEntry::PageType> {
Do you have a plan for how to unravel this dependency given that it forces
common to depend on browser?

[Nirnimesh, 2010-10-28 18:43:29]

http://codereview.chromium.org/4200007/diff/2002/10022
File chrome/chrome_tests.gypi (right):

http://codereview.chromium.org/4200007/diff/2002/10022#newcode9
chrome/chrome_tests.gypi:9: 'common/pref_names.cc',
Please include chrome/common/automation_constants.h here

[Elliot Glaysher, 2010-10-28 18:57:07]

http://codereview.chromium.org/4200007/diff/2002/10022
File chrome/chrome_tests.gypi (right):

http://codereview.chromium.org/4200007/diff/2002/10022#newcode9
chrome/chrome_tests.gypi:9: 'common/pref_names.cc',
On 2010/10/28 18:43:30, Nirnimesh wrote:
> Please include chrome/common/automation_constants.h here

Done.

http://codereview.chromium.org/4200007/diff/2002/10026
File chrome/common/automation_messages.h (right):

http://codereview.chromium.org/4200007/diff/2002/10026#newcode202
chrome/common/automation_messages.h:202: struct
ParamTraits<NavigationEntry::PageType> {
On 2010/10/28 18:37:17, Ben Goodger wrote:
> Do you have a plan for how to unravel this dependency given that it forces
> common to depend on browser?

Beyond hoisting the enums into chrome/common/, I don't.

If you have any better ideas about where this code should live, I'm all ears. It
seems that it's problematic wherever I put it.

[Ben Goodger (Google), 2010-10-28 19:31:42]

Who uses these TabContents-specific automation messages and what for? How
does the CF integration relate?

In the long term, TabContents will become its own toplevel directory in
src/. My naive assertion is that TC related stuff should live together...
but I'd like to understand a bit more.

-Ben

On Thu, Oct 28, 2010 at 11:57 AM, <erg@chromium.org> wrote:

>
> http://codereview.chromium.org/4200007/diff/2002/10022
> File chrome/chrome_tests.gypi (right):
>
> http://codereview.chromium.org/4200007/diff/2002/10022#newcode9
> chrome/chrome_tests.gypi:9: 'common/pref_names.cc',
> On 2010/10/28 18:43:30, Nirnimesh wrote:
>
>> Please include chrome/common/automation_constants.h here
>>
>
> Done.
>
>
> http://codereview.chromium.org/4200007/diff/2002/10026
> File chrome/common/automation_messages.h (right):
>
> http://codereview.chromium.org/4200007/diff/2002/10026#newcode202
> chrome/common/automation_messages.h:202: struct
> ParamTraits<NavigationEntry::PageType> {
> On 2010/10/28 18:37:17, Ben Goodger wrote:
>
>> Do you have a plan for how to unravel this dependency given that it
>>
> forces
>
>> common to depend on browser?
>>
>
> Beyond hoisting the enums into chrome/common/, I don't.
>
> If you have any better ideas about where this code should live, I'm all
> ears. It seems that it's problematic wherever I put it.
>
>
> http://codereview.chromium.org/4200007/show
>

[Ben Goodger (Google), 2010-10-28 19:31:58]

On Thu, Oct 28, 2010 at 12:31 PM, Ben Goodger (Google) <ben@chromium.org>wrote:

> Who uses these TabContents-specific automation messages and what for? How
> does the CF integration relate?
>
> In the long term, TabContents will become its own toplevel directory in
> src/. My naive assertion is that TC related stuff should live together...
> but I'd like to understand a bit more.
>
> -Ben
>
>
> On Thu, Oct 28, 2010 at 11:57 AM, <erg@chromium.org> wrote:
>
>>
>> http://codereview.chromium.org/4200007/diff/2002/10022
>> File chrome/chrome_tests.gypi (right):
>>
>> http://codereview.chromium.org/4200007/diff/2002/10022#newcode9
>> chrome/chrome_tests.gypi:9: 'common/pref_names.cc',
>> On 2010/10/28 18:43:30, Nirnimesh wrote:
>>
>>> Please include chrome/common/automation_constants.h here
>>>
>>
>> Done.
>>
>>
>> http://codereview.chromium.org/4200007/diff/2002/10026
>> File chrome/common/automation_messages.h (right):
>>
>> http://codereview.chromium.org/4200007/diff/2002/10026#newcode202
>> chrome/common/automation_messages.h:202: struct
>> ParamTraits<NavigationEntry::PageType> {
>> On 2010/10/28 18:37:17, Ben Goodger wrote:
>>
>>> Do you have a plan for how to unravel this dependency given that it
>>>
>> forces
>>
>>> common to depend on browser?
>>>
>>
>> Beyond hoisting the enums into chrome/common/, I don't.
>>
>> If you have any better ideas about where this code should live, I'm all
>> ears. It seems that it's problematic wherever I put it.
>>
>>
>> http://codereview.chromium.org/4200007/show
>>
>
>

[amit, 2010-10-28 21:50:27]

On 2010/10/28 19:31:58, Ben Goodger wrote:
> On Thu, Oct 28, 2010 at 12:31 PM, Ben Goodger (Google)
<ben@chromium.org>wrote:
> 
> > Who uses these TabContents-specific automation messages and what for? How
> > does the CF integration relate?
> >
> > In the long term, TabContents will become its own toplevel directory in
> > src/. My naive assertion is that TC related stuff should live together...
> > but I'd like to understand a bit more.

GCF hosts a 'TabContents' using an 'ExternalTabContainer' class. So removing 
TabContents dependencies and moving it to a top level folder is quite
beneficial.  

I am not sure what you mean by TabContents specific automation messages. GCF
uses messages like AutomationMsg_NavigateInExternalTab which go through the
automation provider. 

> >
> > -Ben
> >
> >
> > On Thu, Oct 28, 2010 at 11:57 AM, <mailto:erg@chromium.org> wrote:
> >
> >>
> >> http://codereview.chromium.org/4200007/diff/2002/10022
> >> File chrome/chrome_tests.gypi (right):
> >>
> >> http://codereview.chromium.org/4200007/diff/2002/10022#newcode9
> >> chrome/chrome_tests.gypi:9: 'common/pref_names.cc',
> >> On 2010/10/28 18:43:30, Nirnimesh wrote:
> >>
> >>> Please include chrome/common/automation_constants.h here
> >>>
> >>
> >> Done.
> >>
> >>
> >> http://codereview.chromium.org/4200007/diff/2002/10026
> >> File chrome/common/automation_messages.h (right):
> >>
> >> http://codereview.chromium.org/4200007/diff/2002/10026#newcode202
> >> chrome/common/automation_messages.h:202: struct
> >> ParamTraits<NavigationEntry::PageType> {
> >> On 2010/10/28 18:37:17, Ben Goodger wrote:
> >>
> >>> Do you have a plan for how to unravel this dependency given that it
> >>>
> >> forces
> >>
> >>> common to depend on browser?
> >>>
> >>
> >> Beyond hoisting the enums into chrome/common/, I don't.
> >>
> >> If you have any better ideas about where this code should live, I'm all
> >> ears. It seems that it's problematic wherever I put it.
> >>
> >>
> >> http://codereview.chromium.org/4200007/show
> >>
> >
> >
>

[Elliot Glaysher, 2010-10-29 21:22:20]

> Who uses these TabContents-specific automation messages and what
> for? How does the CF integration relate?

Automation used to just be for testing. And now it certainly has grown. CF uses
automation to control a tab contents, as the tests use automation to control a
test process.

> GCF hosts a 'TabContents' using an 'ExternalTabContainer' class. So removing 
> TabContents dependencies and moving it to a top level folder is quite
> beneficial.

As of patchest 8, chrome_frame doesn't depend on tab_contents.h, as all the
important constants have been hoisted into chrome/common/. The DEPS modification
has been removed, too.

[Ben Goodger (Google), 2010-11-01 17:50:36]

LGTM