Closed Bug 909823 Opened 11 years ago Closed 2 years ago

Figure out permission weirdness in Bug 870676 test

Categories

(Core :: Security, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: khuey, Unassigned)

References

Details

We needed to set 'needParentPermission' to true in order to get test_fmradio.html to pass with the patches from bug 870676.  It's not clear what this does or why it's necessary.  We should dive in and figure out if this is a bug with the permissions checking.
The implemented testing framework differs slightly from my comment in bug 815105#c16 . I don't recall the exact reason for not creating an actual app iframe, maybe because the test directly modifies permissions. In this case, the tests would  fail for APIs that check APP_TYPE.

The VM frame hierarchy should be as follows
- test-container app (which should have all permissions similar to shell.js)
-- mochi.test iframe (test_* and file_framework.js are loaded into this iframe)
--- example.org remote iframe (iframe created during tests)

needParentPermission injects the permission in to the mochi.test iframe.

This is the relevant code / callpath for AppProcessChecker [1]

I'll debug the call and see what is being passed to the check. The only thing I can think of is that the call at
34   nsCOMPtr<mozIApplication> app = tab->GetOwnOrContainingApp();

isn't returning what I expect.

[1] - http://mxr.mozilla.org/mozilla-central/source/dom/ipc/AppProcessChecker.cpp#23
Assignee: nobody → dchan+bugzilla
No longer blocks: 913343

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: dchanm+bugzilla → nobody

test_fmradio.html doesn't exist any longer.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.