Closed
Bug 1643999
Opened 4 years ago
Closed 3 years ago
Investigate automatic enabling of LSNG
Categories
(Core :: Storage: localStorage & sessionStorage, task, P1)
Core
Storage: localStorage & sessionStorage
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: janv, Assigned: janv)
Details
Some users experience unsuccessful temporary storage initialization. It is the only thing which prevents LSNG from being enabled on Release channel. While we are actively working on fixes to address initialization failures, we could experiment with enabling LSNG based on the result of temporary storage initialization in the last session.
Assignee | ||
Updated•4 years ago
|
Severity: -- → S3
Priority: -- → P1
Comment 1•4 years ago
|
||
So if I understand right the description, the approach would be to:
- persist somewhere the status of the last temporary storage initialization (where it survives a restart)
- check this status on next start and enable LSNG in case
Open questions:
- Is a single (last) good initialization enough to be sufficiently confident to enable LSNG ? Do we have an indication of the stability (or intermittency) of failures? Assuming that an initialization run does always the same things, I would think it's quite stable if things do not change frequently and randomly on disk, though.
- Is this a one way flip or would it disable LSNG after a new failure? And only after a new last failure?
And I assume we want to send an explicit message via telemetry on each switch.
Assignee | ||
Comment 2•3 years ago
|
||
We are now focusing on asynchronous storage initialization work instead, bug 1671932.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•