This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

I think something weird is happening in step (7), reloading facebook.com after turning off airplane mode. It always clobbers the WKBackForwardList entry right after it, e.g. if the history is fb -> wikipedia -> amazon, it becomes fb -> fb error page -> amazon.

Delete comment ⚐
I debugged this a bit more. I think we're running into a possible WebKit bug.

I'm able to reproduce it in an app that uses a vanilla WKWebView (attached). My setup also includes a local HTTPS server (https://localhost:8009/nostore) that always returns a response with "Cache-Control: no-store" header. This prevents the response to be cached in WKWebView's page cache.

The WKWebView is also programmed to load an error message in -|webView:didFailProvisionalNavigation| callback using this:

[self.webView loadHTMLString:@"<h1>Error!</h1>" baseURL:[NSURL URLWithString:@"https://test.com"]]; 

The steps to reproduce the bugs are the following:
1. Load https://localhost:8009/nostore
2. Load https://wikipedia.org
3. Kill the local server
4. In web view, run history.back() => Error message is now visible, URL is test.com.
5. In web view, run history.forward() => wikipedia.org loaded from page cache
6. Restart the local server
7. In web view, run history.back() => This reloads https://localhost:8009/nostore
8. In web view, run history.forward()

Now this should load wikipedia.org. But instead, it loads the error message at "test.com"! The wikipedia.org back/forward entry seems to be clobbered.

With debug message, I can see that the WKBackForwardListItem loaded in step 8 is the same object associated with wikipedia.org, but its URL is now "test.com". Another strange part is that after step 8, in the |-webView:decidePolicyForNavigationAction:| callback, NavigationAction.request.URL is actually "test.com" when I expected it to be "wikipedia.org".

Here is the annotated logs of events: https://paste.googleplex.com/6352359026327552

===

ajuma@ suggested some pointers, which I'll try now:

"As a first step make sure that process-swap-on-navigation is disabled, since that'll just complicate things (you'll need to debug across multiple WebProcesses). This is controlled by the "#define DEFAULT_PROCESS_SWAP_ON_CROSS_SITE_NAVIGATION_ENABLED" line in WebKit/Shared/WebPreferencesDefaultValues.h.

Then try setting breakpoints in HistoryController (in WebCore/loader) in the WebProcess. In particular, we must be getting a call to HistoryController::updateCurrentItem that's clobbering wikipedia's item. That won't really tell us why we're updating that item, but it'd be good to confirm that that's what's happening. Then, try stepping through HistoryController::goToItem for step 8. That should end up in HistoryController::recursiveGoToItem, which will call FrameLoader::loadItem, which should lead to FrameLoader::loadDifferentDocumentItem, and then to FrameLoader::loadWithDocumentLoader, which kicks off the navigation policy callback. Somewhere along that chain the URL must be getting switched from the one originally in the item to test.com. So try printing out the URLs along the way. To make it possible to see WTFStrings in the debugger, make sure to add a line to your ~/.lldbinit file with the equivalent of

command script import /Users/ajuma/syncWebKit/Tools/lldb/lldb_webkit.py"

Deleted: WKWebView-clobber-forward.zip 74.5 KB

WKWebView-clobber-forward.zip 74.5 KB Download

I was not able to reproduce the issue on trunk WebKit, using either the toy example or the original repro steps using chrome. I suspect the issue has been fixed, but I filed radar/47159309 anyways for Apple to track.

Is it possible to workaround this bug? The bug was marked as Proj-WKBackForwardListBlocker

It's non-trivial. Some internal state of the forward WKBackForwardListItem is corrupted probably at step 7. The only way I can think of to work around is to recreate the entire forward history using restore_session.html. I'll look tomorrow.

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

commit ef7c2b2c5189e104d0f62d0da7ffbc555a5e0106
Author: Danyao Wang <danyao@google.com>
Date: Wed Jan 16 22:21:09 2019

[Nav Experiment] Add workaround for WKWebView history clobber bug.

The clobber bug happens when the error page (loaded via -loadHTMLString)
becomes associated with the WKBackForwardListItem after the original
item the error page was loaded for, after the original item has been
reloaded in online mode.

This workaround detects when clobber is about to happen and uses
restore session to rewrite the clobbered entry and the forward history
after it. This works well if the clobber is triggered by a forward
navigation, as in the repro steps in crbug.com/887497.

Also added UMA metrics to track the frequency of this bug in the
real world.

Bug: 887497
Change-Id: I2b69d0ed8f8b9ad984b7c29aa6cb61be887f57e5
Reviewed-on: https://chromium-review.googlesource.com/c/1407607
Commit-Queue: Danyao Wang <danyao@chromium.org>
Reviewed-by: Brian White <bcwhite@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623397}
[modify] https://crrev.com/ef7c2b2c5189e104d0f62d0da7ffbc555a5e0106/ios/web/features.mm
[modify] https://crrev.com/ef7c2b2c5189e104d0f62d0da7ffbc555a5e0106/ios/web/navigation/navigation_manager_impl.h
[modify] https://crrev.com/ef7c2b2c5189e104d0f62d0da7ffbc555a5e0106/ios/web/navigation/navigation_manager_impl.mm
[modify] https://crrev.com/ef7c2b2c5189e104d0f62d0da7ffbc555a5e0106/ios/web/navigation/wk_based_navigation_manager_impl.h
[modify] https://crrev.com/ef7c2b2c5189e104d0f62d0da7ffbc555a5e0106/ios/web/navigation/wk_based_navigation_manager_impl.mm
[modify] https://crrev.com/ef7c2b2c5189e104d0f62d0da7ffbc555a5e0106/ios/web/public/features.h
[modify] https://crrev.com/ef7c2b2c5189e104d0f62d0da7ffbc555a5e0106/ios/web/web_state/ui/crw_web_controller.mm
[modify] https://crrev.com/ef7c2b2c5189e104d0f62d0da7ffbc555a5e0106/tools/metrics/histograms/histograms.xml

Since this workaround is landed, I'll move it out of slim nav blocker queue.