Import TestRunner library into chromium.

Import TestRunner library into chromium.

The reasons for the move are:

- it's actually a blink embedder, so it can't use blink/wtf types
- it can't use base either
- we want to replace CppBoundClass with gin::Wrappable, not possible in blink

In the first step, this is mostly a 1:1 copy (except for include paths).
Follow-up CLs will move the test plugin and layout tests helpers and
clean up the coding style

BUG=324658
R=abarth@chromium.org, maruel@chromium.org, torne@chromium.org, jam@chromium.org
TBR=torne@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=242095

[jochen (gone - plz use gerrit), 2013-12-19 17:13:37]

plz review

Marc-Antoine, presubmit
John, directory layout
Adam, everything

[jochen (gone - plz use gerrit), 2013-12-19 17:14:26]

On 2013/12/19 17:13:37, jochen wrote:
> plz review
> 
> Marc-Antoine, presubmit
> John, directory layout
> Adam, everything

I'll kick off tryjobs as soon as I'm back on my pc

[jam, 2013-12-19 17:30:58]

quick questions:
-does all the stuff in content/public need to be there? i.e. are some of these
interfaces or methods only used by content/test only? Or if there are some
methods that are used by content/shell, can you enumerate which ones they are
(if they're not too many), and can we put them on existing content/public/ files
like content/public/test/layouttest_support.h?
-in general, when moving files like this we should try to preserve OWNERS so
that people who touch these files don't lose privileges. it looks like the
testing files in blink had * as owners, so should we do that here as well?

[abarth-chromium, 2013-12-19 17:37:39]

On 2013/12/19 17:30:58, jam wrote:
> -in general, when moving files like this we should try to preserve OWNERS so
> that people who touch these files don't lose privileges. it looks like the
> testing files in blink had * as owners, so should we do that here as well?

We just used * because we were lazy.  We might want to look at who has been
working on / reviewing changes to this code and pick an actual list of folks.

[abarth-chromium, 2013-12-19 17:42:05]

I didn't read all the files in detail, but LGTM

https://codereview.chromium.org/110533009/diff/20001/content/content_layout_t...
File content/content_layout_tests.gypi (right):

https://codereview.chromium.org/110533009/diff/20001/content/content_layout_t...
content/content_layout_tests.gypi:113: 'WEBTESTRUNNER_IMPLEMENTATION=1',
This seems redundant with the same declaration above.

https://codereview.chromium.org/110533009/diff/20001/content/public/test/layo...
File content/public/test/layout_tests/WebFrameTestProxy.h (right):

https://codereview.chromium.org/110533009/diff/20001/content/public/test/layo...
content/public/test/layout_tests/WebFrameTestProxy.h:33: */
I believe you can remove these license blocks when the only copyright holder is
Google.

[M-A Ruel, 2013-12-19 17:53:51]

PRESUBMIT.py lgtm

[jochen (gone - plz use gerrit), 2013-12-19 18:41:34]

On 2013/12/19 17:30:58, jam wrote:
> quick questions:
> -does all the stuff in content/public need to be there? i.e. are some of these
> interfaces or methods only used by content/test only? Or if there are some
> methods that are used by content/shell, can you enumerate which ones they are
> (if they're not too many), and can we put them on existing content/public/
files
> like content/public/test/layouttest_support.h?

content/shell uses all headers I moved to content/public - they used to be in
third_party/WebKit/public/testing - except for WebScopedPtr.h which we can
replace by scoped_ptr<> after the move.

the headers mostly define interfaces which are implemented by content shell

[jam, 2013-12-19 19:16:25]

On 2013/12/19 18:41:34, jochen wrote:
> On 2013/12/19 17:30:58, jam wrote:
> > quick questions:
> > -does all the stuff in content/public need to be there? i.e. are some of
these
> > interfaces or methods only used by content/test only? Or if there are some
> > methods that are used by content/shell, can you enumerate which ones they
are
> > (if they're not too many), and can we put them on existing content/public/
> files
> > like content/public/test/layouttest_support.h?
> 
> content/shell uses all headers I moved to content/public - they used to be in
> third_party/WebKit/public/testing - except for WebScopedPtr.h which we can
> replace by scoped_ptr<> after the move.
> 
> the headers mostly define interfaces which are implemented by content shell

I picked one method randomly: createWebRTCPeerConnectionHandler on
WebTestInterfaces. This is on an interface in content/public now, implemented in
content/shell, and called by content/shell.

[jochen (gone - plz use gerrit), 2013-12-19 19:19:16]

On 2013/12/19 19:16:25, jam wrote:
> On 2013/12/19 18:41:34, jochen wrote:
> > On 2013/12/19 17:30:58, jam wrote:
> > > quick questions:
> > > -does all the stuff in content/public need to be there? i.e. are some of
> these
> > > interfaces or methods only used by content/test only? Or if there are some
> > > methods that are used by content/shell, can you enumerate which ones they
> are
> > > (if they're not too many), and can we put them on existing content/public/
> > files
> > > like content/public/test/layouttest_support.h?
> > 
> > content/shell uses all headers I moved to content/public - they used to be
in
> > third_party/WebKit/public/testing - except for WebScopedPtr.h which we can
> > replace by scoped_ptr<> after the move.
> > 
> > the headers mostly define interfaces which are implemented by content shell
> 
> I picked one method randomly: createWebRTCPeerConnectionHandler on
> WebTestInterfaces. This is on an interface in content/public now, implemented
in
> content/shell, and called by content/shell.

It's called by content shell, but implemented in the test runner library.

[jochen (gone - plz use gerrit), 2013-12-19 21:03:09]

John proposed via chat (if I understood correctly) to move the code inside
content/shell - probably content/shell/renderer/test_runner

It would no longer be a shared library, but compiled into content shell.

Is everybody ok with this approach?

If possible, I'd like to land the change tomorrow.

[abarth-chromium, 2013-12-20 04:33:35]

On 2013/12/19 21:03:09, jochen wrote:
> Is everybody ok with this approach?

That fine with me as long as we don't ship this code anywhere.  It's dangerous
to ship because it doesn't respect the security model.

[jochen (gone - plz use gerrit), 2013-12-20 10:31:17]

I've moved the code inside content shell.

[jochen (gone - plz use gerrit), 2013-12-20 12:17:51]

+torne for android_webview

I've also added an OWNERS file with Adam and started a thread on blink-dev
proposing a larger list.

[commit-bot: I haz the power, 2013-12-20 13:02:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jochen@chromium.org/110533009/150001

[Torne, 2013-12-20 13:21:17]

android_webview license stuff LGTM

[jochen (gone - plz use gerrit), 2013-12-20 13:27:44]

Committed patchset #9 manually as r242095 (presubmit successful).

[jam, 2013-12-20 17:40:16]

lgtm, thanks

[jam, 2014-03-19 17:09:04]

followup ping: this is still using webkit style, uses file names with capitals,
isn't in the content namespace etc. these are all things that it needs since
it's in src/content to be consistent with all the code there.

are there plans to convert this soon?

[jochen (gone - plz use gerrit), 2014-03-19 20:29:50]

On 2014/03/19 17:09:04, jam wrote:
> followup ping: this is still using webkit style, uses file names with
capitals,
> isn't in the content namespace etc. these are all things that it needs since
> it's in src/content to be consistent with all the code there.
> 
> are there plans to convert this soon?

we currently convert the files while removing CppBoundClass instances which is a
bit slow. You should see already a few files like test_runner.cc. After that,
the rest should be more or less mechanical

[jam, 2014-03-20 17:02:56]

On 2014/03/19 20:29:50, jochen wrote:
> On 2014/03/19 17:09:04, jam wrote:
> > followup ping: this is still using webkit style, uses file names with
> capitals,
> > isn't in the content namespace etc. these are all things that it needs since
> > it's in src/content to be consistent with all the code there.
> > 
> > are there plans to convert this soon?
> 
> we currently convert the files while removing CppBoundClass instances which is
a
> bit slow. You should see already a few files like test_runner.cc. After that,
> the rest should be more or less mechanical

ok, thanks for the update. just to be clear, so there are people already tasked
with doing this? or are you saying that it should be easy for anyone to convert?

[jochen (gone - plz use gerrit), 2014-03-20 20:05:30]

On 2014/03/20 17:02:56, jam wrote:
> On 2014/03/19 20:29:50, jochen wrote:
> > On 2014/03/19 17:09:04, jam wrote:
> > > followup ping: this is still using webkit style, uses file names with
> > capitals,
> > > isn't in the content namespace etc. these are all things that it needs
since
> > > it's in src/content to be consistent with all the code there.
> > > 
> > > are there plans to convert this soon?
> > 
> > we currently convert the files while removing CppBoundClass instances which
is
> a
> > bit slow. You should see already a few files like test_runner.cc. After
that,
> > the rest should be more or less mechanical
> 
> ok, thanks for the update. just to be clear, so there are people already
tasked
> with doing this? or are you saying that it should be easy for anyone to
convert?

nobody has signed up yet for it. I plan to find an owner for converting the rest
once CppBoundClass is gone.