SessionStore keeps a session history listener per-browser to track history changes: https://searchfox.org/mozilla-central/rev/6c9ff2820d3aae683ec87c53c79e5108d54f3f76/browser/components/sessionstore/SessionStore.jsm#1002

It creates this listener after receiving a message from ContentSessionStore.jsm, which is sent in the constructor, which runs right after we load the content-sessionStore.js framescript: https://searchfox.org/mozilla-central/rev/6c9ff2820d3aae683ec87c53c79e5108d54f3f76/browser/components/sessionstore/ContentSessionStore.jsm#526, https://searchfox.org/mozilla-central/rev/6c9ff2820d3aae683ec87c53c79e5108d54f3f76/browser/components/sessionstore/SessionStore.jsm#1342-1344

The reasoning behind this change is as follows:

1. For remote="true" browsers, the disablehistory attribute was already
   always ignored, as we'd always create session history. This means
   that the PaymentUIService consumer was already a no-op before this
   patch.

2. For non-content browsers, such as those in preferences.xhtml and
   browser.xhtml this was also already a no-op, as we'd only create
   session history for toplevel content browsers, so removing the
   attribute there should be a no-op.

3. This leaves only tests which both use the attribute and have
   type="content" specified. Some manual local testing suggested that
   neither of the modified tests broke with the attribute removed.

After this change, SessionHistory will always be initialized for
toplevel content BrowsingContext instances as they are connected, which
should simplify logic such as the logic in this bug to attach to the
session history instance.

This does a few things:

1. Tracks SHistoryListeners with BrowsingContext::BrowserId instead of the
   browser's permanentKey.
2. Gets rid of the listener's _sHistoryChanges property, which is possible
   because _sHistoryChanges == false <-> _fromIdx == kNoIndex.
3. Simplifies the code that interacts with SHistoryListener in
   UpdateSessionStoreFromTablistener, and attempts to make that function a
   little more readable.

We now create the listener after receiving a "window-global-created" and destroy
it after receiving "browsing-context-discarded".

Depends on D110336

Depends on D110336

Backed out 3 changesets (bug 1700963) for Browser-chrome failures in docshell/test/browser/browser_bug1309900_crossProcessHistoryNavigation.js. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer?job_id=336540464&repo=autoland&lineNumber=2433

https://treeherder.mozilla.org/logviewer?job_id=336540032&repo=autoland&lineNumber=8376

https://treeherder.mozilla.org/logviewer?job_id=336540271&repo=autoland&lineNumber=2628

https://treeherder.mozilla.org/logviewer?job_id=336542044&repo=autoland&lineNumber=8083

https://treeherder.mozilla.org/logviewer?job_id=336543244&repo=autoland&lineNumber=19096

https://treeherder.mozilla.org/logviewer?job_id=336540504&repo=autoland&lineNumber=5402

https://treeherder.mozilla.org/logviewer?job_id=336541485&repo=autoland&lineNumber=9956

Push with failures:
https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=cda35e5543274ffa11e32e79937c36f9842566d7

Backout:
https://hg.mozilla.org/integration/autoland/rev/eb837f72d2efa15712e1238e3623b8c115856d23

Looks like the cases where we now throw errors are more common than I had thought. Handling those cases more gracefully appears to fix things.

We were also attempting to collect history in the parent for non-SHIP, which was part of the reason for the non-fission failures.

https://hg.mozilla.org/mozilla-central/rev/39820d01e6ab
https://hg.mozilla.org/mozilla-central/rev/3c654e8a366a
https://hg.mozilla.org/mozilla-central/rev/833295fd0979