The default bug view has changed. See this FAQ.

Accessing mozIndexedDB in a chrome window throws

RESOLVED FIXED

Status

()

Core
DOM: IndexedDB
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: khuey, Assigned: khuey)

Tracking

unspecified
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.84 KB, patch
Ben Turner (not reading bugmail, use the needinfo flag!)
: review+
Details | Diff | Splinter Review
Created attachment 554939 [details] [diff] [review]
Patch

mozIThirdPartyUtil chokes on chrome windows because their principal (nsSystemPrincipal) has no URI.
Attachment #554939 - Flags: review?(bent.mozilla)
Attachment #554939 - Flags: review?(bent.mozilla) → review+
http://hg.mozilla.org/integration/mozilla-inbound/rev/84d701850381
http://hg.mozilla.org/mozilla-central/rev/84d701850381

I believe we could test this...
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Version: unspecified → Trunk
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!
(In reply to Andrew Sutherland (:asuth) from comment #3)

Let's sort this out in bug 587797?
Component: DOM → DOM: IndexedDB
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.