Override cache policy when changing a reload to a back/forward navigation.

Override cache policy when changing a reload to a back/forward navigation.

In some cases, the RenderView performs a history navigation in response to a
reload when the WebFrame does not have the page in question committed. Override
the cache policy so the navigation revalidates the cache, rather than skipping
revalidation altogether.

BUG=331386
TEST=CrashRecoveryBrowserTest.ReloadCacheRevalidate

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=243796

[davidben, 2014-01-06 23:00:16]

This is the third of a three-legged change. Sending them all out now to get
early feedback, but they should land in order.

1. Fix some build dependencies in Chromium exposed by the Blink CL.
https://codereview.chromium.org/101203006/

2. Expose a new parameter to WebFrame::loadHistoryItem.
https://codereview.chromium.org/123133006/

[ Wait for Blink roll. ]

3. This CL: Use the new parameter in RenderViewImpl with a test.

jamesr: Primary review. (Would you be a good person to look at this? I just went
with content/renderer/OWNERS. I'd normally give navigation stuff to creis@, but
he's OOO.)
jam: chrome/ OWNERS.
rmcilroy: FYI.

I made the test check the about:crash behavior since that was the simplest test
of this codepath. I can look into write a session restore one if that would be
preferred. The relevant case for Android is when a reload occurs while the
session restore (which loads with LOAD_PREFERRING_CACHE) has yet to commit. The
reload should occur with cache revalidation.

[jamesr, 2014-01-06 23:49:25]

I am not a good reviewer for navigation related things.

[darin (slow to review), 2014-01-07 07:39:58]

LGTM

https://codereview.chromium.org/101203007/diff/1/chrome/browser/crash_recover...
File chrome/browser/crash_recovery_browsertest.cc (right):

https://codereview.chromium.org/101203007/diff/1/chrome/browser/crash_recover...
chrome/browser/crash_recovery_browsertest.cc:56:
response->AddCustomHeader("Expires", "Thu, 1 Jan 2099 00:00:00 GMT");
nit: another approach here would be to set a cache-control header with
max-age=99999 or some other big number. that way you don't have to invent a
fixed time in the way way future.

https://codereview.chromium.org/101203007/diff/1/content/renderer/render_view...
File content/renderer/render_view_impl.cc (right):

https://codereview.chromium.org/101203007/diff/1/content/renderer/render_view...
content/renderer/render_view_impl.cc:1418: cache_policy =
WebURLRequest::ReloadIgnoringCacheData;
good fix for that old bug.

[davidben, 2014-01-08 17:38:02]

CQing now that dependent CLs are in and try jobs look good.

https://codereview.chromium.org/101203007/diff/1/chrome/browser/crash_recover...
File chrome/browser/crash_recovery_browsertest.cc (right):

https://codereview.chromium.org/101203007/diff/1/chrome/browser/crash_recover...
chrome/browser/crash_recovery_browsertest.cc:56:
response->AddCustomHeader("Expires", "Thu, 1 Jan 2099 00:00:00 GMT");
On 2014/01/07 07:39:59, darin wrote:
> nit: another approach here would be to set a cache-control header with
> max-age=99999 or some other big number. that way you don't have to invent a
> fixed time in the way way future.

Ah yeah, that would be better. Done.

[commit-bot: I haz the power, 2014-01-08 17:40:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/101203007/120001

[commit-bot: I haz the power, 2014-01-08 20:22:36]

Retried try job too often on win_rel for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[davidben, 2014-01-09 02:39:45]

On 2014/01/08 20:22:36, I haz the power (commit-bot) wrote:
> Retried try job too often on win_rel for step(s) browser_tests
>
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

Ran it through a new win_rel try job and it was green.
android_dbg_triggered_tests looks like some infrastructure problem. Trying the
CQ again.

[commit-bot: I haz the power, 2014-01-09 02:43:24]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/101203007/120001

[commit-bot: I haz the power, 2014-01-09 07:32:28]

Change committed as 243796