Importing data from other computer corrupts the container extension somehow

[mcepl]

Both computers use MozillaFirefox-66.0-1.1.x86_64 from the openSUSE/Tumbleweed repository. On one computer I export my containers to ffcontainers-eguebw4d.default-1548008691899-20190402.zip On other computer I switch off Firefox and import the data. The result is something which looks very much like https://github.com/mozilla/multi-account-containers/issues/1321 (non-functional container tab). Can reproduce with:

$ rm -rf  /home/matej/.mozilla/firefox//r7f7tog2.default/storage/default/moz-extension+++5f45d77e-be24-4875-92f5-c6dcce28fc7d\^userContextId\=4294967295/
$ # BTW, Note the double slash in the profile name ... isn't it wrong?
$ ./firefox # let it run for a moment to be sure that empty databases and data structures
$ # are created
$ pkill -f firefox
$ ./ffcontainer.sh import ~/ffcontainers-eguebw4d.default-1548008691899-20190402.zip

Restart Firefox and the menu is messed up.

[pierlauro]

The result is something which looks very much like mozilla/multi-account-containers#1321 (non-functional container tab)

I had the same issue when synchronizing from an updated Firefox installation with the containers addon version 4 to another updated Firefox BUT whose containers addon was still at version 3.

Could you check the addon's version on the importing machine?

# BTW, Note the double slash in the profile name ... isn't it wrong?

Not totally wrong since the path is valid anyway (// is expanded as ././ so it is equivalent to /). But thanks, I will fix it. It could potentially introduce indexing errors when using cut -d /.

[pierlauro]

Not totally wrong since the path is valid anyway (// is expanded as ././ so it is equivalent to /). But thanks, I will fix it. It could potentially introduce indexing errors when using cut -d /.

Just merged your pull request, thank you.

[mcepl]

I had the same issue when synchronizing from an updated Firefox installation with the containers addon version 4 to another updated Firefox BUT whose containers addon was still at version 3.

Could you check the addon's version on the importing machine?

??? I have multi-account-containers version 6.1.0 from https://github.com/mozilla/multi-account-containers

[pierlauro]

You should check the version in containers.js, your version on the first machine is 4 as you can see in your archive's file. What about the other machine?

[mcepl]

I believe it is the same containers.json.

[pierlauro]

I tried to reproduce the error but I did not succeed.

Would you mind attaching both your prefs.js?

[mcepl]

prefs.js.target.txt prefs.js.source.txt

[joaopsys]

Same happening to me unfortunately. The containers.json is copied just fine, but overwriting the sqlite file makes the extension stop working.

[pierlauro]

A couple of days ago I figured out which is the error: as you can see in prefs.js, every addon installation has a different ramdom ID. The problem could intuitively be solved in 2 ways:

1 - Replace the addon id. 2 - Make a SQL dump of the addon's settings table from the source machine and restore it on the destination one.

Regarding the first solution, it seems that replacing an addon id is not as trivial as expected because it is somewhere stored in a binary form (I replaced all plain-text ids and still didn't succeed to fix the problem).

The second alternative is also presenting a problem as the sqlite database is set to call some triggers on items INSERT/DELETE that, unfortunately, are not enclosed in the file itself but are programmatically declared as custom functions directly in C++ in Firefox.

Given the context, my objective is to develop a generic solution to export/import every addon's settings (at least all the ones using IndexedDB) and use it also in this script.

This will require some time, it is in my TODO list for next weekend so I will update you soon.

Feel free to give suggestions if you have any.

[joaopsys]

Thank you for the technical details! So in theory, if I apply all the INSERTs directly from one DB to the other, while Firefox is running, would that accomplish anything?

EDIT: Nope, the database is obviously locked :)

[pierlauro]

EDIT: Nope, the database is obviously locked :)

That's not the only problem: even if the DB would not be locked, the SQLite client would still not be able to locate the functions (loaded in memory by Firefox and not saved in the file - so not shared with other clients).