Open Bug 1445464 Opened 7 years ago Updated 1 year ago

[META]Persist SessionStorage like LocalStorage by default

Categories

(Core :: Storage: localStorage & sessionStorage, enhancement, P2)

Product:
Core
Component:
Storage: localStorage & sessionStorage
Type:
enhancement

Tracking

()

People

(Reporter: nika, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: meta)

Currently we're persisting SessionStorage in an in-memory database. Unfortunately, we still end up writing this data out to disk, as it is saved by Session Restore in the Session Restore JSON file so it can be restored if the browser crashes. It would be more efficient if we instead stored it double-keyed by some sort of session ID, and then perform occasional GCs of the unused keys (such as after reading the Session REstore database on startup). This would allow us to reduce the amount of work Session Restore has to do, while also potentially simplifying the SessionStorage APIs.
Blocks: 1147820
Priority: -- → P3
Marion, could you ask someone to throw some feedback as to how they feel about this idea? This has some impact on how bug 1445459 ends up being implemented for fission.
Flags: needinfo?(mdaly)
:janv can you give Nika feedback on this plan? I think it has merit but I don't know if it will lead to any increased efficiencies.
Flags: needinfo?(mdaly) → needinfo?(jvarga)
Blocks: 1467223
Nika, if I understand your proposal correctly, you want to completely unplug SessionStorage from the Session Restore database and handle crash recovery by persisting SessionStorage like we persist LocalStorage, is that right ? Well, I think I like this idea. Actually, I would be more than happy to do this change since it touches multiple areas that I'm involved with. I don't know all the session restore internals yet, could you tell me more about session ID ? Do we need to keep multiple versions of SessionStorage data for the same origin ? Could we just persist SessionStorage like LocalStorage and then at startup load data for SessionStorage as part of crash recovery ? This can also affect the new LocalStorage implementation which is about to land soon. Originally, I assumed that SessionStorage would stay separate from LocalStorage which influenced my decisions regarding directory and filenames, either in the source code or in the storage area in user's profile directory. Andrew, I think we might need to investigate this before landing new LS.
Flags: needinfo?(nika)
Flags: needinfo?(jvarga)
Flags: needinfo?(bugmail)
(In reply to Jan Varga [:janv] from comment #3) > Nika, if I understand your proposal correctly, you want to completely unplug > SessionStorage from the Session Restore database and handle crash recovery > by persisting SessionStorage like we persist LocalStorage, is that right ? Yup, that's what I was planning to do here. > Well, I think I like this idea. > Actually, I would be more than happy to do this change since it touches > multiple areas that I'm involved with. 🎉 > I don't know all the session restore internals yet, could you tell me more > about session ID ? I don't believe that we currently associate a unique serializable ID with each SessionStore entry, but it wouldn't be hard to add one which was visible to SessionStorage in both processes & was used to save & restore this information. > Do we need to keep multiple versions of SessionStorage data for the same > origin ? No, we should not need to do this. SessionStorage is stored separately from history entries. Currently it looks something like: "https://www.messenger.com^userContextId=6": { "sp_pi": "..." } and instead we would just store a single ID for the entries which we'd use to look up from SessionStorage when restoring. We'd also probably have some sort of cleanup system where we'd request a list of all SessionStorage IDs and would choose to either retain or discard each set. > Could we just persist SessionStorage like LocalStorage and then at startup > load data for SessionStorage as part of crash recovery ? Yup! That'd be pretty great :-)
Flags: needinfo?(nika)
Blocks: 1490803
No longer blocks: 1490803
Assignee: nobody → jvarga
Component: DOM → DOM: Web Storage
Priority: P3 → P2
Summary: Persist SessionStorage like LocalStorage by default → [META]Persist SessionStorage like LocalStorage by default
No longer blocks: 1467223
Blocks: fission
No longer blocks: 1445459
Depends on: 1517090

I'm not working on this right now.

Assignee: jvarga → nobody
Flags: needinfo?(bugmail)

(In reply to :Nika Layzell (ni? for response) from comment #4)

(In reply to Jan Varga [:janv] from comment #3)

Do we need to keep multiple versions of SessionStorage data for the same
origin ?

No, we should not need to do this. SessionStorage is stored separately from
history entries. Currently it looks something like:

"https://www.messenger.com^userContextId=6": { "sp_pi": "..." }

and instead we would just store a single ID for the entries which we'd use
to look up from SessionStorage when restoring.

We'd also probably have some sort of cleanup system where we'd request a
list of all SessionStorage IDs and would choose to either retain or discard
each set.

Please, check bug 1298912, and bug 1470692 for reference.
It should be possible to recover one of multiple recent sessions. The main reason is that now it is not possible sometimes to recover the last session correctly.

Please, also check bug 1528598 (comments 1-6), bug 1524948 (comments 1-6), bug 1528604 (comments 1-6), and bug 1427928 (comments 60-62) for reference.
Firefox/session managers should be allowed to manage multiple sessions at the same time.

Flags: needinfo?(nika)
Flags: needinfo?(jvarga)

I was referring to SessionStorage not SessionStore/SessionRestore.

Flags: needinfo?(jvarga)

This bug is related specifically to SessionStorage, not to the confusingly-similarly-named SessionStore/SessionRestore.

Flags: needinfo?(nika)
Depends on: 1575025
Depends on: 1593365

SessionStorage persisted like LocalStorage needs support for having multiple origin directories for the same origin. QuotaManager storage v2 would provide that.

:janv, I assume, this will cause more work than the currently linked dependencies. Can we scope this better and add the bugs we need here?

Flags: needinfo?(jvarga)

At this stage, this mostly depends on enabling LSNG on Release and on QM v4 which will support multiple directories on disk for the same origin (required for this bug and QM v4 is being designed in a way to be easilly usable by SSNG as well).
We will add more bugs here once we get closer to actual implementation of SSNG.

Depends on: 1599979
Flags: needinfo?(jvarga)

I remove the block for fission, since SessionStorage has already supported fission now.

I would like to use this bug for tracking the SessionStorage new generation (SSNG) implementation which based on LocalStorage new generation(SSNG).

No longer blocks: fission
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.