Closed Bug 916974 Opened 11 years ago Closed 10 years ago

[e10s] Session history support for e10s


(Firefox :: General, defect)

Not set



Tracking Status
e10s + ---


(Reporter: Felipe, Unassigned)


(Blocks 2 open bugs)


The session history support we currently have in e10s is very basic. Basically there's just back/forward clicking support through our simple RemoteWebNavigation code.

But session history is quite big and consists of various interfaces closely tied to the docshell (nsISH* et al).  I'm not sure if we want to replicate all of that in the parent.. I'm thinking we don't. But that might mean there's quite some work to do to make the UI work all properly.

In a straightforward implementation, we would be forwarding the data from the content to the parent through the RemoteWebNavigation. But I realized recently that most of the session-history data that would be forwarded here is also data that Session Restore is collecting and forwarding to use in the parent.

So to avoid wasting time collecting and sending the same data twice, I thought a smart implementation would be to have e10s session history be driven by Session Restore.

This could also be a Core bug depending on how the implementation goes, but I'm putting it in Firefox for now.

Cc'ing some folks who knows about session history and e10s session restore to see if that makes sense and would work out in practice. Alternative ideas are also very much welcome.
Blocks: 916975
First, what kind of chrome code accesses the session history as well? What data does it need? I agree that fetching the data twice would be bad, replicating all nsISH* structures shouldn't be the goal either.

We could for example introduce a session history module that listens for session history changes on all browsers. That means whenever the session history for a browser changes, it sends a (sync?) message including the serialized history entry.

Chrome code wanting to use this data can then just pass a browser and retrieve session history entries in a serialized format. Would that work for what you need it for?
I filed bug 931534 to do this synchronously. We can keep this bug open for an asynchronous solution in case we want to do that.
Closed: 10 years ago
Resolution: --- → WORKSFORME
Depends on: 1093373
You need to log in before you can comment on or make changes to this bug.