3

I have asked this question before and I got two answers:

  1. It's impossible, don't forget to file a bug report!

  2. It's possible by messing around with localhost requests.

Quote from Stefan Arentz:

There is no easy answer here. The WKWebView cannot be archived and it does also not participate in UI state preservation/restoration. You already discovered this.

For Firefox for iOS we took a different route to work around these limitations. This far from ideal but it does work.

When we restore a tab that has session info (previously visited pages) attached, we load a special html page from a local web server (running on localhost) that modifies the push state of the page and pushes previously visited URLs on the history stack.

Because these URLs need to be of same origin, we basically push urls like `http://localhost:1234/history/item?url=http://original.url.com

In our UI we translate this to display original.url.com. When the user goes back in history to load these, we intercept and instead of loading the page from localhost, we load the original page.

It is a big hack but that is all we have at this point.

Problem is, I downloaded the Firefox app for iOS and tested whether it restores a tab or not. I found out that after you close the app and re-open it all is lost. The option to go back isn't there.

This is a big deal for me and the web browser that I'm building. So, I'm hoping for a third answer, a better solution. I do feel optimistic because more than a year has passed.

Going back to using UIWebView isn't an option because of poor performance.

Community
  • 1
  • 1
Vulkan
  • 1,004
  • 16
  • 44
  • Why don't you keep track of the history stack yourself using the WKWebView delegate? – max_ May 15 '16 at 17:28
  • Even if I do so, how will that solve the problem? – Vulkan May 15 '16 at 17:32
  • Hmm... this gave me an idea but it feels like you haven't understood the problem yet. Thanks anyway! – Vulkan May 15 '16 at 17:42
  • 1
    Keeping track of the history will mean that when the user hits the back/forward button you can redirect the request to the correct url even if the user has closed the web view and reopened it. Yes, this will not maintain the exact state of the page, but it will let you create another instance of a WKWebView with its history intact, as per your question. – max_ May 15 '16 at 17:49
  • Sorry for being biassed. I thought of the same thing back when UIWebView was still a thing. I couldn't implement this solution because there was no way to access the backForwardList hence my record of the history was not reliable but now it seems a viable solution. Back then I wasn't familiar with UIWebView state preservation/restoration. – Vulkan May 15 '16 at 18:32
  • This method fails miserably when combined with javascript window.history.back(); .forward() and .go(n) methods. Suppose a history stack of h = [0, 1, 2] and a new WKWebView with a new history stack h' = [2]. The user presses back to go to page 1. A new request is loaded and the h' stack looks like this: h' = [2, 1]. If the new page uses the back/forward/go javascript methods the history gets reversed. The history.back[]; actually goes forward! – Vulkan May 19 '16 at 11:23
  • So, keeping track of the history won't work for everyone. – Vulkan May 19 '16 at 11:30

0 Answers0