It hangs waiting for SSTabRestored events for restored tabs that are loaded via Location.reload(). This event is dispatched in response to STATE_STOP progress events seen by ContentRestore.jsm#ProgressListener. This listener lives in the content process, but since these loads may trigger a process switch, we may throwaway the listener prior to the completion of the load. A quick solution is add the listener to the browser element in the parent.

Tests rely on seeing this event, but bug 1656997 made it so we never actually
call |SessionStore.restoreTab| for remoteness updates when the SHIP pref is
enabled. This reverts the changes from D86073 in favor of D86057.

Still fails with Kashav/Randell's patches in bug 1673617.

Per discussion, this times out after reloading the first tab due to sessionstore using old-style process switch, and we also get a documentchannel process switch.

The solution here is to get rid of the old-style switch (messagemanager), and implement a way for a content process to ask the parent for state data for sub-frames.

Related to andreas' bug 1572084

May make sense to implement in C++

This will be done by Kashav in conjunction with the rewrite of session restore function in Bug 1597499.

Will enable this in bug 1597499.