This bug is not an explicit fix request, but more for tracking. The SessionStorageManager infrastructure is getting rewritten. The current approach (including this one) implicitly assumes that the root document for the current doctree is in-process, and that we can obtain the storage manager pointer for it directly.

This assumption simply will not be true with Fission, and after discussing things with some people working on this, it turns out the infrastructure is being rewritten with an architecture that supports OOP storage managers cleanly.

This bug should be watched and closed when it becomes irrelevant due to other architecture work.

:djvj and I discussed this on IRC and I indicated that we would generally expect to change the code that attempts to get the "top" SessionStorageManager to instead get a singleton service which it would provide with a "session id"/other unique indicator, plus the origin.

Right now the code wants to access the TopSessionStorageManager() because it holds all of the storage origins for the tab in question. The SessionStorageManager instance is effectively acting like an identifier.

This change could be implemented even prior to changing the SessionStorage implementation to be based on LSNG.

Kannan says replacing nsIDocShellTreeItem calls should block enabling Fission in Nightly (M6).

Andrew, what are the next steps for this bug? Do we need to fix this bug before enabling Fission Nightly (M6)? What is broken until we fix it?

Here are Kannan's instructions for replacing nsIDocShellTreeItem with BrowsingContext, but comment 1 sounds like you might take a different approach (using a singleton service):

https://wiki.mozilla.org/Project_Fission/DocShell_Tree_Replace

I believe this has been very recently fixed by Part 1 (review commit) of bug 1593246. It removes nsDocShell::TopSessionStorageManager and moves it to BrowsingContext where it knows how to use BrowsingContext's concept of top.