We have to be able to switch between content processes fairly often right now (such as when navigating away from the new tab page, Large-Allocation loads, navigating from webextension URLs to web content, and from file URLs to web content), and the current process goes through SessionStore. This design works pretty well, but has some problems. For example, you can't currently make a cross process POST load, if SessionStorage is too big we throw some of it out, and some history data is lost (IIRC?). It would be nice to implement a performant in-platform solution for process switching loads. This bug is to track that work.

Assigning this to myself for Q1 - We want this for improving our process switching story - potentially leading toward out of process window references.

I'm not sure if my understanding of GroupedSHistory at that time was 100 % correct, but I think the problem with regards to the session store described in bug 1350567 was actually existing, so it would be nice if the new implementation could avoid this right from the start if possible.

(In reply to Jan Henning [:JanH] from comment #2) > I'm not sure if my understanding of GroupedSHistory at that time was 100 % > correct, but I think the problem with regards to the session store described > in bug 1350567 was actually existing, so it would be nice if the new > implementation could avoid this right from the start if possible. The hope with the new implementation is to avoid all of the problems with previous implementations by integrating deeply with session history rather than being a synchronization layer built on top of it. This unfortunately also means it's going to be a much larger project (and unfortunately also one which I haven't had much time to work on yet). I'll make sure that we don't have that particular issue in the new version.

(In reply to Nika Layzell [:mystor] from comment #3) > (In reply to Jan Henning [:JanH] from comment #2) > > I'm not sure if my understanding of GroupedSHistory at that time was 100 % > > correct, but I think the problem with regards to the session store described > > in bug 1350567 was actually existing, so it would be nice if the new > > implementation could avoid this right from the start if possible. > > The hope with the new implementation is to avoid all of the problems with > previous implementations by integrating deeply with session history rather > than being a synchronization layer built on top of it. This unfortunately > also means it's going to be a much larger project (and unfortunately also > one which I haven't had much time to work on yet). > > I'll make sure that we don't have that particular issue in the new version. Storing all session history together in one process as you've proposed in bug 1434768 sounds like it should avoid the major pain point of the previous implementations, namely session history potentially being spread out across any number of processes.

(In reply to Jan Henning [:JanH] from comment #4) > Storing all session history together in one process as you've proposed in > bug 1434768 sounds like it should avoid the major pain point of the previous > implementations, namely session history potentially being spread out across > any number of processes. Yes, that's my current plan :-). I'm planning to move all of the session history state into the parent process. This should help remove the duplication and other issues I believe.