Last Comment Bug 681024 - Accessing mozIndexedDB in a chrome window throws
: Accessing mozIndexedDB in a chrome window throws
Product: Core
Classification: Components
Component: DOM: IndexedDB (show other bugs)
: unspecified
: All All
-- normal (vote)
: ---
Assigned To: Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)
: Hsin-Yi Tsai [:hsinyi]
Depends on:
Blocks: 587797
  Show dependency treegraph
Reported: 2011-08-22 13:04 PDT by Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)
Modified: 2012-03-22 11:52 PDT (History)
4 users (show)
mounir: in‑testsuite?
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (1.84 KB, patch)
2011-08-22 13:04 PDT, Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary)
bent.mozilla: review+
Details | Diff | Splinter Review

Description User image Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-22 13:04:34 PDT
Created attachment 554939 [details] [diff] [review]

mozIThirdPartyUtil chokes on chrome windows because their principal (nsSystemPrincipal) has no URI.
Comment 1 User image Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-08-22 13:36:16 PDT
Comment 2 User image Mounir Lamouri (:mounir) 2011-08-23 01:32:43 PDT

I believe we could test this...
Comment 3 User image Andrew Sutherland [:asuth] 2011-08-24 12:12:38 PDT
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()->

This nets it the system principal because it is using the context of the calling code, so:
  if (nsContentUtils::IsSystemPrincipal(principal)) {
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 User image Ben Turner (not reading bugmail, use the needinfo flag!) 2011-08-24 12:49:18 PDT
(In reply to Andrew Sutherland (:asuth) from comment #3)

Let's sort this out in bug 587797?

Note You need to log in before you can comment on or make changes to this bug.