1668084 - Fix browser_586068-reload.js for Fission+SHIP

Status: RESOLVED DUPLICATE of bug 1597499

(Core :: DOM: Navigation, defect, P2)

Description

[u608768]

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.

Comment 1

[u608768]

Attachment: Bug 1668084 - Add a symmetrical parent-process ProgressListener for tab restores with sessionHistoryInParent, r?peterv

Comment 2

[u608768]

Attachment: Bug 1668084 - Ensure we're dispatching SSTabRestored events for remoteness changes when SHIP is enabled, r?nika

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.

Comment 4

[Neha Kochar [:neha]]

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

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

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++

Comment 7

[Neha Kochar [:neha]]

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

Comment 8

[u608768]

Will enable this in bug 1597499.