Temporary-containers: Preferences wiped

[stoically]

My PC frooze and after restarting and starting Firefox, all my Temporary Containers preferences where gone - and also all permanent containers. Storage from other extensions was still intact, no heckin clue how and why that happened. That's bad. Also, I've only recently introduced safety measures into the code to avoid storing corrupt storage or continuing to initialize the Add-on if storage can't be loaded. Since the permanent containers were also wiped (despite the fact that multiple Add-ons are installed that keep the container-feature active) I'm speculating that this is actually a Firefox bug and not a Temporary Containers bug.

[stoically]

I've introduced a rather radical change with just published version 0.65. I'm now relying 100% on runtime.onInstalled to initialize preferences - no other code-path is now able to reset/wipe preferences/storage. Before that I relied on storage.local.get to reject if something went wrong; but in case it would for whatever reason return an empty result instead, that could wipe the storage. Other Add-ons actually do the same and don't rely on onInstalled; so I have still no idea why I was affected, but whatever. The downside is that if people that install the Add-on the first time and for whatever reason the onInstalled event doesn't fire, they wont get a functioning Add-on unless reinstalling helps. Oh well.

[stoically]

Added a "Reset storage" button to the error-message that gets shown if storage doesn't get initialized correctly. That way users can initialize storage themselves if for whatever reason the onInstalled event isn't fired correctly.

[terrytriplett]

Can confirm. Just walked in to a frozen PC after being AFK for an hour or so. No clue what caused the lockup, but the system was unresponsive and I had to hit the reset button.

After restarting and loading Firefox, all Permanent Containers were gone and I got the "Reset storage" button mentioned above.

Not happy that I have to reconfigure everything again, but at least the reset button gave me some info about what happened, so that's something at least.

Wish I could offer more info, but that's all I have since this happened a few minutes ago.

[ag14774]

Same thing happened to me. It showed a popup that Ghostery had been updated. Immediately after that the whole computer froze. After restart, Ghostery was completely gone from add-ons, the permanent containers were reset and I got a message from temporary containers to reset storage. The built in permanent containers kept their settings though.

[roded]

Same here. Lost all container related settings.
Terrible.
Is there a way to restore these from a different profile? Copying over the extensions' stroage.js does not seem to do the trick.

[ag14774]

Just to add that it turned out I had faulty RAM that caused my laptop to crash. Each time it crashed, I would lose my settings. Now that I've fixed that, I don't have any issues anymore. But maybe there is a way to make the settings more robust so that they are not corrupted every time something goes wrong.

[hackel]

I just got bit by this bug myself. Unfortunately, restarting Firefox made no difference. All of my containers (and all of their data) were unfortunately removed.

I was actually able to piece them back together from my cookie-autodelete preferences, which contained the userContextId for each container, and manually recreate them. I then parsed the session recovery JSON in order to figure out all of the temporary containers I had open at the time, as they still had the userContextId stored, and then I manually edited my containers.json to add them back as temp containers. I was hopeful this would restore the cookies inside the containers, but no luck there.

It seems pretty clear that this issue is with the Firefox core, not this extension. It's crazy that it stores the containers in a plan json file with no backup instead of sqlite. Is there an upstream bug report for this? I couldn't find one.

Seems similar to https://github.com/mozilla/multi-account-containers/issues/1242
Possibly related to https://bugzilla.mozilla.org/show_bug.cgi?id=1468119 but in my case it happened right after a crash and an update (to 65.0b7).

[stpr-dev]

It is rather unfortunate that the issue is closed, since this is a major problem. I lost my prefs to this extension after my system froze and forced a restart. Is there no way to make the storage method more robust? Or at least providing a way of saving and restoring prefs so that there is an easy way to restore this in the event that this happens?

[Gitoffthelawn]

I sporadically experience the same issue. There seems to be no rhyme or reason to it. Once in a while, when launching Firefox, Temporary Containers issues the dreaded "Error while loading preferences" message. At that point, the only solution that works is to reset all the Temporary Containers settings and start over from scratch.

Perhaps it's time to re-open this issue?

[mlncn]

Is this really cannot reproduce? I guess it's not every time there's a hard crash. But agree that this should be reopened or escalated in Firefox; i referenced this from Mozilla's Multi-Account Containers issue. Thanks hackel for the link.

[stoically]

If someone has a way to reproduce the issue I'd be happy to open a Bug with Firefox. That would require to somehow simulate a Firefox crash I guess, not sure if/how that's possible?

The issue is closed since it actually is a Firefox bug and not something that can be solved by TC. However, I'm hoping to at least implement the backup option #86 soon, that way restoring the preferences would be possible, though currently open TCs at the time of the crash would not be removed after restoring the preferences and still have to be removed manually.

[Gitoffthelawn]

Is it confirmed to be a Firefox bug? It very well might be, although two data points make me wonder:

1. For me, no other extension ever loses its data, even if Firefox does crash.
2. For me, TC saying it lost it's data seems to happen randomly when opening Firefox, not when Firefox crashes. From what I experience, Firefox almost never crashes (for me), but I suppose it is occasionally crashing when I close it, and I just don't know, because there is no visual indication.

That would require to somehow simulate a Firefox crash I guess, not sure if/how that's possible?

If anyone wants to try forcing a crash in Firefox, I seem to remember I was able to do it a while ago by injecting some CSS that overwhelmed the browser. It was too long ago to remember the details, but If you try injecting something (using the developer tools, or possibly userContent.css or userChrome.css) like:

* { font-size: 500pt !important;}

or something that adds a background-image to each element (*), you may have success.

Another thing to try is to add CSS content ::before and ::after every element. Something like:

*::before, *::after { content: "Break Me!"; }

might work.

If you play around with it enough, there's a good chance you can make it crash.

When I discovered the Firefox bug, I chose not to report it to Mozilla because:

1. I was concerned their solution would be to weaken the developer tools or take away userChrome.css and userContent.css. If they did any of that, it would make Firefox rather useless for me.
2. I was too busy.
3. Mozilla bug reports often sit unresolved for years. Sometimes it feels like talking into a vacuum.

[stpr-dev]

@Gitoffthelawn raises a good point: I did not lose data from any other extension except containers. It is rather interesting and I wonder why.
The only way I can "reproduce" this is when my system is completely frozen (doesn't even respond to magic keys on Linux for me). Forcing a hard reboot results in a wiped container settings, though not 100% of the time.

[Gitoffthelawn]

@collectorgeneral Does Firefox issue a crash report when that happens?

[stpr-dev]

@Gitoffthelawn It is NOT Firefox that crashes. There is a bug in the Linux kernel that AMD systems might experience random freezes that will cause it to fail to respond to any sort of input. Unfortunately, it seems to me like it appears only when the system is at light load (usually web browsing). See this issue.
The unfortunate side effect is that if I had firefox running in the background (which is quite normal/likely), then when the system is reset, the preferences for ONLY this extension appears to be wiped. So it is quite interesting as to why this extension in particular seems to be the only one affected. So it isn't firefox crashing that causes the prefs to be wiped per se, but the side effect of a system lockup in my particular case.

[Gitoffthelawn]

@collectorgeneral OK, so there's a good chance FF isn't even abending (abnormal ending)... it's just not closing properly. That info seems to possibly narrow it down.

Thinking aloud, here are the possibilities:

1. Nothing to do with Firefox
2. Due to a Firefox startup issue
3. Due to an issue when Firefox does not close properly
4. Due to an issue when Firefox closes properly
5. Due to an issue when Firefox crashes

Now, just looking at your case and mine, they superficially look completely different. But they actually have a couple things in common. Combined, they might be able to narrow things down. In both our cases, it doesn't seem to be due to possibility 5. Your case eliminates possibility 4. My case might eliminate possibility 3. That points to possibilities 1 and 2. I've long suspected it's possibility 2, although possibility 3 wouldn't shock me either.

Anyways, that's some detective work without sufficient data to draw a real conclusion. But, you never know, maybe it's spot on. :grin:

[stpr-dev]

@Gitoffthelawn Interesting thought, and you may not be far off from the truth here.

On my secondary PC, I removed this extension, and despite the fact, I lost my prefs on the permanent containers extensions as well when my PC froze. This definitely has to do something with the main extension itself. If we get that fixed, perhaps this extension won't suffer from the same issue.

[Gitoffthelawn]

@collectorgeneral What do you mean by the "permanent containers extensions" and the "main extension"?

[stpr-dev]

@Gitoffthelawn Sorry I meant the official containers add-on (a.k.a Firefox Multi-Account Containers). This addon depends on it right? Its the official extension that seems to be the root cause of all the problems.

[Gitoffthelawn]

@collectorgeneral I don't have that extension installed.

[stpr-dev]

@Gitoffthelawn Apologies for the late reply, it was midterm time at university. I thought this was a requirement for this extension? Perhaps I am misunderstanding the instruction that says (Note: Multi-Account Containers Version 6.0.0 or higher is required.). Come to think of it, I haven't tried this without the official container extension to begin with! If it is not a dependency for this extension, then either these two are related or I was seeing two different problems and assumed they are. If its not, then my bad.