Remove RenderFrameMessageFilter.

Remove RenderFrameMessageFilter.

All the conversions to frame IPCs are happening on RenderMessageFilter, anyway.

BUG=none
TEST=none

Committed: https://crrev.com/8acbcea784e3aa4cbfc500a08ae0344fafb32289
Cr-Commit-Position: refs/heads/master@{#346675}

[Avi (use Gerrit), 2015-09-01 00:45:15]

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

[commit-bot: I haz the power, 2015-09-01 00:45:24]

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

[Avi (use Gerrit), 2015-09-01 01:08:51]

avi@chromium.org changed reviewers:
+ creis@chromium.org, nasko@chromium.org

[Avi (use Gerrit), 2015-09-01 01:08:51]

Yeah. Re the DEPS, that sucks, but at least we're keeping the number of layering
violations the same.

[commit-bot: I haz the power, 2015-09-01 02:59:14]

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

[commit-bot: I haz the power, 2015-09-01 02:59:15]

Dry run: This issue passed the CQ dry run.

[nasko, 2015-09-01 16:55:33]

Sad that we still need a DEPS exception, but we are replacing one with another,
so it is fine with me.

LGTM

[Avi (use Gerrit), 2015-09-01 17:02:01]

The CQ bit was checked by avi@chromium.org

[commit-bot: I haz the power, 2015-09-01 17:02:23]

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

[commit-bot: I haz the power, 2015-09-01 17:07:52]

Committed patchset #1 (id:1)

[Charlie Reis, 2015-09-01 17:08:02]

On 2015/09/01 16:55:33, nasko wrote:
> Sad that we still need a DEPS exception, but we are replacing one with
another,
> so it is fine with me.
> 
> LGTM

Hmm, I didn't realize the dependency issue.  Is this DEPS problem going to get
worse over time as we handle more frame messages in RenderMessageFilter?  I'm
concerned that this isn't a one-for-one trade.

Before, you could imagine fixing the DEPS problem in RPH by asking the
BrowserContext for the frame filter using a BrowserMessageFilter type. 
(RenderProcessHostImpl doesn't need to know it's a RenderFrameMessageFilter, so
it doesn't need to depend on frame_host/.)

Now, there will be increasingly many frame messages handled in the
renderer_host/ directory, and the logic for those may depend on other files in
frame_host/.  We were aiming for renderer_host/ not to depend on frame_host/ in
general.  Maybe that's a reason to keep RenderFrameMessageFilter that we didn't
think of?  Or are there strong reasons to move forward with this despite that?

[commit-bot: I haz the power, 2015-09-01 17:08:36]

Patchset 1 (id:??) landed as
https://crrev.com/8acbcea784e3aa4cbfc500a08ae0344fafb32289
Cr-Commit-Position: refs/heads/master@{#346675}

[Avi (use Gerrit), 2015-09-01 18:10:23]

On 2015/09/01 17:08:02, Charlie Reis wrote:
> On 2015/09/01 16:55:33, nasko wrote:
> > Sad that we still need a DEPS exception, but we are replacing one with
> another,
> > so it is fine with me.
> > 
> > LGTM
> 
> Hmm, I didn't realize the dependency issue.  Is this DEPS problem going to get
> worse over time as we handle more frame messages in RenderMessageFilter?  I'm
> concerned that this isn't a one-for-one trade.
> 
> Before, you could imagine fixing the DEPS problem in RPH by asking the
> BrowserContext for the frame filter using a BrowserMessageFilter type. 
> (RenderProcessHostImpl doesn't need to know it's a RenderFrameMessageFilter,
so
> it doesn't need to depend on frame_host/.)
> 
> Now, there will be increasingly many frame messages handled in the
> renderer_host/ directory, and the logic for those may depend on other files in
> frame_host/.  We were aiming for renderer_host/ not to depend on frame_host/
in
> general.  Maybe that's a reason to keep RenderFrameMessageFilter that we
didn't
> think of?  Or are there strong reasons to move forward with this despite that?

Good point.

There's no huge reason we need to move forward with this. I saw one handler for
one IPC vs every other frame IPC on the RenderMessageFilter.

If you think it's better if we don't go this way, I'll revert and rework.

[Avi (use Gerrit), 2015-09-01 20:02:24]

After discussion with Nasko, reverting and re-working this is how I'm going to
go.

[Charlie Reis, 2015-09-01 20:05:51]

On 2015/09/01 20:02:24, Avi wrote:
> After discussion with Nasko, reverting and re-working this is how I'm going to
> go.

Yeah, I think that makes sense.  Looking at the existing frame messages in
RenderMessageFilter, I think they'll fit better in frame_host/ than
renderer_host/.  Thanks.

[Avi (use Gerrit), 2015-09-01 20:17:26]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/1314133005/ by avi@chromium.org.

The reason for reverting is: We're going a different route..