Bug 1073165 - [e10s] TypeError: this._historyListener is null when clicking crashed tabs that were never loaded.

So I thought this would get fixed by bug 1065785 , but no dice. :/

STR:

1) In Preferences > General, configure Firefox to not load tabs until selected.

2) Open a number of tabs, and load some pages in them

3) Shut down the session

4) Reload Firefox but stay on the default selected tab

5) Find the plugin-container for the content process, and kill it - or somehow else reliably create a crash for the content process.

6) The selected tab should show the tab crashed interface. Open the Browser Console, and click on any of the background tabs that were never loaded / selected.

ER:

No error messages in the Browser Console.

AR:

The Browser Console shows:

"TypeError: this._historyListener is null". According to ttaubert in bug 1070096 comment 16:

What is _historyListener?

Seems like all usage of _historyListener is contained within ContentRestore.jsm

According to this :

// This listener is used to detect reloads on restoring tabs. Set in

// restoreHistory and removed in restoreTabContent.

We're hitting the error in restoreTabContent, when we try to call:

this._historyListener.uninstall();

Clearly, we've set it to null before this.

https://hg.mozilla.org/mozilla-central/file/63006936ab99/browser/components/sessionstore/SessionStore.jsm#l1431 <-- this looks pretty important. When you click on a tab, I think this gets called, and because tab.linkedBrowser.__SS_restoreState == TAB_STATE_NEEDS_RESTORE, we try to restore it.

I guess for crashed tabs, we should probably clear the __SS_restoreState.

Ok, that's pretty straight-forward. SessionStore hears about crashed tabs, so I guess it just needs to clear __SS_restoreState for them.

Huh. So that works. The problem with that though is that when you click on those unrestored tabs after a crash, they don't show the tab crashed page - they just show white. So maybe my solution is too naive.

Ah, ok, it's because a browser with pending="true" on it has display: none, so it's not laid out. We need to remove that pending-ness.

Ah, _resetLocalTabRestoringState in SessionStore looks relevant...

Wait, wut - I switched to using _resetLocalTabRestoringState, but now the warning is back in the console. :/

Heh, this is because I'm a fool and copy-pasted the call to _resetLocalTabRestoringState without updating the variable name of the tab I'm passing in.

Yay! It works!

Local tests pass. I don't think we need a new test here. Posting for review...