eugenebut@: do you still have time to help take a look at these?

I added some logging to testBackForwardNavigation.

The following URLs are committed in setUp:

about:blank?for=chrome%3A%2F%2Fnewtab%2F
http://127.0.0.1:53838/url1.test/
http://127.0.0.1:53838/url2.test/

The following URLs are committed after PurgeCachedWebViewPages() call:

file:///...../ios_chrome_web_egtests.app/restore_session.html#session=%7B%22offset%22%3A0%2C%22titles%22%3A%5B%22New%20Tab%22%2C%22%22%2C%22%22%5D%2C%22urls%22%3A%5B%22about%3Ablank%3Ffor%3Dchrome%253A%252F%252Fnewtab%252F%22%2C%22http%3A%2F%2F127.0.0.1%3A53879%2Furl1.test%2F%22%2C%22http%3A%2F%2F127.0.0.1%3A53879%2Furl2.test%2F%22%5D%7D

file:///...../ios_chrome_web_egtests.app/restore_session.html#targetUrl=http%3A%2F%2F127.0.0.1%3A53879%2Furl2.test%2F

http://127.0.0.1:53879/url2.test/

The following navigation items exist before tapping back button:

file:///...../ios_chrome_web_egtests.app/restore_session.html#session=%7B%22offset%22%3A0%2C%22titles%22%3A%5B%22New%20Tab%22%2C%22%22%2C%22%22%5D%2C%22urls%22%3A%5B%22about%3Ablank%3Ffor%3Dchrome%253A%252F%252Fnewtab%252F%22%2C%22http%3A%2F%2F127.0.0.1%3A54025%2Furl1.test%2F%22%2C%22http%3A%2F%2F127.0.0.1%3A54025%2Furl2.test%2F%22%5D%7D
file:///...../ios_chrome_web_egtests.app/restore_session.html#targetUrl=http%3A%2F%2F127.0.0.1%3A54025%2Furl1.test%2F
http://127.0.0.1:54025/url2.test/


The following URLs are committed after tapping back button:

file:///......./ios_chrome_web_egtests.app/restore_session.html#targetUrl=http%3A%2F%2F127.0.0.1%3A53879%2Furl1.test%2F

file:///......./ios_chrome_web_egtests.app/restore_session.html#targetUrl=http%3A%2F%2F127.0.0.1%3A53879%2Furl1.test%2F



Danyao, do you think Back Button was called before restoration is complete, or the restoration itself has failed?

I was able to reproduce the steps from Comment #3 today. Restoration is done when the Back button is called because we can see that "http://127.0.0.1:53879/url2.test/" finished loading.

When Back button is tapped, the following happens:
1) file:///......./ios_chrome_web_egtests.app/restore_session.html#targetUrl=http%3A%2F%2F127.0.0.1%3A50532%2Furl1.test%2F is started, committed, then finished.
2) Another navigation to file:///......./ios_chrome_web_egtests.app/restore_session.html#targetUrl=http%3A%2F%2F127.0.0.1%3A50532%2Furl1.test%2F is started, committed, then finished.
3) didStart for http://127.0.0.1:50532/url1.test/

Omnibox URL is updated to "http://127.0.0.1:50532/url1.test/" after navigation (1) is committed. I don't know why there are 2 navigations to the restored "url1.test" session entry, but that is not the cause of the problem. I need to figure out who's triggering the omnibox URL update and see if it makes sense to skip.

The omnibox URL update happens because after the restore session URL is committed, NavigationManager::GetLastCommittedItem() returns the navigation item for url1, even though the network request for http://127.0.0.1:50532/url1.test has not yet responded. This makes sense to me because if user clicks on "stop" at this point and reload, they should see url1 reloaded instead of url2.

To truly test the pending URL behavior, we need to create navigation history that is not in WKWebView's bfcache. This is very hard to do set up in tests. So after talking to eugenebut@, I think
we will not make these tests blocking the slim nav launch.

For posterity, WKWebView does not cache HTTPS request with "Cache-Control: no-store" response header. See https://github.com/WebKit/webkit/blob/master/Source/WebCore/history/PageCache.cpp#L128. This option doesn't work now due to challenges with installing test certs in iOS Simulator: https://docs.google.com/document/d/1ySB97OiHE-kDeI8dra5ftmtBQbbMEwtQQ1785Jr-n-s/edit#heading=h.l1c93ji2jioh

RBS should not be marked available. Assigning to eugenebut for further triage. Please remove RBS if no longer applicable.

Removed RBS label because slim nav is not going in M72. We're using Proj-WKBackForwardListBlocker to tracking slim nav blockers.