Last Comment Bug 681024 - Accessing mozIndexedDB in a chrome window throws
: Accessing mozIndexedDB in a chrome window throws
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: IndexedDB (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Kyle Huey [:khuey] (khuey@mozilla.com)
:
Mentors:
Depends on:
Blocks: 587797
  Show dependency treegraph
 
Reported: 2011-08-22 13:04 PDT by Kyle Huey [:khuey] (khuey@mozilla.com)
Modified: 2012-03-22 11:52 PDT (History)
4 users (show)
mounir: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch (1.84 KB, patch)
2011-08-22 13:04 PDT, Kyle Huey [:khuey] (khuey@mozilla.com)
bent.mozilla: review+
Details | Diff | Review

Description Kyle Huey [:khuey] (khuey@mozilla.com) 2011-08-22 13:04:34 PDT
Created attachment 554939 [details] [diff] [review]
Patch

mozIThirdPartyUtil chokes on chrome windows because their principal (nsSystemPrincipal) has no URI.
Comment 1 Kyle Huey [:khuey] (khuey@mozilla.com) 2011-08-22 13:36:16 PDT
http://hg.mozilla.org/integration/mozilla-inbound/rev/84d701850381
Comment 2 Mounir Lamouri (:mounir) 2011-08-23 01:32:43 PDT
http://hg.mozilla.org/mozilla-central/rev/84d701850381

I believe we could test this...
Comment 3 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()->
    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!) 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.