Open Bug 1239528 Opened 8 years ago Updated 2 years ago

dom/permissions/tests/test_permissions_basics fails with e10s

Categories

(Core :: DOM: Core & HTML, defect)

defect

Tracking

()

Tracking Status
e10s - ---
firefox46 --- affected

People

(Reporter: mccr8, Unassigned)

References

Details

This test calls navigator.mozPermissionSettings.set(), then checks that the set() actually works. The implementation of mozPermissionSettings, in PermissionSettings.js, synchronously calls into the parent process. The parent-side implementation, in PermissionSettings.jsm, calls into Services.perms.addFromPrincipal() to actually set the permission. This is implemented in nsPermissionManager::AddInternal(), which then sends a message to the child process, via ContentChild::SendAddPermission.

However, that message to the child process is asynchronous, so when the test checks that the permission is set, it isn't.

I'm not sure if this is a problem with the test, the implementation, or the API. I don't think mozPermissionSettings is used on desktop, so I don't think this really needs to be tracked for e10s. Gaia uses this API, but maybe only in the parent process? Either that or they just never check the value being set right after they set it.
Oh, and I meant to mention, I noticed another part of the test that is broken:

// Removing a permission from the same origin, even an explicit one, should fail
try {
  mozPermissions.set(testPerm, "unknown", privAppManifest, originPriv);
  ok(false, "Setting a permission to unknown");
...

This is supposed to fail because of some permission thing, but it actually fails because the .set call does not have enough arguments. I think it needs an extra "false" argument.

There's also an extra space in one of the permission manager logging things but I'll file a separate bug for that.
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.