Bug 131043 – Web Replay: save and restore page history state at main frame navigations

• Component: History
• Status: RESOLVED LATER

[Brian Burg]

The easy part is encoding/decoding the HistoryItem tree.

[Brian Burg]

(comment got truncated)

The main use cases here are to support replaying the following:
 - introspection through History.idl interface
 - programmatic pushState/popState
 - history navigations within the document

The page cache is always disabled during capture/replay, so history navigations outside the document should just start a normal page load.

Current implementation plan is to encode history item trees in the back/forward list, and replace page's back/forward list at the beginning of replay.

[Anders Carlsson]

 One thing that we desperately need to do is to dumb down the back forward list and history in the web process - the web process should just know:

1. the length of the back forward list
2. the current index of the back forward list.

Everything else should be managed by the UI process.

[Brian Burg]

(In reply to comment #2)
>  One thing that we desperately need to do is to dumb down the back forward list and history in the web process - the web process should just know:
> 
> 1. the length of the back forward list
> 2. the current index of the back forward list.
> 
> Everything else should be managed by the UI process.

That shouldn't affect the replay strategy AFAICT. It'll require some extra plumbing to get the initial state to/from to the UI process.

[Brian Burg]

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.

[Brian Burg]

Created attachment 229901 [details]
the patch

[WebKit Commit Bot]

Attachment 229901 [details] did not pass style-queue:


ERROR: Source/WebCore/replay/SerializationMethods.cpp:201:  The parameter type should use PassRefPtr instead of RefPtr.  [readability/pass_ptr] [5]
ERROR: Source/WebCore/replay/SerializationMethods.cpp:288:  The parameter type should use PassRefPtr instead of RefPtr.  [readability/pass_ptr] [5]
ERROR: Source/WebCore/replay/SerializationMethods.cpp:696:  The parameter type should use PassRefPtr instead of RefPtr.  [readability/pass_ptr] [5]
ERROR: Source/WebCore/replay/SerializationMethods.h:78:  The parameter type should use PassRefPtr instead of RefPtr.  [readability/pass_ptr] [5]
ERROR: Source/WebCore/replay/SerializationMethods.h:85:  The parameter type should use PassRefPtr instead of RefPtr.  [readability/pass_ptr] [5]
ERROR: Source/WebCore/replay/SerializationMethods.h:141:  The parameter type should use PassRefPtr instead of RefPtr.  [readability/pass_ptr] [5]
Total errors found: 6 in 26 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Blaze Burg]

Closing web replay-related bugs until we resume working on the feature again.