This class is used by both parent and child processes. It's more heavily used on the parent vs the child side.
With this change, even though the PermissionManager class should itself be now thread-safe, I have still
kept assertions on most of it's public methods for main thread in place because I wanted to keep the regression
risk minimal with this change while still satisfying my criteria about allowing some operations like adding new
and reading existing permissions thread-safe such that they can be performed off-main thread.
There might be some permission manager callers here which previously needed to switch to main thread in order to
invoke operations; they would no longer need to do that. After gaining some confidence with this limited exposure
maybe we can slowly start looking into the callers and see if they can benefit from this thread-safety now i.e.
if they do not need to switch to main thread just for the sake of PermissionManager usage.
Since, this is a singleton class; ofcourse, the creation, initialization, etc. are still main thread only. Also,
any DB operation can also only be performed on the corresponding thread only.
Differential Revision: https://phabricator.services.mozilla.com/D244608
- Pass through principal as lambda argument in internal RemovePermissionEntries
permission manager function
- Add new permission manager internal function RemoveAllForPrivateBrowsing,
which removes all permission manager entries with a private browsing principal
- Call RemoveAllForPrivateBrowsing on `last-pb-context-exited` event
Differential Revision: https://phabricator.services.mozilla.com/D244787
If Thunderbird ships permissions, this test fails since the test doesn't account for that.
Firefox runs the test without Firefox profile settings (meaning no remote settings available) so
it's not a problem there.
Differential Revision: https://phabricator.services.mozilla.com/D239492
With the previous implementation, the permission manager may miss the
"profile-after-change" event and won't start the remote permission service.
Differential Revision: https://phabricator.services.mozilla.com/D235169
This ensures that the instantiation of the service always returns the
same singleton. I also changed calls to nsEffectiveTLDService::GetInstance
to use mozilla::components::EffectiveTLD::Service() instead.
Differential Revision: https://phabricator.services.mozilla.com/D235288
This patch makes PermissionManager::GetInstance do the instantiation
work and GetXPCOMSingleton just uses it.
We always acquire the creation mutex and return an already_AddRefed to
avoid any possible race. We count on callers of GetInstance to
(shortly) keep a local reference if they have more work to do.
On async shutdown in the parent process, we first mark our singleton
dead, then close all our resources async and finally null our instance
holder only after the async shutdown has finished.
Differential Revision: https://phabricator.services.mozilla.com/D233816
This is adding the RemotePermissionService xpcom js service for the purpose of
importing default permission manager entries from remote settings. This service
will be initialized by the permission manager after it has read all its
permissions from disk and is fully initialized.
When being initialized, the service will at first get all the current default
remote permissions from the remote settings client, and add them as default
permissions through the `AddDefaultFromPrincipal` method added in D222650. An
event listener is then also set up to keep the default entries in the permission
manager in sync with remote settings.
All of this is guarded behind a whitelist in the the `ALLOWED_PERMISSION_VALUES`
variable, ensuring only specific permission types and values can be imported
through this mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D222649
This method will later be used to import default permissions from remote
settings through the remote permission manager.
Differential Revision: https://phabricator.services.mozilla.com/D222650
Allow default permissions to be deleted by adding a new permission with same
origin and type, and value UNKNOWN_ACTION, analogous to how normal permissions
currently already get deleted. This can then later be used by the remote
permission service (D222649) to remove default permissions it previously added
if they have been removed in remote settings.
Also add brackets to make clang-tidy happy.
Differential Revision: https://phabricator.services.mozilla.com/D222651
This makes sure default permissions are always restored when a previously
overriding user permission gets deleted with AddInternal.
Differential Revision: https://phabricator.services.mozilla.com/D222652
This just simplifies the code for later use and should not change any behaviour
beside the following:
If `permissions.manager.defaultsUrl` is customized and contains a legacy `host`
entry, removes the history lookup to determine known origins for a given host.
Instead, only entries for http:// and https:// on the default ports will be
added. This is because with the changes in this patch,
`UpgradeHostToOriginAndInsert` is moved off the main thread, and a history
lookup is only allowed on the main thread.
Also rename `mDefaultEntries` to `mDefaultEntriesForImport` to better reflect
what this array is actually for: Storing the defaults so that they can be
(re-)imported into the permission manager, and not being the primary location
where the default permissions are stored.
Differential Revision: https://phabricator.services.mozilla.com/D222654
This is adding the RemotePermissionService xpcom js service for the purpose of
importing default permission manager entries from remote settings. This service
will be initialized by the permission manager after it has read all its
permissions from disk and is fully initialized.
When being initialized, the service will at first get all the current default
remote permissions from the remote settings client, and add them as default
permissions through the `AddDefaultFromPrincipal` method added in D222650. An
event listener is then also set up to keep the default entries in the permission
manager in sync with remote settings.
All of this is guarded behind a whitelist in the the `ALLOWED_PERMISSION_VALUES`
variable, ensuring only specific permission types and values can be imported
through this mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D222649
This method will later be used to import default permissions from remote
settings through the remote permission manager.
Differential Revision: https://phabricator.services.mozilla.com/D222650
Allow default permissions to be deleted by adding a new permission with same
origin and type, and value UNKNOWN_ACTION, analogous to how normal permissions
currently already get deleted. This can then later be used by the remote
permission service (D222649) to remove default permissions it previously added
if they have been removed in remote settings.
Also add brackets to make clang-tidy happy.
Differential Revision: https://phabricator.services.mozilla.com/D222651
This makes sure default permissions are always restored when a previously
overriding user permission gets deleted with AddInternal.
Differential Revision: https://phabricator.services.mozilla.com/D222652
This just simplifies the code for later use and should not change any behaviour
beside the following:
If `permissions.manager.defaultsUrl` is customized and contains a legacy `host`
entry, removes the history lookup to determine known origins for a given host.
Instead, only entries for http:// and https:// on the default ports will be
added. This is because with the changes in this patch,
`UpgradeHostToOriginAndInsert` is moved off the main thread, and a history
lookup is only allowed on the main thread.
Also rename `mDefaultEntries` to `mDefaultEntriesForImport` to better reflect
what this array is actually for: Storing the defaults so that they can be
(re-)imported into the permission manager, and not being the primary location
where the default permissions are stored.
Differential Revision: https://phabricator.services.mozilla.com/D222654
This is adding the RemotePermissionService xpcom js service for the purpose of
importing default permission manager entries from remote settings. This service
will be initialized by the permission manager after it has read all its
permissions from disk and is fully initialized.
When being initialized, the service will at first get all the current default
remote permissions from the remote settings client, and add them as default
permissions through the `AddDefaultFromPrincipal` method added in D222650. An
event listener is then also set up to keep the default entries in the permission
manager in sync with remote settings.
All of this is guarded behind a whitelist in the the `ALLOWED_PERMISSION_VALUES`
variable, ensuring only specific permission types and values can be imported
through this mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D222649
This method will later be used to import default permissions from remote
settings through the remote permission manager.
Differential Revision: https://phabricator.services.mozilla.com/D222650
Allow default permissions to be deleted by adding a new permission with same
origin and type, and value UNKNOWN_ACTION, analogous to how normal permissions
currently already get deleted. This can then later be used by the remote
permission service (D222649) to remove default permissions it previously added
if they have been removed in remote settings.
Also add brackets to make clang-tidy happy.
Differential Revision: https://phabricator.services.mozilla.com/D222651
This makes sure default permissions are always restored when a previously
overriding user permission gets deleted with AddInternal.
Differential Revision: https://phabricator.services.mozilla.com/D222652
This just simplifies the code for later use and should not change any behaviour
beside the following:
If `permissions.manager.defaultsUrl` is customized and contains a legacy `host`
entry, removes the history lookup to determine known origins for a given host.
Instead, only entries for http:// and https:// on the default ports will be
added. This is because with the changes in this patch,
`UpgradeHostToOriginAndInsert` is moved off the main thread, and a history
lookup is only allowed on the main thread.
Also rename `mDefaultEntries` to `mDefaultEntriesForImport` to better reflect
what this array is actually for: Storing the defaults so that they can be
(re-)imported into the permission manager, and not being the primary location
where the default permissions are stored.
Differential Revision: https://phabricator.services.mozilla.com/D222654
This is adding the RemotePermissionService xpcom js service for the purpose of
importing default permission manager entries from remote settings. This service
will be initialized by the permission manager after it has read all its
permissions from disk and is fully initialized.
When being initialized, the service will at first get all the current default
remote permissions from the remote settings client, and add them as default
permissions through the `AddDefaultFromPrincipal` method added in D222650. An
event listener is then also set up to keep the default entries in the permission
manager in sync with remote settings.
All of this is guarded behind a whitelist in the the `ALLOWED_PERMISSION_VALUES`
variable, ensuring only specific permission types and values can be imported
through this mechanism.
Differential Revision: https://phabricator.services.mozilla.com/D222649
This method will later be used to import default permissions from remote
settings through the remote permission manager.
Differential Revision: https://phabricator.services.mozilla.com/D222650
Allow default permissions to be deleted by adding a new permission with same
origin and type, and value UNKNOWN_ACTION, analogous to how normal permissions
currently already get deleted. This can then later be used by the remote
permission service (D222649) to remove default permissions it previously added
if they have been removed in remote settings.
Also add brackets to make clang-tidy happy.
Differential Revision: https://phabricator.services.mozilla.com/D222651
This makes sure default permissions are always restored when a previously
overriding user permission gets deleted with AddInternal.
Differential Revision: https://phabricator.services.mozilla.com/D222652
This just simplifies the code for later use and should not change any behaviour
beside the following:
If `permissions.manager.defaultsUrl` is customized and contains a legacy `host`
entry, removes the history lookup to determine known origins for a given host.
Instead, only entries for http:// and https:// on the default ports will be
added. This is because with the changes in this patch,
`UpgradeHostToOriginAndInsert` is moved off the main thread, and a history
lookup is only allowed on the main thread.
Also rename `mDefaultEntries` to `mDefaultEntriesForImport` to better reflect
what this array is actually for: Storing the defaults so that they can be
(re-)imported into the permission manager, and not being the primary location
where the default permissions are stored.
Differential Revision: https://phabricator.services.mozilla.com/D222654
