New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 640631 link

Starred by 1 user
Status: Fixed
Owner:
█ ananta@chromium.org
Last visit > 30 days ago
Closed: Feb 2017
Cc:
clamy@chromium.org
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

PlzNavigate: Pattern of WebFrameClient callbacks for renderer-initiated failed navigations does not match non-PlzNavigate behavior

Project Member Reported by blundell@chromium.org, Aug 24 2016 
For renderer-side failed navigations, the current behavior results in WebFrameClient receiving a callback to didStartProvisionalLoad() followed by a callback to didFailProvisionalLoad().

However, in PlzNavigate the navigation failure is detected in the browser, not in the renderer. Neither of the above callbacks occur. Instead, in some cases the didFailLoad() callback occurs instead as a result of FrameTreeNode::ResetNavigationRequest() sending the FrameMsg_Stop IPC.

This difference in behavior has the concrete impact of causing layout tests that have renderer-initiated failed navigations to fail because the sequence of output produced by WebFrameTestClient doesn't match expectations. It's possible that it also has effects on production code.
Project Member

Comment 1 by bugdroid1@chromium.org, Aug 25 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/76f7fed1ec182373a0cde7bb2485ed4636f4b62f

commit 76f7fed1ec182373a0cde7bb2485ed4636f4b62f
Author: blundell <blundell@chromium.org>
Date: Thu Aug 25 12:56:02 2016

PlzNavigate: Triage renderer-initiated failed navigation tests

These tests fail due to WebFrameClient having a difference sequence of
callbacks, which is itself due to the fact that in PlzNavigate, the
navigation failure is detected in the browser.

BUG= 640631 

Review-Url: https://codereview.chromium.org/2278563002
Cr-Commit-Position: refs/heads/master@{#414410}

[modify] https://crrev.com/76f7fed1ec182373a0cde7bb2485ed4636f4b62f/third_party/WebKit/LayoutTests/FlagExpectations/enable-browser-side-navigation

Comment 2 by ananta@chromium.org, Feb 4 2017

Owner: ananta@chromium.org
Status: Assigned (was: Available)
Project Member

Comment 3 by bugdroid1@chromium.org, Feb 9 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a85730c84d15b89b04bf58ed6efda2050c9de619

commit a85730c84d15b89b04bf58ed6efda2050c9de619
Author: ananta <ananta@chromium.org>
Date: Thu Feb 09 21:23:10 2017

PlzNavigate: Invoke didFailProvisionalLoad() in the renderer when a navigation request is cancelled or fails

Navigation requests can be cancelled or they could fail. In the latter case we do send an IPC FrameMsg_FailedNavigation
to the renderer where we display error pages etc. However we don't invoke didFailProvisionalLoad() which causes a number
of blink layout tests to fail. In any case we send out a didStartProvisionalLoad() notification in blink when plznavigate
handles navigation requests. We can safely call didFailProvisionalLoad() notification when the navigation fails.

For cancelled navigations like external URLs etc we invoke the didFailProvisionalLoad() handler for client side navigations in FrameLoader::stopAllLoaders()

BUG= 640631 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2687593002
Cr-Commit-Position: refs/heads/master@{#449412}

[modify] https://crrev.com/a85730c84d15b89b04bf58ed6efda2050c9de619/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/a85730c84d15b89b04bf58ed6efda2050c9de619/third_party/WebKit/LayoutTests/FlagExpectations/enable-browser-side-navigation
[modify] https://crrev.com/a85730c84d15b89b04bf58ed6efda2050c9de619/third_party/WebKit/Source/core/loader/FrameLoader.cpp

Comment 4 by ananta@chromium.org, Feb 9 2017

Status: Fixed (was: Assigned)
►

Sign in to add a comment