(Currently there is a hardcoded assertion that there is only one session per segment.) To make multi-segment sessions work, we need a way to "bounce" replayed page loads to/from about:blank. By that, I mean that once we begin replaying a single segment (i.e., extent of one main frame navigation), we should first navigate to about:blank, then kick off the initial navigation for the segment. Similarly, when switching between two segments, we bounce to about:blank before replaying the next segment. The document.referer attribute can be naively memoized in this case, and referrer data in resource headers will be deterministic and handled just like other resource load data. The motivation for this is as follows: When one document starts unloading, it can fire beforeunload events, which may produce additional nondeterminism by running scripts, loading resourecs, modal dialogs, etc. So, the document's execution is still being "replayed" and producing or consuming nondeterministic inputs from its InputCursor. But, as one page is unloading, the provisional document is loading and producing/consuming inputs from its own InputCursor. Currently, the per-page ReplayController only has one EventLoopInputDispatcher. It doesn't know how to replay two documents at once. To support multiple independent segments without bouncing to/from about:blank, the event loop input dispatcher would have to figure out an interleaving of execution between the two replaying documents so that they both behave deterministically. This seems really complicated for scenarios where the provisional document load is cancelled---such as when the user cancels the beforeunload event. Also, since the segments are independent and reorder-able, there are no guarantees about which documents are the outgoing and provisional documents.
Closing web replay-related bugs until we resume working on the feature again.