865674 - Ensure SSWindowStateReady is dispatched before the first SSTabRestored event

Status: NEW

(Firefox :: Session Restore, defect)

Description

[Tim Taubert [:ttaubert] (inactive)]

Attachment: ensure SSWindowStateReady is dispatched before the first SSTabRestored event

The patches landed in bug 615394 don't actually implement what their tests seem to imply: that SSWindowStateReady is sent before the first SSTabRestored event is fired. restoreTab() send the event right away if didStartLoad=false which then is always before SSWindowStateReady. Sometimes, if the event queue is full and the machine is slow, this can also happen if we actually load something - see bug 624384.

The attached patch ensures that SSWindowStateReady is sent after every tab's history is restored but *before* the first restoreTab() call. Additional fixes are described below:

browser_588426.js:
This test implicitly expected the restoreTab() call to happen before the SSWindowStateReady event got sent. All it needs to do is wait until the tab has properly been restored.

browser_636279.js:
The test wanted statePinned as its starting state but didn't actually wait until all tabs had been restored. The TabProgressListener therefore received state change notifications from the previous session that the test assumed to be restored already.

browser_522545.js:
The test started to fail because it implicitly expected restoreTab() to be called on the same tick as restoreHistoryPrecursor(). Therefore the userTypedValue was already set when the about:blank sent onLocationChange and caused the url bar value to be updated. I fixed this by explicitly updating url bar values if we did not actually start a load.

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 741844 [details] [diff] [review]
ensure SSWindowStateReady is dispatched before the first SSTabRestored event

Looks like this patch needs more work:

https://tbpl.mozilla.org/?tree=Try&rev=d544179732d2