зеркало из https://github.com/mozilla/gecko-dev.git
Bug 1823159 - Avoid racily initializing the PermissionManager twice during startup, r=timhuang,baku
It appears that the issue is caused by a change in behaviour from bug 1799470 which made the profile available earlier during startup. If the permission manager is started between the time when the profile becomes available and profile-do-change, it would've previously initialized without storage, and initialized storage after profile-do-change, but after the changes it may initialize twice instead. This patch changes the profile-do-change handler to check if we already have a profile, and avoid initializing the DB twice in that situation. Differential Revision: https://phabricator.services.mozilla.com/D173062
This commit is contained in:
Родитель
97af22bfac
Коммит
bebd207110
|
@ -2584,8 +2584,9 @@ NS_IMETHODIMP PermissionManager::Observe(nsISupports* aSubject,
|
||||||
const char16_t* someData) {
|
const char16_t* someData) {
|
||||||
ENSURE_NOT_CHILD_PROCESS;
|
ENSURE_NOT_CHILD_PROCESS;
|
||||||
|
|
||||||
if (!nsCRT::strcmp(aTopic, "profile-do-change")) {
|
if (!nsCRT::strcmp(aTopic, "profile-do-change") && !mPermissionsFile) {
|
||||||
// the profile has already changed; init the db from the new location
|
// profile startup is complete, and we didn't have the permissions file
|
||||||
|
// before; init the db from the new location
|
||||||
InitDB(false);
|
InitDB(false);
|
||||||
} else if (!nsCRT::strcmp(aTopic, "testonly-reload-permissions-from-disk")) {
|
} else if (!nsCRT::strcmp(aTopic, "testonly-reload-permissions-from-disk")) {
|
||||||
// Testing mechanism to reload all permissions from disk. Because the
|
// Testing mechanism to reload all permissions from disk. Because the
|
||||||
|
|
Загрузка…
Ссылка в новой задаче