681024 - Accessing mozIndexedDB in a chrome window throws

Status: RESOLVED FIXED

(Core :: Storage: IndexedDB, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Patch

mozIThirdPartyUtil chokes on chrome windows because their principal (nsSystemPrincipal) has no URI.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/84d701850381

Comment 2

[Mounir Lamouri (:mounir)]

http://hg.mozilla.org/mozilla-central/rev/84d701850381

I believe we could test this...

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

There's a similar problem in the IDBFactory::Open/CheckPermissionHelper.cpp GetIndexedDBPermissions pairing, although maybe what I'm doing is bad.

Specifically, I have JS code that is loaded by jetpack.  I try and steal a reference to mozIndexedDB from the hidden window.  This works on a build with the patch.

Unfortunately, when I issue the call to IDBFactory::Open, it uses:
  nsresult rv = nsContentUtils::GetSecurityManager()->
    GetSubjectPrincipal(getter_AddRefs(principal));

This nets it the system principal because it is using the context of the calling code, so:
  if (nsContentUtils::IsSystemPrincipal(principal)) {
    origin.AssignLiteral("chrome");
  }
ends up assigning us the URI of "chrome".

But in GetIndexedDBPermissions, the principal is looked up by doing:
  nsCOMPtr<nsIScriptObjectPrincipal> sop(do_QueryInterface(aWindow));
  NS_ENSURE_TRUE(sop, nsIPermissionManager::DENY_ACTION);

Unfortunately, the hidden window's principal is not the system principal, so this check does not pass:
  if (nsContentUtils::IsSystemPrincipal(sop->GetPrincipal())) {
    return nsIPermissionManager::ALLOW_ACTION;
  }

and instead we end up dying at:
  nsresult rv = NS_NewURI(getter_AddRefs(uri), aASCIIOrigin);
  NS_ENSURE_SUCCESS(rv, nsIPermissionManager::DENY_ACTION);


Would it be okay to make GetIndexedDBPermissions detect a URI of chrome or save off the principal of the caller so things could work?  I have tried some other hackery like invoking IDBFactory::Open in a loaded document and passing that back out to my jetpack module, but unfortunately I start getting JS same-compartment assertions when the callback triggers and my code tries to get at the 'result' on the db request.

I would ideally like to avoid loading my JS as a straight-up content document because everything else is using the jetpack module system, but I can do that if that's the only option.  Suggestions appreciated!

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to Andrew Sutherland (:asuth) from comment #3)

Let's sort this out in bug 587797?