naclag5@ Thanks for the issue.

Tested this issue on Windows 10 and Mac OS 10.12.6 on the reported version 63.0.3239.132, latest Canary 66.0.3334.0 and Stable 64.0.3282.119 and unable to reproduce the issue by following the steps mentioned in the original comment.

On relaunching Chrome again, can observe that the new posts are seen at https://www.reddit.com/r/all/new/.
Attached is the screen cast for reference.

Request you to please check and update if anything is missed from our end in reproducing the issue.

Also request you to please retry the issue on a new chrome profile without any flags/extensions and update the thread with the observations.

Thanks..

Deleted: 806589.webm 7.9 MB

	806589.webm 7.9 MB View Download

It loads cached pages when the 'Continue where you left off' is enabled as the start up option.

1. Check 'Continue where you left off' as the start up option
2. Have https://www.reddit.com/r/all/new/ open in a tab
3. Close browser
4. Relaunch browser
5. New posts are not loaded, have to manually refresh.

Chrome version: Version 64.0.3282.140
OS Version: Windows 10.0

Deleted: Feb 4 2018 12_35 AM.webm 9.4 MB

	Feb 4 2018 12_35 AM.webm 9.4 MB View Download

@emone

yes, thank you.
that's exactly the issue, I didn't even notice that @susanjun wasn't using this option and that's why it worked for her.

You need to have 'Continue where you left off' enabled!

Thank you for providing more feedback. Adding requester "susanjunia.boorgula@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce this issue on reported version 63.0.3239.132, on latest stable 64.0.3282.140 and latest canary 66.0.3339.0 using Windows 10,Ubuntu 14.04 and Mac 10.13.3

Good Build: 61.0.3163.58
Bad Build: 61.0.3163.59

Can't perform per-revison/chromium bisect for branch builds. Hence providing manual changelog.

CL: https://chromium.googlesource.com/chromium/src/+log/61.0.3163.58..61.0.3163.59?pretty=fuller&n=10000

Suspecting https://chromium-review.googlesource.com/c/chromium/src/+/625538 or https://chromium-review.googlesource.com/c/chromium/src/+/626621

cc'ing @arthursonzogni and @yhirano from respective cls.

Could someone help in assigning to appropriate owner. Thanks!

It can't be my patch: https://chromium-review.googlesource.com/c/chromium/src/+/626621
This one is about URLs with embedded credential: https://user:pass@host. It occurs only in iframes and it can only block or allow a navigation request. It doesn't deal with cache.

I don't see any suspect CL in:
https://chromium.googlesource.com/chromium/src/+log/61.0.3163.58..61.0.3163.59?pretty=fuller&n=10000

I talked with clamy@. Maybe this behavior is explainable by the function UpdateLoadFlagsWithCacheFlags(...):
```
    case FrameMsg_Navigate_Type::RESTORE:
      *load_flags |= net::LOAD_SKIP_CACHE_VALIDATION;
      break;
```

Assigning this issue to me.

Do we really want to re-validate the response and (potentially) not reusing the entry in the cache after a navigation restore? I am not sure about this.

+CC navigation folks.

Comment 7: Reloading and cache validation sounds like a question for toyoshim@.

IMO, tab restoration should load pages from disk cache as we can as possible, as we do for history navigations, that says adding net::LOAD_SKIP_CACHE_VALIDATION for RESTORE looks correct to me.

My old documents for reload investigation said that tab restoration used 'preffering cache' option that's the LOAD_SKIP_CACHE_VALIDATION today.

So, I think current behavior is expected. But before 61, tab restoration was temporarily broken for some reasons, and fixed again to load from cache around 61?

But I also could not find any suspicious CL in the revision range of comment #6. The 61.0.3163.59 is the exact min_version that enabled PlzNavigate by field trial flags, and PlzNavigate was the only feature that specified this exact version. So it might be possible that non-PlaNavigate code path was broken temporarily and the manual bisect just says enabling PlzNavigate fixes the issue?

sc00335628: can you try 61.0.3163.59 with browser-side-navigation disabled (probably from chrome://flags/#browser-side-navigation)? I guess this behavior does not depend on minor versions, but do on the flag.

Anyway the UI explanation 'Continue where you left off' makes me expect that pages will be restored from cached so that I can see the same contents I left on shutdown.

Thanks toyoshim@! That's what I felt about it.

Yes 61.0.3163.59 is the version where PlzNavigate is enabled on Beta and Stable for the first time using Finch. That explains why we don't see anything in the range.

I tried enabling/disabling PlzNavigate and it looks to me it causes this behavior to appear/disappear.

Maybe we can close this bug? It looks like chrome is now working as intended.

I'm sorry but is this seriously what you're gonna go with?
It hasn't worked like this since the inital release yet you decide to change it after ten years and say: "hurr, durr it was meant to work like this all along!"

The flag '#browser-side-navigation' is not in the newest version anymore and was changed to '#navigation-mojo-response' which has absolutely zero effect on this behavior...

@toyoshim: this code was written in 2015 based on the Blink code. I'm pretty sure that we set preferring cache at that time for restores in Blink (though Blink might have a different opinion of what a restore is). Unfortunately, Blink and Chromium repos were still separated at that time, so I'm having a hard time getting Blink to the state it was when we wrote the code in the first place.

In any case, we can easily change the policy to be something else if we want to. I do think we want to keep the load preferring cache at least for Android, since restores there include tabs killed due to memory pressure. I remember that we wanted to restore those ASAP, and loading them always from cache was better in that regard. Not sure about desktop. toyoshim@, what's your call there?

Yes, it's open for discussion. Let me know if something needs to be changed. At least, it would not be very difficult (1-2 lines change).

It may worth looking for older version of Chrome to see if it was a temporary bug or not.

On history restoration, I expect the browser to restore the URL, but also the current state of the document (input/textarea's content for instance), as if I was doing a back-forward history navigation.

---
FYI: In chrome://flags
#browser-side-navigation and #navigation-mojo-response are different thing.
#browser-side-navigation disappeared because the experiment ended. It became the default. The old code path is being suppressed.

In that case as for the input from user's perspective, there should be a new flag/option implemented to enable the old behavior...
You cannot just have something work one way for x amount of years, then change it suddenly and expect everyone to adapt without notice.

clamy:
I'm +1 to keep the TOT behavior that restores from cache, even for desktops. We may reconsider changing this behavior in the future if there are many requests from users, but it would be a separate discussion. But for now, I think major users do not want to reload all pages, but want to restore the original state that the user left at the last shutdown, as quickly as possible.

If a user prefers to reload all pages on the tab restoration, there is a choice not to use Chrome's default tab restoration feature, but to use a Chrome Extension.