More strict restrictions for content -> content/shell dependencies.

More strict restrictions for content -> content/shell dependencies.

This CL removes content -> content/shell layering violation around
swapped-out filtering, by moving the filtering code into
LayoutTestContentClient in the appropriate layer.

This CL also tweaks content/DEPS to restricts allowed dependencies, by
expanding a comment into an actual DEPS rule that only allows content/shell
dependency for browser tests.

Additionally, a DEPS exception in content/common/DEPS is not needed anymore
(per https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#newcode70).

BUG=357747, 596736
Committed: https://crrev.com/80f7f60ce8e7c651c0d3d5957fbbb4ffe9972309
Cr-Commit-Position: refs/heads/master@{#382725}

[Łukasz Anforowicz, 2016-03-08 17:25:22]

Description was changed from

==========
More strict restrictions for content -> content/shell dependencies.

This is a follow-up to a code review comment in a separate CL, here:
https://codereview.chromium.org/1765623003/#msg7

BUG=
==========

to

==========
More strict restrictions for content -> content/shell dependencies.

This is a follow-up to a code review comment in a separate CL, here:
https://codereview.chromium.org/1765623003/#msg7

BUG=357747
==========

[Łukasz Anforowicz, 2016-03-08 17:32:41]

lukasza@chromium.org changed reviewers:
+ jochen@chromium.org, nasko@chromium.org

[Łukasz Anforowicz, 2016-03-08 17:32:41]

nasko@ + jochen@, could you please take a look?

This is a follow-up to a code review comment from jochen@ made in a separate CL,
here:
https://codereview.chromium.org/1765623003/#msg7

[jochen (gone - plz use gerrit), 2016-03-09 14:57:19]

https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS
File content/common/DEPS (right):

https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
content/common/DEPS:70: "java_bridge_messages\.h": [
that file doesn't exist anymore, right?

https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
content/common/DEPS:74: # TODO(nasko): https://crbug.com/357747: Should remove
swapped out altogether.
the CL that introduced this fixes a single layout test. can we just skip the
layout test instead?

[Łukasz Anforowicz, 2016-03-09 21:47:42]

jochen@, can you take another look please?

https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS
File content/common/DEPS (right):

https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
content/common/DEPS:70: "java_bridge_messages\.h": [
On 2016/03/09 14:57:19, jochen wrote:
> that file doesn't exist anymore, right?

Done - removed.

buildtools/checkdeps/checkdeps.py content # continues to pass.

I did find content/common/gin_java_bridge_messages.h, but 1) it looks to be
something different + 2) it doesn't include anything from content/child.

https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
content/common/DEPS:74: # TODO(nasko): https://crbug.com/357747: Should remove
swapped out altogether.
On 2016/03/09 14:57:19, jochen wrote:
> the CL that introduced this fixes a single layout test. can we just skip the
> layout test instead?

I'd rather leave this here - currently (now that we've OOPIF-ied a significant
chunk of layout test harness) removing the ShellViewHostMsg_PrintMessage
exclusion in swapped_out_message.cc leads to 222 failures (text/diffs) under
http/tests when layout tests are run with --site-per-process.  For example -
this breaks all tests that expect the actual output to contain lines from
|alert('blah')| kind of calls.

I think we also have a tentative plan for getting rid of the swapped out
exclusions even in case swapped out cannot be yanked out soon - we can send
messages through a local frame, rather than sending them via (swapped out)
render view.  Still - this is a tentative plan - before we commit to it we
should have a clearer picture of which pieces of BlinkTestRunner (and
BlinkTestController) are per-view vs per-process vs per-frame and only after
having that picture change how messages are sent around.  This might also be an
interesting mojofication experiment (although I am very skeptical about the
absence of ordering guarantees for navigation-vs-layouttest messages).

I guess the last paragraph is a long-winded way of trying to say "It will really
be temporary.  Pinky-promise!".  Hmmmm... :-)  OTOH, I am not sure if we have
good alternatives and the layering violation is narrow and won't grow (after
landing the DEPS CL).

[jochen (gone - plz use gerrit), 2016-03-10 15:45:13]

On 2016/03/09 at 21:47:42, lukasza wrote:
> jochen@, can you take another look please?
> 
> https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS
> File content/common/DEPS (right):
> 
>
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
> content/common/DEPS:70: "java_bridge_messages\.h": [
> On 2016/03/09 14:57:19, jochen wrote:
> > that file doesn't exist anymore, right?
> 
> Done - removed.
> 
> buildtools/checkdeps/checkdeps.py content # continues to pass.
> 
> I did find content/common/gin_java_bridge_messages.h, but 1) it looks to be
something different + 2) it doesn't include anything from content/child.
> 
>
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
> content/common/DEPS:74: # TODO(nasko): https://crbug.com/357747: Should remove
swapped out altogether.
> On 2016/03/09 14:57:19, jochen wrote:
> > the CL that introduced this fixes a single layout test. can we just skip the
> > layout test instead?
> 
> I'd rather leave this here - currently (now that we've OOPIF-ied a significant
chunk of layout test harness) removing the ShellViewHostMsg_PrintMessage
exclusion in swapped_out_message.cc leads to 222 failures (text/diffs) under
http/tests when layout tests are run with --site-per-process.  For example -
this breaks all tests that expect the actual output to contain lines from
|alert('blah')| kind of calls.
> 
> I think we also have a tentative plan for getting rid of the swapped out
exclusions even in case swapped out cannot be yanked out soon - we can send
messages through a local frame, rather than sending them via (swapped out)
render view.  Still - this is a tentative plan - before we commit to it we
should have a clearer picture of which pieces of BlinkTestRunner (and
BlinkTestController) are per-view vs per-process vs per-frame and only after
having that picture change how messages are sent around.  This might also be an
interesting mojofication experiment (although I am very skeptical about the
absence of ordering guarantees for navigation-vs-layouttest messages).
> 
> I guess the last paragraph is a long-winded way of trying to say "It will
really be temporary.  Pinky-promise!".  Hmmmm... :-)  OTOH, I am not sure if we
have good alternatives and the layering violation is narrow and won't grow
(after landing the DEPS CL).

why not add a ContentClient interface then?

[Łukasz Anforowicz, 2016-03-14 20:35:57]

On 2016/03/10 15:45:13, jochen wrote:
> On 2016/03/09 at 21:47:42, lukasza wrote:
> > jochen@, can you take another look please?
> > 
> > https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS
> > File content/common/DEPS (right):
> > 
> >
>
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
> > content/common/DEPS:70: "java_bridge_messages\.h": [
> > On 2016/03/09 14:57:19, jochen wrote:
> > > that file doesn't exist anymore, right?
> > 
> > Done - removed.
> > 
> > buildtools/checkdeps/checkdeps.py content # continues to pass.
> > 
> > I did find content/common/gin_java_bridge_messages.h, but 1) it looks to be
> something different + 2) it doesn't include anything from content/child.
> > 
> >
>
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
> > content/common/DEPS:74: # TODO(nasko): https://crbug.com/357747: Should
remove
> swapped out altogether.
> > On 2016/03/09 14:57:19, jochen wrote:
> > > the CL that introduced this fixes a single layout test. can we just skip
the
> > > layout test instead?
> > 
> > I'd rather leave this here - currently (now that we've OOPIF-ied a
significant
> chunk of layout test harness) removing the ShellViewHostMsg_PrintMessage
> exclusion in swapped_out_message.cc leads to 222 failures (text/diffs) under
> http/tests when layout tests are run with --site-per-process.  For example -
> this breaks all tests that expect the actual output to contain lines from
> |alert('blah')| kind of calls.
> > 
> > I think we also have a tentative plan for getting rid of the swapped out
> exclusions even in case swapped out cannot be yanked out soon - we can send
> messages through a local frame, rather than sending them via (swapped out)
> render view.  Still - this is a tentative plan - before we commit to it we
> should have a clearer picture of which pieces of BlinkTestRunner (and
> BlinkTestController) are per-view vs per-process vs per-frame and only after
> having that picture change how messages are sent around.  This might also be
an
> interesting mojofication experiment (although I am very skeptical about the
> absence of ordering guarantees for navigation-vs-layouttest messages).
> > 
> > I guess the last paragraph is a long-winded way of trying to say "It will
> really be temporary.  Pinky-promise!".  Hmmmm... :-)  OTOH, I am not sure if
we
> have good alternatives and the layering violation is narrow and won't grow
> (after landing the DEPS CL).
> 
> why not add a ContentClient interface then?

Because these swapped-out exceptions will be gone soon (i.e. see [1])
and I am hesitant to add extra abstractions for stuff that is going away.

So - for the CL under review I think I'll just wait until nasko@ finishes
ripping out swapped-out (which will automatically resolve the concerns above).

For longer term, we might want to tweak how BlinkTestController and
BlinkTestRunner
talk to each other.  One option is to talk via RenderFrame (rather than via
RenderView
which is potentially associated with a *remote* frame) - this would require
attributing
many test runner activities to a frame (see [2] for attribution for PrintMessage
and
a few other messages;  also note how we send via a random local frame in some
cases - yuck [3]).
Another option might be to investigate how BlinkTestController and
BlinkTestRunner
would look like in a Mojo world (being able to directly send PrintMsg without
attributing
it to a particular frame might simplify some things;  and we need to address
some Mojo
issues [ordering] at one point - might just as well tackle them now).  Let me
know if
you have any other suggestions or ideas.

[1]
https://codereview.chromium.org/1799163002/diff/1/content/browser/frame_host/...

[2]
https://docs.google.com/document/d/1vsLzgHhgIA_UQUtzb6rBcjtAZui1FIaDEb1JfDpJU7o

[3] https://codereview.chromium.org/1715573002/#msg9

[dcheng, 2016-03-14 20:53:43]

On 2016/03/14 at 20:35:57, lukasza wrote:
> On 2016/03/10 15:45:13, jochen wrote:
> > On 2016/03/09 at 21:47:42, lukasza wrote:
> > > jochen@, can you take another look please?
> > > 
> > > https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS
> > > File content/common/DEPS (right):
> > > 
> > >
> >
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
> > > content/common/DEPS:70: "java_bridge_messages\.h": [
> > > On 2016/03/09 14:57:19, jochen wrote:
> > > > that file doesn't exist anymore, right?
> > > 
> > > Done - removed.
> > > 
> > > buildtools/checkdeps/checkdeps.py content # continues to pass.
> > > 
> > > I did find content/common/gin_java_bridge_messages.h, but 1) it looks to
be
> > something different + 2) it doesn't include anything from content/child.
> > > 
> > >
> >
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
> > > content/common/DEPS:74: # TODO(nasko): https://crbug.com/357747: Should
remove
> > swapped out altogether.
> > > On 2016/03/09 14:57:19, jochen wrote:
> > > > the CL that introduced this fixes a single layout test. can we just skip
the
> > > > layout test instead?
> > > 
> > > I'd rather leave this here - currently (now that we've OOPIF-ied a
significant
> > chunk of layout test harness) removing the ShellViewHostMsg_PrintMessage
> > exclusion in swapped_out_message.cc leads to 222 failures (text/diffs) under
> > http/tests when layout tests are run with --site-per-process.  For example -
> > this breaks all tests that expect the actual output to contain lines from
> > |alert('blah')| kind of calls.
> > > 
> > > I think we also have a tentative plan for getting rid of the swapped out
> > exclusions even in case swapped out cannot be yanked out soon - we can send
> > messages through a local frame, rather than sending them via (swapped out)
> > render view.  Still - this is a tentative plan - before we commit to it we
> > should have a clearer picture of which pieces of BlinkTestRunner (and
> > BlinkTestController) are per-view vs per-process vs per-frame and only after
> > having that picture change how messages are sent around.  This might also be
an
> > interesting mojofication experiment (although I am very skeptical about the
> > absence of ordering guarantees for navigation-vs-layouttest messages).
> > > 
> > > I guess the last paragraph is a long-winded way of trying to say "It will
> > really be temporary.  Pinky-promise!".  Hmmmm... :-)  OTOH, I am not sure if
we
> > have good alternatives and the layering violation is narrow and won't grow
> > (after landing the DEPS CL).
> > 
> > why not add a ContentClient interface then?
> 
> Because these swapped-out exceptions will be gone soon (i.e. see [1])
> and I am hesitant to add extra abstractions for stuff that is going away.
> 
> So - for the CL under review I think I'll just wait until nasko@ finishes
> ripping out swapped-out (which will automatically resolve the concerns above).
> 
> For longer term, we might want to tweak how BlinkTestController and
BlinkTestRunner
> talk to each other.  One option is to talk via RenderFrame (rather than via
RenderView
> which is potentially associated with a *remote* frame) - this would require
attributing
> many test runner activities to a frame (see [2] for attribution for
PrintMessage and
> a few other messages;  also note how we send via a random local frame in some
cases - yuck [3]).
> Another option might be to investigate how BlinkTestController and
BlinkTestRunner
> would look like in a Mojo world (being able to directly send PrintMsg without
attributing
> it to a particular frame might simplify some things;  and we need to address
some Mojo
> issues [ordering] at one point - might just as well tackle them now).  Let me
know if
> you have any other suggestions or ideas.

Thinking about this more, I'm not really sure that Mojo will solve these
problems.
1) If we want PrintMessage to be well-ordered WRT to something else (and we
probably do), PrintMessage is going to have to be an associated interface (each
Mojo interface, by default, has its own message pipe, and thus there is no
guarantee of ordering between two Mojo interfaces. A Mojo interface can have
associated interfaces with it, and the associated interfaces all share the same
message pipe, hence providing FIFO guarantees).
2) If it's an associated interface, I suspect it won't be trivial to just make
it a global on both sides (which is what it sounds like this is trending
towards).
3) Thus it's either going to be process, view, or frame bound in the end anyway.
So we'll need to figure this out either way.

> 
> [1]
https://codereview.chromium.org/1799163002/diff/1/content/browser/frame_host/...
> 
> [2]
https://docs.google.com/document/d/1vsLzgHhgIA_UQUtzb6rBcjtAZui1FIaDEb1JfDpJU7o
> 
> [3] https://codereview.chromium.org/1715573002/#msg9

[Łukasz Anforowicz, 2016-03-22 17:08:13]

Description was changed from

==========
More strict restrictions for content -> content/shell dependencies.

This is a follow-up to a code review comment in a separate CL, here:
https://codereview.chromium.org/1765623003/#msg7

BUG=357747
==========

to

==========
More strict restrictions for content -> content/shell dependencies.

This CL removes content -> content/shell layering violation around
swapped-out filtering, by moving the filtering code into
LayoutTestContentClient in the appropriate layer.

This CL also tweaks content/DEPS to restricts allowed dependencies, by
expanding a comment into an actual DEPS rule that only allows content/shell
dependency for browser tests.

Additionally, a DEPS exception in content/common/DEPS is not needed anymore
(per
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...).

BUG=357747, 594219
==========

[Łukasz Anforowicz, 2016-03-22 17:29:31]

jochen@, can you take another look please?

Changes since the last time:

- Got rid of swapped-out-related layering violation (via
ContentClient::CanSendWhileSwappedOut overriden in the layout tests layer - in
LayoutTestContentClient)

- There is now a separate bug and a CL (by brettw@ and jam@) addressing the
layering violation: https://crbug.com/596736 and
https://codereview.chromium.org/1821243002/ (although this CL handles layout
test messages in the shell layer - in ShellContentClient)

https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS
File content/common/DEPS (right):

https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...
content/common/DEPS:74: # TODO(nasko): https://crbug.com/357747: Should remove
swapped out altogether.
On 2016/03/09 21:47:42, Łukasz Anforowicz wrote:
> On 2016/03/09 14:57:19, jochen wrote:
> > the CL that introduced this fixes a single layout test. can we just skip the
> > layout test instead?
> 
> I'd rather leave this here - currently (now that we've OOPIF-ied a significant
> chunk of layout test harness) removing the ShellViewHostMsg_PrintMessage
> exclusion in swapped_out_message.cc leads to 222 failures (text/diffs) under
> http/tests when layout tests are run with --site-per-process.  For example -
> this breaks all tests that expect the actual output to contain lines from
> |alert('blah')| kind of calls.
> 
> I think we also have a tentative plan for getting rid of the swapped out
> exclusions even in case swapped out cannot be yanked out soon - we can send
> messages through a local frame, rather than sending them via (swapped out)
> render view.  Still - this is a tentative plan - before we commit to it we
> should have a clearer picture of which pieces of BlinkTestRunner (and
> BlinkTestController) are per-view vs per-process vs per-frame and only after
> having that picture change how messages are sent around.  This might also be
an
> interesting mojofication experiment (although I am very skeptical about the
> absence of ordering guarantees for navigation-vs-layouttest messages).
> 
> I guess the last paragraph is a long-winded way of trying to say "It will
really
> be temporary.  Pinky-promise!".  Hmmmm... :-)  OTOH, I am not sure if we have
> good alternatives and the layering violation is narrow and won't grow (after
> landing the DEPS CL).

Done - it turns out that there already is a public API for filtering swapped out
messages (ContentClient::CanSendWhileSwappedOut) - layout tests should simply
reuse this.

[Łukasz Anforowicz, 2016-03-22 17:30:41]

Description was changed from

==========
More strict restrictions for content -> content/shell dependencies.

This CL removes content -> content/shell layering violation around
swapped-out filtering, by moving the filtering code into
LayoutTestContentClient in the appropriate layer.

This CL also tweaks content/DEPS to restricts allowed dependencies, by
expanding a comment into an actual DEPS rule that only allows content/shell
dependency for browser tests.

Additionally, a DEPS exception in content/common/DEPS is not needed anymore
(per
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...).

BUG=357747, 594219
==========

to

==========
More strict restrictions for content -> content/shell dependencies.

This CL removes content -> content/shell layering violation around
swapped-out filtering, by moving the filtering code into
LayoutTestContentClient in the appropriate layer.

This CL also tweaks content/DEPS to restricts allowed dependencies, by
expanding a comment into an actual DEPS rule that only allows content/shell
dependency for browser tests.

Additionally, a DEPS exception in content/common/DEPS is not needed anymore
(per
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...).

BUG=357747, 596736
==========

[jam, 2016-03-22 19:35:59]

jam@chromium.org changed reviewers:
+ jam@chromium.org

[jam, 2016-03-22 19:36:00]

lgtm

https://codereview.chromium.org/1777503003/diff/60001/content/shell/common/la...
File content/shell/common/layout_test/layout_test_content_client.h (right):

https://codereview.chromium.org/1777503003/diff/60001/content/shell/common/la...
content/shell/common/layout_test/layout_test_content_client.h:13: class
LayoutTestContentClient : public content::ShellContentClient {
nit: no content::

[Łukasz Anforowicz, 2016-03-22 20:30:48]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-22 20:31:22]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1777503003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1777503003/80001

[Łukasz Anforowicz, 2016-03-22 20:36:15]

Thanks jam@.  jochen@ - can you take a look? (patchset #4 addresses the
swapped-out layering violation that you've called out in
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...)

https://codereview.chromium.org/1777503003/diff/60001/content/shell/common/la...
File content/shell/common/layout_test/layout_test_content_client.h (right):

https://codereview.chromium.org/1777503003/diff/60001/content/shell/common/la...
content/shell/common/layout_test/layout_test_content_client.h:13: class
LayoutTestContentClient : public content::ShellContentClient {
On 2016/03/22 19:36:00, jam wrote:
> nit: no content::

Done.

[commit-bot: I haz the power, 2016-03-22 22:02:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-22 22:02:38]

Dry run: This issue passed the CQ dry run.

[jam, 2016-03-22 22:04:28]

On 2016/03/22 20:36:15, Łukasz Anforowicz wrote:
> Thanks jam@.  jochen@ - can you take a look? (patchset #4 addresses the
> swapped-out layering violation that you've called out in
>
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...)

I believe there's no need to wait for another review on this; this is an obvious
fix.

[jam, 2016-03-22 22:04:29]

The CQ bit was checked by jam@chromium.org

[jam, 2016-03-22 22:04:29]

The patchset sent to the CQ was uploaded after l-g-t-m from jam@chromium.org
Link to the patchset: https://codereview.chromium.org/1777503003/#ps80001
(title: "Removed unnecessary namespace-qualification.")

[commit-bot: I haz the power, 2016-03-22 22:04:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1777503003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1777503003/80001

[Łukasz Anforowicz, 2016-03-22 22:10:29]

On 2016/03/22 22:04:28, jam wrote:
> On 2016/03/22 20:36:15, Łukasz Anforowicz wrote:
> > Thanks jam@.  jochen@ - can you take a look? (patchset #4 addresses the
> > swapped-out layering violation that you've called out in
> >
>
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...)
> 
> I believe there's no need to wait for another review on this; this is an
obvious
> fix.

Ok.  jochen@ - please shout if you see anything that needs tweaking or a
follow-up.

[commit-bot: I haz the power, 2016-03-22 22:14:42]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-22 22:14:43]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Łukasz Anforowicz, 2016-03-22 22:19:49]

nasko@ - could you please take a look at content/common/swapped_out_messages.cc?

[nasko, 2016-03-22 23:06:59]

content/common/swapped_out_messages.cc LGTM

[Łukasz Anforowicz, 2016-03-22 23:08:12]

The CQ bit was checked by lukasza@chromium.org

[commit-bot: I haz the power, 2016-03-22 23:08:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1777503003/80001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1777503003/80001

[commit-bot: I haz the power, 2016-03-22 23:13:28]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-03-22 23:14:32]

Description was changed from

==========
More strict restrictions for content -> content/shell dependencies.

This CL removes content -> content/shell layering violation around
swapped-out filtering, by moving the filtering code into
LayoutTestContentClient in the appropriate layer.

This CL also tweaks content/DEPS to restricts allowed dependencies, by
expanding a comment into an actual DEPS rule that only allows content/shell
dependency for browser tests.

Additionally, a DEPS exception in content/common/DEPS is not needed anymore
(per
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...).

BUG=357747, 596736
==========

to

==========
More strict restrictions for content -> content/shell dependencies.

This CL removes content -> content/shell layering violation around
swapped-out filtering, by moving the filtering code into
LayoutTestContentClient in the appropriate layer.

This CL also tweaks content/DEPS to restricts allowed dependencies, by
expanding a comment into an actual DEPS rule that only allows content/shell
dependency for browser tests.

Additionally, a DEPS exception in content/common/DEPS is not needed anymore
(per
https://codereview.chromium.org/1777503003/diff/20001/content/common/DEPS#new...).

BUG=357747, 596736

Committed: https://crrev.com/80f7f60ce8e7c651c0d3d5957fbbb4ffe9972309
Cr-Commit-Position: refs/heads/master@{#382725}
==========

[commit-bot: I haz the power, 2016-03-22 23:14:33]

Patchset 5 (id:??) landed as
https://crrev.com/80f7f60ce8e7c651c0d3d5957fbbb4ffe9972309
Cr-Commit-Position: refs/heads/master@{#382725}