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)
Core
DOM: Core & HTML
Tracking
()
NEW
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.
Updated•8 years ago
|
tracking-e10s:
--- → -
Reporter | ||
Comment 1•8 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.
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•