(In reply to Marios Titas from comment #21) > (In reply to Tom Tung [:tt, :ttung] from comment #20) > > D98296 fixes the issue on my mac book pro. Will send review requests once the try completes and its result look good. > > I tested this patch and it seems to address the issue when tested against a clean new profile. However, the issue is still there when testing against an existing old profile. Is there anyway to fix this for the old profile? Or did the old code produce a "corrupt" say `sessionstore.jsonlz4` (or whatever other file) in that profile? Thanks for testing and letting me know it seems to fix the issue on your machine as well! Unfortunately, I don't think there is an easy way to recover back once SessionStore persists its data into the disk (`sessionstore.jsonlz4`). The problem is how to determine whether the userContextId for a tab in SessionStore needs to be updated. We might be able to tell if the data in `sessionstore.jsonlz4` is needed to be updated by comparing the `userContextId` in different entries (e.g. in comment #10, we have "storage": { "https://twitter.com^userContextId=1" ...} ), but not all the sites is using SessionStorage and it can be overwrite after the further restore.
Bug 1665942 Comment 22 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Marios Titas from comment #21) > (In reply to Tom Tung [:tt, :ttung] from comment #20) > > D98296 fixes the issue on my mac book pro. Will send review requests once the try completes and its result look good. > > I tested this patch and it seems to address the issue when tested against a clean new profile. However, the issue is still there when testing against an existing old profile. Is there anyway to fix this for the old profile? Or did the old code produce a "corrupt" say `sessionstore.jsonlz4` (or whatever other file) in that profile? Thanks for testing and letting me know it seems to fix the issue on your machine as well! Unfortunately, I don't think there is an easy way to recover back once SessionStore persists its data into the disk (`sessionstore.jsonlz4`). The problem is how to determine whether the userContextId for a tab in SessionStore needs to be updated. We might be able to tell if the data in `sessionstore.jsonlz4` is needed to be updated by comparing the `userContextId` in different entries (e.g. in comment #10, we have "storage": { "https://twitter.com^userContextId=1" ...} ), but not all the sites is using SessionStorage and it can be overwrite after the further restore. To elaborate more on recovering from a "corrupt" `sessionstore.jsonlz4`, my concern is that if there are no other entries that store the correct userContextId, then we won't be able to recover the tab to the right userContextId.