Remove remaining WebContentsImpl from InterstitialPageImpl.

Remove remaining WebContentsImpl from InterstitialPageImpl.

A followup CL to crrev.com/230889, since I missed few cases of WebContentsImpl usage.
The reason for moving InterstitialPage::Create to content/public/ is the need to know about both WebContentsImpl and InterstitialPageImpl. Since the goal is to break the InterstitialPageImpl -> WebContentsImpl dependency and this method is the public interface to InterstitialPage, it cannot stay in interstitial_page_impl.cc.

BUG=304341

[nasko, 2013-10-25 20:46:11]

Hey guys,
I've missed some WebContentsImpl instances in my previous CL. In order to remove
the rest, I needed to move the public InterstitialPage::Create method to
content/public/.
I'm not sure if this pattern is good or not, but it is allowed by DEPS and it
makes some sense for public wrapper for impl specific constructor to be next to
the header file. Any feedback/comment appreciated.
Thanks,
Nasko

[jam, 2013-10-25 23:17:48]

I don't follow the reason to do this? If InterstitialPageImpl knows about
WebContents, isn't that equivalent to it knowing about WebContentsImpl?
WebContents vs WebContentsImpl is related to Content API only.

[Charlie Reis, 2013-10-25 23:28:07]

On 2013/10/25 23:17:48, jam wrote:
> I don't follow the reason to do this? If InterstitialPageImpl knows about
> WebContents, isn't that equivalent to it knowing about WebContentsImpl?
> WebContents vs WebContentsImpl is related to Content API only.

It's because InterstitialPageImpl is moving to a new frame_host directory that
doesn't depend on the web_contents directory, kind of like the classes in
renderer_host.

[jam, 2013-10-28 16:49:49]

On 2013/10/25 23:28:07, creis wrote:
> On 2013/10/25 23:17:48, jam wrote:
> > I don't follow the reason to do this? If InterstitialPageImpl knows about
> > WebContents, isn't that equivalent to it knowing about WebContentsImpl?
> > WebContents vs WebContentsImpl is related to Content API only.
> 
> It's because InterstitialPageImpl is moving to a new frame_host directory that
> doesn't depend on the web_contents directory, kind of like the classes in
> renderer_host.

My point is that InterstitialPageImpl depending on
content/public/browser/web_contents.h is equivalent to depending on
content/browser/web_contents/web_contents_impl.h

If you look at content/browser/renderer_host, the DEPS file there actually
disallows web_contents.h.

[nasko, 2013-10-28 16:59:34]

On 2013/10/28 16:49:49, jam wrote:
> On 2013/10/25 23:28:07, creis wrote:
> > On 2013/10/25 23:17:48, jam wrote:
> > > I don't follow the reason to do this? If InterstitialPageImpl knows about
> > > WebContents, isn't that equivalent to it knowing about WebContentsImpl?
> > > WebContents vs WebContentsImpl is related to Content API only.
> > 
> > It's because InterstitialPageImpl is moving to a new frame_host directory
that
> > doesn't depend on the web_contents directory, kind of like the classes in
> > renderer_host.
> 
> My point is that InterstitialPageImpl depending on
> content/public/browser/web_contents.h is equivalent to depending on
> content/browser/web_contents/web_contents_impl.h
> 
> If you look at content/browser/renderer_host, the DEPS file there actually
> disallows web_contents.h.

I agree with you overall. The only reason left for InterstitialPageImpl to use
WebContents is to observe navigation entry commit or web contents distroying, so
it can cleanup itself. We will have to move InterstitialPageImpl to be hosted
somewhere in the frame tree, at which point it will likely key off of a
different event, but not sure what that is yet.

Mechanically though, I want to prevent frame_host/ from including anything from
web_contents/ in the short term.