PlzNavigate: Allow frames to fallback to alternative content.

PlzNavigate: Allow frames to fallback to alternative content.

This CL gives frames the opportunity to show alternative content when
<object data="..."> navigation fails instead of displaying an error
page.

It fixes a collection of tests(see bug description) that fail with the
--enable-browser-side-navigation flag.

BUG=657834
Committed: https://crrev.com/bb2aaf9abe13bdd12fbba17fba9901d430057ca0
Cr-Commit-Position: refs/heads/master@{#430266}

[arthursonzogni, 2016-10-21 14:24:49]

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

[commit-bot: I haz the power, 2016-10-21 14:25:05]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-21 15:49:00]

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

[commit-bot: I haz the power, 2016-10-21 15:49:01]

Dry run: This issue passed the CQ dry run.

[arthursonzogni, 2016-10-21 15:59:30]

arthursonzogni@chromium.org changed reviewers:
+ clamy@chromium.org, japhet@chromium.org

[arthursonzogni, 2016-10-21 15:59:31]

Hi Camille and Nate,

Please, could you take a look at this CL?

@clamy:
  content/renderer/render_frame_impl.cc

@japhet:
  third_party/WebKit/Source/web/WebLocalFrameImpl.cpp
  third_party/WebKit/Source/web/WebLocalFrameImpl.h
  third_party/WebKit/public/web/WebLocalFrame.h

FYI: This CL fixes 7 out of 8 test I mention in crbug.com/657834.
     The last one was unrelated to this bug.

Thanks,
Arthur

https://codereview.chromium.org/2439903003/diff/1/third_party/WebKit/Source/w...
File third_party/WebKit/Source/web/WebLocalFrameImpl.cpp (right):

https://codereview.chromium.org/2439903003/diff/1/third_party/WebKit/Source/w...
third_party/WebKit/Source/web/WebLocalFrameImpl.cpp:2062: if (frame()->owner())
I don't know if I can assume that frame()->owner() will always be non-null and
replace the "if" with a "DCHECK".

[clamy, 2016-10-21 16:07:57]

Description was changed from

==========
PlzNavigate: Allow frames to fallback to alternative content.

This CL gives frames the opportunity to show alternative content when
<object data="..."> navigation fails instead of displaying an error
page.

It fixes a collection of tests(see bug description) that fail with the
--enable-browser-side-navigation flag.

BUG=657834
==========

to

==========
PlzNavigate: Allow frames to fallback to alternative content.

This CL gives frames the opportunity to show alternative content when
<object data="..."> navigation fails instead of displaying an error
page.

It fixes a collection of tests(see bug description) that fail with the
--enable-browser-side-navigation flag.

BUG=657834
==========

[clamy, 2016-10-21 16:07:58]

clamy@chromium.org changed reviewers:
+ nasko@chromium.org

[clamy, 2016-10-21 16:09:42]

+nasko: Could you take a look at this? I have questions about history & url
spoof. Also, I'll be ooo until 11/2, so won't be able to review it more.

https://codereview.chromium.org/2439903003/diff/1/content/renderer/render_fra...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2439903003/diff/1/content/renderer/render_fra...
content/renderer/render_frame_impl.cc:5076: frame_->didFailNavigation();
I'm a bit worried about how this interacts with the navigation history. In
particular do we create/update the FrameNavigationEntry in this particular case?
If we don't create or update any, could there be some url spoof issue?

[nasko, 2016-10-21 17:00:04]

https://codereview.chromium.org/2439903003/diff/1/content/renderer/render_fra...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2439903003/diff/1/content/renderer/render_fra...
content/renderer/render_frame_impl.cc:5076: frame_->didFailNavigation();
Should we be loading an error page (last statement before this one) and then
replacing it with fallback content?

I think having a more explicit call to Blink, which returns a boolean whether
fallback content was rendered or not is a bit better. This will allow us to
display that or if no fallback, display the error page.

japhet@ and dcheng@ however are much more knowledgeable in this area, so I'd
defer to them.

[Nate Chapin, 2016-10-21 18:54:00]

https://codereview.chromium.org/2439903003/diff/1/content/renderer/render_fra...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2439903003/diff/1/content/renderer/render_fra...
content/renderer/render_frame_impl.cc:5076: frame_->didFailNavigation();
On 2016/10/21 17:00:04, nasko (slow) wrote:
> Should we be loading an error page (last statement before this one) and then
> replacing it with fallback content?
> 
> I think having a more explicit call to Blink, which returns a boolean whether
> fallback content was rendered or not is a bit better. This will allow us to
> display that or if no fallback, display the error page.
> 
> japhet@ and dcheng@ however are much more knowledgeable in this area, so I'd
> defer to them.

That seems reasonable to me.

[arthursonzogni, 2016-10-25 14:43:02]

Patchset #2 (id:20001) has been deleted

[arthursonzogni, 2016-10-25 14:43:21]

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

[arthursonzogni, 2016-10-25 14:43:30]

The CQ bit was unchecked by arthursonzogni@chromium.org

[arthursonzogni, 2016-10-25 14:44:29]

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

[arthursonzogni, 2016-10-25 14:44:43]

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

[commit-bot: I haz the power, 2016-10-25 14:44:45]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-25 17:09:38]

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

[commit-bot: I haz the power, 2016-10-25 17:09:39]

Dry run: This issue passed the CQ dry run.

[arthursonzogni, 2016-10-26 08:52:40]

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

[commit-bot: I haz the power, 2016-10-26 08:52:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[arthursonzogni, 2016-10-26 08:56:02]

Patchset #2 (id:40001) has been deleted

[commit-bot: I haz the power, 2016-10-26 10:34:58]

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

[commit-bot: I haz the power, 2016-10-26 10:34:59]

Dry run: This issue passed the CQ dry run.

[arthursonzogni, 2016-10-26 11:27:41]

Hi there,

Thank for your reviews.

I made some test (with PlzNavigate disabled). It turns out that the navigation
to the error page is made, even if a fallback content is displayed instead of
it.
That's why I though we could do the same with PlzNavigate. But I am not aware of
a lot of things. Please tell me what do you think.

I still tried your suggestion. I added a condition that makes we don't navigate
to the error page if the parent can display a fallback content instead.
However, I struggle with **not** terminating the loading. Because the frame's
navigation has not been made, the browser and the test runner are waiting.
I unsuccessfully tried ```Send(new FrameHostMsg_DidStopLoading(routing_id_))```
like it was done nearby.
My best try: '''frame_->stopLoading();'''. It seems to work... But I am pretty
sure it is not the right way if there is one.

[Nate Chapin, 2016-10-26 21:33:53]

On 2016/10/26 11:27:41, arthursonzogni wrote:
> Hi there,
> 
> Thank for your reviews.
> 
> I made some test (with PlzNavigate disabled). It turns out that the navigation
> to the error page is made, even if a fallback content is displayed instead of
> it.
> That's why I though we could do the same with PlzNavigate. But I am not aware
of
> a lot of things. Please tell me what do you think.
> 
> I still tried your suggestion. I added a condition that makes we don't
navigate
> to the error page if the parent can display a fallback content instead.
> However, I struggle with **not** terminating the loading. Because the frame's
> navigation has not been made, the browser and the test runner are waiting.
> I unsuccessfully tried ```Send(new
FrameHostMsg_DidStopLoading(routing_id_))```
> like it was done nearby.
> My best try: '''frame_->stopLoading();'''. It seems to work... But I am pretty
> sure it is not the right way if there is one.

Instead of exposing renderFallbackContent() on the public/ API, maybe there
should be a WebLocalFrame::loadFailed(const WebURLError&), and have that call
FrameLoader::loadFailed(). That will render fallback content, and should take
care of FrameLoader's load completion bookkeeping for you.

[arthursonzogni, 2016-10-27 09:52:49]

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

[commit-bot: I haz the power, 2016-10-27 09:53:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[arthursonzogni, 2016-10-27 09:57:40]

The CQ bit was unchecked by arthursonzogni@chromium.org

[arthursonzogni, 2016-10-27 09:58:23]

Patchset #3 (id:80001) has been deleted

[arthursonzogni, 2016-10-27 11:26:25]

Patchset #3 (id:100001) has been deleted

[arthursonzogni, 2016-10-27 11:31:26]

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

[commit-bot: I haz the power, 2016-10-27 11:31:34]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-27 12:39:00]

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

[commit-bot: I haz the power, 2016-10-27 12:39:01]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[arthursonzogni, 2016-10-27 15:14:09]

Patchset #4 (id:140001) has been deleted

[arthursonzogni, 2016-10-27 15:15:07]

On 2016/10/26 21:33:53, Nate Chapin wrote:
> Instead of exposing renderFallbackContent() on the public/ API, maybe there
> should be a WebLocalFrame::loadFailed(const WebURLError&), and have that call
> FrameLoader::loadFailed(). That will render fallback content, and should take
> care of FrameLoader's load completion bookkeeping for you.

Hi Nate,

I follow your suggestions. Thanks!

[Nate Chapin, 2016-10-27 16:44:02]

https://codereview.chromium.org/2439903003/diff/180001/third_party/WebKit/Sou...
File third_party/WebKit/Source/web/WebLocalFrameImpl.cpp (right):

https://codereview.chromium.org/2439903003/diff/180001/third_party/WebKit/Sou...
third_party/WebKit/Source/web/WebLocalFrameImpl.cpp:2070:
frame()->owner()->renderFallbackContent();
Sorry, I was suggesting, instead of calling renderFallbackContent() here, have
this function call:

frame()->loader().loadFailed();

Is that sufficient?

If we do that, we may also be able to get rid of some of the logic in
RenderFrameImpl::OnFailedNavigation, which looks redundant with other load
failure logic.

[arthursonzogni, 2016-10-28 15:55:04]

On 2016/10/27 16:44:02, Nate Chapin wrote:
>
https://codereview.chromium.org/2439903003/diff/180001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/web/WebLocalFrameImpl.cpp (right):
> 
>
https://codereview.chromium.org/2439903003/diff/180001/third_party/WebKit/Sou...
> third_party/WebKit/Source/web/WebLocalFrameImpl.cpp:2070:
> frame()->owner()->renderFallbackContent();
> Sorry, I was suggesting, instead of calling renderFallbackContent() here, have
> this function call:
> 
> frame()->loader().loadFailed();
> 
> Is that sufficient?
> 
> If we do that, we may also be able to get rid of some of the logic in
> RenderFrameImpl::OnFailedNavigation, which looks redundant with other load
> failure logic.

Your suggestion seems to work : https://codereview.chromium.org/2456353002/
I am not very knowledgeable in this code though. What part of
RenderFrameImpl::OnFailedNavigation do you think could be replaced by this call?

Secondly, I have a question. Could we let the error page loading taking place,
no matter if a fallback content is displayed or not by the parent frame? By
doing this, there is no need to try to manually stop the frame loading.
Furthermore, this seems to be what happens when PlzNavigate is not used.

[Nate Chapin, 2016-10-28 16:49:18]

On 2016/10/28 15:55:04, arthursonzogni wrote:
> On 2016/10/27 16:44:02, Nate Chapin wrote:
> >
>
https://codereview.chromium.org/2439903003/diff/180001/third_party/WebKit/Sou...
> > File third_party/WebKit/Source/web/WebLocalFrameImpl.cpp (right):
> > 
> >
>
https://codereview.chromium.org/2439903003/diff/180001/third_party/WebKit/Sou...
> > third_party/WebKit/Source/web/WebLocalFrameImpl.cpp:2070:
> > frame()->owner()->renderFallbackContent();
> > Sorry, I was suggesting, instead of calling renderFallbackContent() here,
have
> > this function call:
> > 
> > frame()->loader().loadFailed();
> > 
> > Is that sufficient?
> > 
> > If we do that, we may also be able to get rid of some of the logic in
> > RenderFrameImpl::OnFailedNavigation, which looks redundant with other load
> > failure logic.
> 
> Your suggestion seems to work : https://codereview.chromium.org/2456353002/
> I am not very knowledgeable in this code though. What part of
> RenderFrameImpl::OnFailedNavigation do you think could be replaced by this
call?
> 
> Secondly, I have a question. Could we let the error page loading taking place,
> no matter if a fallback content is displayed or not by the parent frame? By
> doing this, there is no need to try to manually stop the frame loading.
> Furthermore, this seems to be what happens when PlzNavigate is not used.

[Nate Chapin, 2016-10-28 16:49:18]

On 2016/10/28 15:55:04, arthursonzogni wrote:
> On 2016/10/27 16:44:02, Nate Chapin wrote:
> >
>
https://codereview.chromium.org/2439903003/diff/180001/third_party/WebKit/Sou...
> > File third_party/WebKit/Source/web/WebLocalFrameImpl.cpp (right):
> > 
> >
>
https://codereview.chromium.org/2439903003/diff/180001/third_party/WebKit/Sou...
> > third_party/WebKit/Source/web/WebLocalFrameImpl.cpp:2070:
> > frame()->owner()->renderFallbackContent();
> > Sorry, I was suggesting, instead of calling renderFallbackContent() here,
have
> > this function call:
> > 
> > frame()->loader().loadFailed();
> > 
> > Is that sufficient?
> > 
> > If we do that, we may also be able to get rid of some of the logic in
> > RenderFrameImpl::OnFailedNavigation, which looks redundant with other load
> > failure logic.
> 
> Your suggestion seems to work : https://codereview.chromium.org/2456353002/
> I am not very knowledgeable in this code though. What part of
> RenderFrameImpl::OnFailedNavigation do you think could be replaced by this
call?
> 
> Secondly, I have a question. Could we let the error page loading taking place,
> no matter if a fallback content is displayed or not by the parent frame? By
> doing this, there is no need to try to manually stop the frame loading.
> Furthermore, this seems to be what happens when PlzNavigate is not used.

[Nate Chapin, 2016-10-28 16:55:34]

On 2016/10/28 16:49:18, Nate Chapin wrote:
> On 2016/10/28 15:55:04, arthursonzogni wrote:
> > On 2016/10/27 16:44:02, Nate Chapin wrote:
> > >
> >
>
https://codereview.chromium.org/2439903003/diff/180001/third_party/WebKit/Sou...
> > > File third_party/WebKit/Source/web/WebLocalFrameImpl.cpp (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2439903003/diff/180001/third_party/WebKit/Sou...
> > > third_party/WebKit/Source/web/WebLocalFrameImpl.cpp:2070:
> > > frame()->owner()->renderFallbackContent();
> > > Sorry, I was suggesting, instead of calling renderFallbackContent() here,
> have
> > > this function call:
> > > 
> > > frame()->loader().loadFailed();
> > > 
> > > Is that sufficient?
> > > 
> > > If we do that, we may also be able to get rid of some of the logic in
> > > RenderFrameImpl::OnFailedNavigation, which looks redundant with other load
> > > failure logic.
> > 
> > Your suggestion seems to work : https://codereview.chromium.org/2456353002/
> > I am not very knowledgeable in this code though. What part of
> > RenderFrameImpl::OnFailedNavigation do you think could be replaced by this
> call?
> > 
> > Secondly, I have a question. Could we let the error page loading taking
place,
> > no matter if a fallback content is displayed or not by the parent frame? By
> > doing this, there is no need to try to manually stop the frame loading.
> > Furthermore, this seems to be what happens when PlzNavigate is not used.

I think most of this complexity is that PlzNavigate is trying to inform blink
that a provisional load failed, without actually doing what blink considers a
provisonal load. We should eventually unify their definitions (probably on
PlzNavigate's, since blink's provisional loading is going away eventually?)

The loadFailed() trick is probably sufficient for now, though. If you want to
try to get the non-PlzNavigate behavior of showing the error page, you can
probably drop the early return in RenderFrameImpl::OnFailedNavigation?

[arthursonzogni, 2016-11-02 12:49:03]

I added the patch that use FrameLoader::loadFail.

On 2016/10/28 16:55:34, Nate Chapin wrote:
> I think most of this complexity is that PlzNavigate is trying to inform blink
> that a provisional load failed, without actually doing what blink considers a
> provisonal load. We should eventually unify their definitions (probably on
> PlzNavigate's, since blink's provisional loading is going away eventually?)

Yes, when PlzNavigate launches, the concept of provisional load can be removed
from Blink.

On 2016/10/28 16:55:34, Nate Chapin wrote:
> The loadFailed() trick is probably sufficient for now, though. If you want to
> try to get the non-PlzNavigate behavior of showing the error page, you can
> probably drop the early return in RenderFrameImpl::OnFailedNavigation?

Okay, so we can keep FrameLoader::loadFailed for the moment, it will display
fallback content and stop the frame navigation.
I don't particularly want to adopt the non-PlzNavigate behavior. It is just that
it led to a tinier patch and we didn't have to worry about how to stop a frame
navigation. But if we are certain that FrameLoader::loadFailed is okay, we can
keep it like this.

[Nate Chapin, 2016-11-02 17:18:10]

Almost there, one more nitpick...

https://codereview.chromium.org/2439903003/diff/200001/third_party/WebKit/pub...
File third_party/WebKit/public/web/WebLocalFrame.h (right):

https://codereview.chromium.org/2439903003/diff/200001/third_party/WebKit/pub...
third_party/WebKit/public/web/WebLocalFrame.h:128: virtual bool
canRenderFallbackContent() const = 0;
I don't really like having this on the public/ api.

Could we just have:

virtual bool maybeRenderFallbackContent(const WebURLError&)

...so that we don't need both of these functions?

[arthursonzogni, 2016-11-03 09:17:12]

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

[commit-bot: I haz the power, 2016-11-03 09:17:28]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-03 11:18:00]

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

[commit-bot: I haz the power, 2016-11-03 11:18:01]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT,
no build URL)

[arthursonzogni, 2016-11-03 15:10:42]

Thanks Nate, I did your suggestion of merging the two functions.

https://codereview.chromium.org/2439903003/diff/200001/third_party/WebKit/pub...
File third_party/WebKit/public/web/WebLocalFrame.h (right):

https://codereview.chromium.org/2439903003/diff/200001/third_party/WebKit/pub...
third_party/WebKit/public/web/WebLocalFrame.h:128: virtual bool
canRenderFallbackContent() const = 0;
On 2016/11/02 17:18:09, Nate Chapin wrote:
> I don't really like having this on the public/ api.
> 
> Could we just have:
> 
> virtual bool maybeRenderFallbackContent(const WebURLError&)
> 
> ...so that we don't need both of these functions?

Done.

[Nate Chapin, 2016-11-03 16:39:29]

LGTM, thanks

[clamy, 2016-11-04 14:47:12]

Thanks! A few comments below.

https://codereview.chromium.org/2439903003/diff/220001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2439903003/diff/220001/content/renderer/rende...
content/renderer/render_frame_impl.cc:5075: // If it is possible, there is no
more need to load an error page since it
Nit: Rewrite the second sentence as "When that happens, don't load an error
page..."

https://codereview.chromium.org/2439903003/diff/220001/content/renderer/rende...
content/renderer/render_frame_impl.cc:5078: browser_side_navigation_pending_ =
false;
Will maybeRenderFallbackContent eventually lead to a DidCommitProvisionalLoad or
DidStopLoading IPC be sent? If not, we should send a FrameHostMsg_DidStopLoading
here, since the browser expects us to be loading something and needs to be told
that the load has stopped.

[arthursonzogni, 2016-11-07 09:56:23]

Patchset #8 (id:240001) has been deleted

[arthursonzogni, 2016-11-07 09:59:07]

Thanks!

https://codereview.chromium.org/2439903003/diff/220001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/2439903003/diff/220001/content/renderer/rende...
content/renderer/render_frame_impl.cc:5075: // If it is possible, there is no
more need to load an error page since it
On 2016/11/04 14:47:12, clamy (slow) wrote:
> Nit: Rewrite the second sentence as "When that happens, don't load an error
> page..."

Done.

https://codereview.chromium.org/2439903003/diff/220001/content/renderer/rende...
content/renderer/render_frame_impl.cc:5078: browser_side_navigation_pending_ =
false;
On 2016/11/04 14:47:11, clamy (slow) wrote:
> Will maybeRenderFallbackContent eventually lead to a DidCommitProvisionalLoad
or
> DidStopLoading IPC be sent? If not, we should send a
FrameHostMsg_DidStopLoading
> here, since the browser expects us to be loading something and needs to be
told
> that the load has stopped.

Yes it is. The list of calls is:
 * WebLocalFrameImpl::maybeRenderFallbackContent
 * FrameLoader::loadFailed
 * ProgressTracker::progressCompleted
 * FrameLoaderClientImpl::didstopLoading
 * RenderFrameImpl::didStopLoading

It leads to send a DidStopLoading IPC

[clamy, 2016-11-07 12:31:22]

Thanks! Lgtm.

[arthursonzogni, 2016-11-07 12:44:07]

The CQ bit was checked by arthursonzogni@chromium.org

[arthursonzogni, 2016-11-07 12:44:08]

The patchset sent to the CQ was uploaded after l-g-t-m from japhet@chromium.org
Link to the patchset: https://codereview.chromium.org/2439903003/#ps260001
(title: "Nit (+rebase)")

[commit-bot: I haz the power, 2016-11-07 12:44:19]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-07 14:13:34]

Description was changed from

==========
PlzNavigate: Allow frames to fallback to alternative content.

This CL gives frames the opportunity to show alternative content when
<object data="..."> navigation fails instead of displaying an error
page.

It fixes a collection of tests(see bug description) that fail with the
--enable-browser-side-navigation flag.

BUG=657834
==========

to

==========
PlzNavigate: Allow frames to fallback to alternative content.

This CL gives frames the opportunity to show alternative content when
<object data="..."> navigation fails instead of displaying an error
page.

It fixes a collection of tests(see bug description) that fail with the
--enable-browser-side-navigation flag.

BUG=657834
==========

[commit-bot: I haz the power, 2016-11-07 14:13:35]

Committed patchset #8 (id:260001)

[commit-bot: I haz the power, 2016-11-07 14:16:48]

Description was changed from

==========
PlzNavigate: Allow frames to fallback to alternative content.

This CL gives frames the opportunity to show alternative content when
<object data="..."> navigation fails instead of displaying an error
page.

It fixes a collection of tests(see bug description) that fail with the
--enable-browser-side-navigation flag.

BUG=657834
==========

to

==========
PlzNavigate: Allow frames to fallback to alternative content.

This CL gives frames the opportunity to show alternative content when
<object data="..."> navigation fails instead of displaying an error
page.

It fixes a collection of tests(see bug description) that fail with the
--enable-browser-side-navigation flag.

BUG=657834

Committed: https://crrev.com/bb2aaf9abe13bdd12fbba17fba9901d430057ca0
Cr-Commit-Position: refs/heads/master@{#430266}
==========

[commit-bot: I haz the power, 2016-11-07 14:16:49]

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