[Webkit-unassigned] [Bug 131043] Web Replay: save and restore page history state at main frame navigations

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=131043





--- Comment #4 from Brian Burg <burg at cs.washington.edu>  2014-04-18 14:08:20 PST ---
I've implemented a prototype of save/restore of the back forward list. Basic details:

On capture, save current and back entries on the list.
On replay, clear the back/forward list and append saved entries. Then, tell HistoryController that the current position is the final entry.

I promoted clear() to be part of the BackForwardClient interface. The WebProcess version had already implemented this. Doing the same for WK1 is easy.

This doesn't quite work, since clear() truncates all entries except the current entry. So if we start replaying with 2 entries, clear(), then append two more entries, window.history.length will be 3 instead of 2 on replay.

Some alternatives that might work better, which I'm investigating:

One alternative is to do the same clear+append when capturing: save entries, clear all but current, then immediately append and set current cursor. But, this isn't great either: you'll have duplicate entries (at the beginning and end) representing the page that you were on when capturing started. From this point, if the program calls window.history.go(-3), the resulting navigation will be nondeterministic (depends on the page from which you started replaying).

Another alternative is to add a flag to clear() which completely empties out the back forward list, including the current item. I'm assuming this may introduce complications for other clients.

Another alternative is to add a method to completely replace the history list with a saved list. This is essentially the same as the previous alternative but adds another method to the API.

A final alternative is a variant of the first. To capture, we start by saving the back-forward list, then navigate to about:blank, restore the saved back-forward list, then kick off the initial navigation to the page we actually want to capture. To replay, we similarly navigate to about:blank, clear+append history, then do the initial navigation to the page we want to replay.

I prefer the last alternative, and am going to look at it next. Springboarding from the clean slate of about:blank between every session segment may be useful for other things, like making document.referer easy to memoize and handling replay of unload behavior.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.