dom/permissions/tests/test_permissions_basics fails with e10s

NEW
Unassigned

Status

()

3 years ago
3 years ago

People

(Reporter: mccr8, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(e10s-, firefox46 affected)

Details

(Reporter)

Description

3 years ago
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.
tracking-e10s: --- → -
(Reporter)

Comment 1

3 years ago
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.
You need to log in before you can comment on or make changes to this bug.