User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.100 Safari/537.36 Steps to reproduce: I configured cookie exceptions in FF using the corresponding GUI. Actual results: The cookie exception was only working in the browser session I configured the exception in. After a restart of Firefox the exception was no longer shown and no longer worked. It turns out that the cookie exception was not saved to permissions.sqlite in the user profile. When checking other clients that had already cookie exceptions in permissions.sqlite, Firefox did not load those exceptions (no exceptions were shown in the GUI and they did not work either). I tried the same with a new user profile and the problem still persists. The only time the loading and saving of cookie exceptions worked, was in the first browser session after an up- or downgrade of FF (when FF also shows the dialog for checking the extensions). It seems there might be a race condition in FF startup, when trying to access the permissions.sqlite database. I don't know in what FF version this problem began showing up, I checked FF 49, 49.0.2 and 50, and all these version had the same problem. Expected results: The cookie exception should have been saves into permissions.sqlite after configuring it, and on a Firefox restart it should have been loaded.

Just found this bug report, which seems to have the same root cause: https://bugzilla.mozilla.org/show_bug.cgi?id=1263209 And after reading the comment 12 in that bug report, it seems that the problem arises due to a failure when trying to access the storage service, i.e. the do_GetService(MOZ_STORAGE_SERVICE_CONTRACTID) call, when trying to open the database, fails.

I have put some debugging code into FF and it seems this happens because in storage/mozStorageService.cpp in Service::initialize() the call rc = ::sqlite3_config(SQLITE_CONFIG_MALLOC, &memMethods) fails with error code 21 (SQLITE_MISUSE). I'm not sure why this is the case. The SQLite documentation suggest this might happen, for example, because sqlite3_config() gets called after sqlite3_initialize(), but the only sqlite3_initialize() call I have found is in Service::initialize() and it only gets executed after the sqlite3_config() calls. Another interesting thing: After the do_GetService(MOZ_STORAGE_SERVICE_CONTRACTID) call fails, apparently Service::initialize() gets called a second time from somewhere else, and this time it is successful and does not generate an error when sqlite3_config(SQLITE_CONFIG_MALLOC, &memMethods) gets called. Maybe there are other sqlite3_* calls elsewhere, that implicitly call sqlite3_initialize() before Service::initialize() gets called?

After adding more debugging output, it turns out that sqlite3_initialize() is called implicitly about 100 times before sqlite3_config(SQLITE_CONFIG_MALLOC, &memMethods) gets called in Service::initialize(). This seems to be because we use NSS_DEFAULT_DB_TYPE=sql and apparently this triggers all those sqlite calls when initializing the NSS DB. The code needs to make sure that this cannot happen. There is a (internal?) bug report for that, that sadly hasn't received much attention lately: https://bugzilla.mozilla.org/show_bug.cgi?id=730495 Here is a bug reports because of failing extensions installations which has the same root cause: https://bugzilla.mozilla.org/show_bug.cgi?id=1277295 (reported by me) https://bugzilla.mozilla.org/show_bug.cgi?id=1236865#c2