Bugzilla

I'm pausing work on this for a bit but here are some notes.

In the old code (as per kashav's comment), we used to add a listener to [correctly handle browser.loadURI() calls from foreign code](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/browser/components/sessionstore/ContentRestore.jsm#155-169). In `onStartRequest`, the listener would call ContentSessionStore's `restoreTabContentStarted` and pass a callback (more on it later). Then, it would call another [callback to notify the parent that the load started](https://searchfox.org/mozilla-central/rev/6e630edb09c3ab06d0103665b16c9ea7dce782c5/browser/components/sessionstore/ContentSessionStore.jsm#600-605). This callback would eventually call cause `SessionStoreInternal._restoreTabContentStarted` to be called. 

So, roughly this is the code that get's invoked (to visualize it):
```
this._progressListener = new ProgressListener(this.docShell, {
      onStartRequest: () => {
        // Some code called browser.loadURI() on a pending tab. It's safe to
        // assume we don't care about restoring scroll or form data.
        this._tabData = null;

        // Listen for the tab to finish loading.
        this.restoreTabContentStarted(callbacks.onLoadFinished);

        // Notify the parent.
        callbacks.onLoadStarted();
      },
    });
```
`ContentSessionStore.restoreTabContentStarted` does a few things:
- uninstalls the reload listener
- uninstalls the old progress listener (with `onStartRequest` callback)
- adds a new progress listener with `onStopRequest` callback, which just calls `onLoadFinished` (see below).

`callbacks.onLoadStarted()` is 
```
      onLoadStarted: () => {
        // Notify the parent that the tab is no longer pending.
        this.mm.sendAsyncMessage("SessionStore:restoreTabContentStarted", {
          epoch,
        });
      },
```
which eventually calls `SessionStoreInternal._restoreTabContentStarted`.

and `callbacks.onLoadFinished` is
```
    onLoadFinished: () => {
        // Tell SessionStore.jsm that it may want to restore some more tabs,
        // since it restores a max of MAX_CONCURRENT_TAB_RESTORES at a time.
        this.mm.sendAsyncMessage("SessionStore:restoreTabContentComplete", {
          epoch,
        });
      },
```
which eventually calls `SessionStoreInternal._restoreTabContentComplete`.

So the old code roughly does the following:
- add a progress listener with onStartRequest callback
- when onStartRequest gets called, call `restoreTabContentStarted` 
-- uninstall old listeners and install a new one with onStopRequest, which will eventually call `SessionStoreInternal._restoreTabContentComplete`.
- notify the parent that the load has started by sending a message which eventually causes `SessionStoreInternal._restoreTabContentStarted` to be called.

And again, repeating everything but with the correct ordering:
- add a progress listener with onStartRequest
- onStartRequest gets called, uninstall old listeners and install a new listener with onStopRequest
- notify the parent that the load has started (causes `SessionStoreInternal._restoreTabContentStarted` to be called)
- sometime later, onStopRequest in the new listener gets called, and eventually we execute code in `SessionStoreInternal._restoreTabContentComplete`.

As per convo with kashav in the DM, this is the idea of how events are to fold out when we are restoring a tab and loadURI gets called:
- we start a restore
- we get a STATE_START during the restore history phase (~and restore tab content phase?~), which signifies some foreign code attempted to load a url in the browser (that differs from the one being restored?)
- we clear our restore data, since we won't be restoring anymore, and remove listeners and other stuff associated with the restore
- when that new load finishes we still fire the "restore complete" events

I'm pausing work on this for a bit but here are some notes.

In the old code (as per kashav's comment), we used to add a listener to [correctly handle browser.loadURI() calls from foreign code](https://searchfox.org/mozilla-central/rev/2f109387cc6886859d3f985ed9aca352fff653b8/browser/components/sessionstore/ContentRestore.jsm#155-169). In `onStartRequest`, the listener would call ContentSessionStore's `restoreTabContentStarted` and pass a callback (more on it later). Then, it would call another [callback to notify the parent that the load started](https://searchfox.org/mozilla-central/rev/6e630edb09c3ab06d0103665b16c9ea7dce782c5/browser/components/sessionstore/ContentSessionStore.jsm#600-605). This callback would eventually call cause `SessionStoreInternal._restoreTabContentStarted` to be called. 

So, roughly this is the code that get's invoked (to visualize it):
```
this._progressListener = new ProgressListener(this.docShell, {
      onStartRequest: () => {
        // Some code called browser.loadURI() on a pending tab. It's safe to
        // assume we don't care about restoring scroll or form data.
        this._tabData = null;

        // Listen for the tab to finish loading.
        this.restoreTabContentStarted(callbacks.onLoadFinished);

        // Notify the parent.
        callbacks.onLoadStarted();
      },
    });
```
`ContentSessionStore.restoreTabContentStarted` does a few things:
- uninstalls the reload listener
- uninstalls the old progress listener (with `onStartRequest` callback)
- adds a new progress listener with `onStopRequest` callback, which just calls `onLoadFinished` (see below).

`callbacks.onLoadStarted()` is 
```
      onLoadStarted: () => {
        // Notify the parent that the tab is no longer pending.
        this.mm.sendAsyncMessage("SessionStore:restoreTabContentStarted", {
          epoch,
        });
      },
```
which eventually calls `SessionStoreInternal._restoreTabContentStarted`.

and `callbacks.onLoadFinished` is
```
    onLoadFinished: () => {
        // Tell SessionStore.jsm that it may want to restore some more tabs,
        // since it restores a max of MAX_CONCURRENT_TAB_RESTORES at a time.
        this.mm.sendAsyncMessage("SessionStore:restoreTabContentComplete", {
          epoch,
        });
      },
```
which eventually calls `SessionStoreInternal._restoreTabContentComplete`.

So the old code roughly does the following:
- add a progress listener with onStartRequest callback
- when onStartRequest gets called, call `restoreTabContentStarted` 
  - uninstall old listeners and install a new one with onStopRequest, which will eventually call `SessionStoreInternal._restoreTabContentComplete`.
- notify the parent that the load has started by sending a message which eventually causes `SessionStoreInternal._restoreTabContentStarted` to be called.

And again, repeating everything but with the correct ordering:
- add a progress listener with onStartRequest
- onStartRequest gets called, uninstall old listeners and install a new listener with onStopRequest
- notify the parent that the load has started (causes `SessionStoreInternal._restoreTabContentStarted` to be called)
- sometime later, onStopRequest in the new listener gets called, and eventually we execute code in `SessionStoreInternal._restoreTabContentComplete`.

As per convo with kashav in the DM, this is the idea of how events are to fold out when we are restoring a tab and loadURI gets called:
- we start a restore
- we get a STATE_START during the restore history phase (~and restore tab content phase?~), which signifies some foreign code attempted to load a url in the browser (that differs from the one being restored?)
- we clear our restore data, since we won't be restoring anymore, and remove listeners and other stuff associated with the restore
- when that new load finishes we still fire the "restore complete" events