1445459 - Modify Session Restore to function on the new Child/ParentSHistory APIs

Status: RESOLVED DUPLICATE of bug 1507287

(Firefox :: Session Restore, task, P2)

Description

[Nika Layzell [:nika] (ni? for response)]

In bug 1438272 we are going to be moving Session History to the parent process. This will break a large amount of Session Restore code, as it depends on reading this state from the content process.

However, we're actually going to be moving this state into a more useful place (It'll be in the parent process!) and we'll be synchronizing a more complete version of session history (e.g. form field state will be in the parent process), meaning that we can probably simplify Session Restore and avoid the polling overhead in the content process.

Comment 1

[Justin Dolske [:Dolske]]

mconley - are we starting to track front-end Fission work anywhere yet?

Comment 2

[Mike Conley (:mconley) (:⚙️)]

(In reply to Justin Dolske [:Dolske] from comment #1)
> mconley - are we starting to track front-end Fission work anywhere yet?

No, not yet. At this point, there's not a whole lot we can do until APIs become exposed to us to transition to. In the meantime, felipe is working on reducing script overhead in content process start-up time as a semi-related project.

Comment 3

[Tom Ritter [:tjr] (OOTO until April)]

As part of this I expect/hope that the SessionStore:restoreHistory/SessionStore:restoreTabContent messages will be trimmed to only send per-origin data to the relevant content process; as what I'm seeing now is more of a complete picture of all session being sent to a content process.