Bug 1337056 - Part 4: Assert that the ipcKey for a principal is avaliable when creating a PermissionKey in the child process, r=baku

MozReview-Commit-ID: G9TynCKgCVF
This commit is contained in:
Michael Layzell 2017-03-02 16:56:01 -05:00
parent d861bbc093
commit ce8ac3bacf

View File

@ -39,6 +39,7 @@
#include "nsINavHistoryService.h"
#include "nsToolkitCompsCID.h"
#include "nsIObserverService.h"
#include "nsPrintfCString.h"
static nsPermissionManager *gPermissionManager = nullptr;
@ -597,6 +598,24 @@ nsPermissionManager::PermissionKey::CreateFromPrincipal(nsIPrincipal* aPrincipal
return nullptr;
}
#ifdef DEBUG
// Creating a PermissionsKey to look up a permission if we haven't had those keys
// synced down yet is problematic, so we do a check here and emit an assertion if
// we see it happening.
if (XRE_IsContentProcess()) {
nsAutoCString permissionKey;
GetKeyForPrincipal(aPrincipal, permissionKey);
// NOTE: Theoretically an addon could ask for permissions which the process
// wouldn't have access to, and we wouldn't want to crash the process in
// this case, but our chrome code should never do this. Using NS_ASSERTION
// here so that we can test fetching unavaliable permissions in tests.
NS_ASSERTION(gPermissionManager->mAvailablePermissionKeys.Contains(permissionKey),
nsPrintfCString("This content process hasn't received the "
"permissions for %s yet", permissionKey.get()).get());
}
#endif
return new PermissionKey(origin);
}