Commit bd18aec0 authored by Nika Layzell's avatar Nika Layzell
Browse files

Bug 1337056 - Part 11: Change the permission key assertion to a fatal assert... 

Bug 1337056 - Part 11: Change the permission key assertion to a fatal assert on debug builds, r=ehsan

MozReview-Commit-ID: HTxvlomRKWy
parent 83c78896

dom/ipc/ContentParent.cpp

+8 −3
Original line number Diff line number Diff line
@@ -5111,14 +5111,19 @@ void 
ContentParent::EnsurePermissionsByKey(const nsCString& aKey)

{

#ifdef MOZ_PERMISSIONS

  // NOTE: Make sure to initialize the permission manager before updating the

  // mActivePermissionKeys list. If the permission manager is being initialized

  // by this call to GetPermissionManager, and we've added the key to

  // mActivePermissionKeys, then the permission manager will send down a

  // SendAddPermission before receiving the SendSetPermissionsWithKey message.

  nsCOMPtr<nsIPermissionManager> permManager =

    services::GetPermissionManager();



  if (mActivePermissionKeys.Contains(aKey)) {

    return;

  }

  mActivePermissionKeys.PutEntry(aKey);



  nsCOMPtr<nsIPermissionManager> permManager =

    services::GetPermissionManager();



  nsTArray<IPC::Permission> perms;

  nsresult rv = permManager->GetPermissionsWithKey(aKey, perms);

  if (NS_WARN_IF(NS_FAILED(rv))) {

extensions/cookie/nsPermissionManager.cpp

+7 −9
Original line number Diff line number Diff line
@@ -647,20 +647,18 @@ nsPermissionManager::PermissionKey::CreateFromPrincipal(nsIPrincipal* aPrincipal 
  }



#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.

  // 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 crash on

  // debug builds 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 "

    if (!gPermissionManager->mAvailablePermissionKeys.Contains(permissionKey)) {

      NS_WARNING(nsPrintfCString("This content process hasn't received the "

                                 "permissions for %s yet", permissionKey.get()).get());

      MOZ_CRASH("The content process hasn't recieved permissions for an origin yet.");

    }

  }

#endif

extensions/cookie/test/browser.ini

+5 −1
Original line number Diff line number Diff line
@@ -2,4 +2,8 @@ 


[browser_test_favicon.js]

[browser_permmgr_sync.js]

skip-if = !e10s # This tests e10s specific behavior
 
# The browser_permmgr_sync test tests e10s specific behavior, and runs code

# paths which would hit the debug only assertion in

# nsPermissionManager::PermissionKey::CreateFromPrincipal. Because of this, it

# is only run in e10s opt builds.

skip-if = debug || !e10s