This patch introduces a new value for the preference
`media.eme.mfcdm.origin-filter.enabled`, enabling the use of an origin
list retrieved from Remote Settings. This allows the list to be updated
dynamically.
Differential Revision: https://phabricator.services.mozilla.com/D247027
This patch introduces a new value for the preference
`media.eme.mfcdm.origin-filter.enabled`, enabling the use of an origin
list retrieved from Remote Settings. This allows the list to be updated
dynamically.
Differential Revision: https://phabricator.services.mozilla.com/D247027
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
This patch implements the PRemoteWorkerDebuggerManager binding.
PRemoteWorkerDebuggerManager is the IPC that handles the registration/unregistration of remote debuggers.
Its life cycle is as long as the RemoteWorkerService such that it can also handle the remote debugger of child workers.
The detailed binding flow is
When ContentParent calls StartRemoteWorkerService() on the parent process main thread, creating Endpoints of PRemoteWorkerDebuggerManager, then creating and binding RemoteWorkerDebuggerManagerParent to the corresponding parent Endpoint.
Propagating the created child Endpoint through ContentParent::SendInitRemoteWorkerService().
Propagating the created child Endpoint to RemoteWorkerService::InitializeOnMainThread(), then creating PRemoteWorkerDebuggerManagerChild and binding it to the child Endpoint. Then IPC is done.
RemoteWorkerdDebuggerManagerChild can also be created in the parent process for workers on the parent process.
This is unnecessary, but providing a general debugging mechanism for all types of Workers is good.
The details flow is similar to the normal flow, but creating Endpoints and RemoteWorkerDebuggerManagerParent when RemoteWorkerService::Observe() the "profile-after-change" signal. Then, RemoteWorkerService::InitailizeOnMainThread() will be called directly on the parent process main thread.
Depends on D230259
Differential Revision: https://phabricator.services.mozilla.com/D231682
This patch implements the PRemoteWorkerDebuggerManager binding.
PRemoteWorkerDebuggerManager is the IPC that handles the registration/unregistration of remote debuggers.
Its life cycle is as long as the RemoteWorkerService such that it can also handle the remote debugger of child workers.
The detailed binding flow is
When ContentParent calls StartRemoteWorkerService() on the parent process main thread, creating Endpoints of PRemoteWorkerDebuggerManager, then creating and binding RemoteWorkerDebuggerManagerParent to the corresponding parent Endpoint.
Propagating the created child Endpoint through ContentParent::SendInitRemoteWorkerService().
Propagating the created child Endpoint to RemoteWorkerService::InitializeOnMainThread(), then creating PRemoteWorkerDebuggerManagerChild and binding it to the child Endpoint. Then IPC is done.
RemoteWorkerdDebuggerManagerChild can also be created in the parent process for workers on the parent process.
This is unnecessary, but providing a general debugging mechanism for all types of Workers is good.
The details flow is similar to the normal flow, but creating Endpoints and RemoteWorkerDebuggerManagerParent when RemoteWorkerService::Observe() the "profile-after-change" signal. Then, RemoteWorkerService::InitailizeOnMainThread() will be called directly on the parent process main thread.
Depends on D230259
Differential Revision: https://phabricator.services.mozilla.com/D231682
This patch implements the PRemoteWorkerDebuggerManager binding.
PRemoteWorkerDebuggerManager is the IPC that handles the registration/unregistration of remote debuggers.
Its life cycle is as long as the RemoteWorkerService such that it can also handle the remote debugger of child workers.
The detailed binding flow is
When ContentParent calls StartRemoteWorkerService() on the parent process main thread, creating Endpoints of PRemoteWorkerDebuggerManager, then creating and binding RemoteWorkerDebuggerManagerParent to the corresponding parent Endpoint.
Propagating the created child Endpoint through ContentParent::SendInitRemoteWorkerService().
Propagating the created child Endpoint to RemoteWorkerService::InitializeOnMainThread(), then creating PRemoteWorkerDebuggerManagerChild and binding it to the child Endpoint. Then IPC is done.
RemoteWorkerdDebuggerManagerChild can also be created in the parent process for workers on the parent process.
This is unnecessary, but providing a general debugging mechanism for all types of Workers is good.
The details flow is similar to the normal flow, but creating Endpoints and RemoteWorkerDebuggerManagerParent when RemoteWorkerService::Observe() the "profile-after-change" signal. Then, RemoteWorkerService::InitailizeOnMainThread() will be called directly on the parent process main thread.
Depends on D230259
Differential Revision: https://phabricator.services.mozilla.com/D231682
This patch implements the PRemoteWorkerDebuggerManager binding.
PRemoteWorkerDebuggerManager is the IPC that handles the registration/unregistration of remote debuggers.
Its life cycle is as long as the RemoteWorkerService such that it can also handle the remote debugger of child workers.
The detailed binding flow is
When ContentParent calls StartRemoteWorkerService() on the parent process main thread, creating Endpoints of PRemoteWorkerDebuggerManager, then creating and binding RemoteWorkerDebuggerManagerParent to the corresponding parent Endpoint.
Propagating the created child Endpoint through ContentParent::SendInitRemoteWorkerService().
Propagating the created child Endpoint to RemoteWorkerService::InitializeOnMainThread(), then creating PRemoteWorkerDebuggerManagerChild and binding it to the child Endpoint. Then IPC is done.
RemoteWorkerdDebuggerManagerChild can also be created in the parent process for workers on the parent process.
This is unnecessary, but providing a general debugging mechanism for all types of Workers is good.
The details flow is similar to the normal flow, but creating Endpoints and RemoteWorkerDebuggerManagerParent when RemoteWorkerService::Observe() the "profile-after-change" signal. Then, RemoteWorkerService::InitailizeOnMainThread() will be called directly on the parent process main thread.
Depends on D230259
Differential Revision: https://phabricator.services.mozilla.com/D231682
Make IntID::AlertNotificationOrigin not terribly slow on windows, since
that's the only thing we had a carveout for avoid querying on startup:
* Modern windows doesn't let you move the taskbar to a separate side.
* Even with that, on a multi-monitor setup there are multiple taskbars.
* More importantly, even with that, now we have native notifications by
default, so this is less important (this is only useful for the
non-native alerts).
Avoid GTK CRITICALs and crashes when calling into LookAndFeel from
XPCShell, which now happens.
Differential Revision: https://phabricator.services.mozilla.com/D242566
This patch implements the PRemoteWorkerDebuggerManager binding.
PRemoteWorkerDebuggerManager is the IPC that handles the registration/unregistration of remote debuggers.
Its life cycle is as long as the RemoteWorkerService such that it can also handle the remote debugger of child workers.
The detailed binding flow is
When ContentParent calls StartRemoteWorkerService() on the parent process main thread, creating Endpoints of PRemoteWorkerDebuggerManager, then creating and binding RemoteWorkerDebuggerManagerParent to the corresponding parent Endpoint.
Propagating the created child Endpoint through ContentParent::SendInitRemoteWorkerService().
Propagating the created child Endpoint to RemoteWorkerService::InitializeOnMainThread(), then creating PRemoteWorkerDebuggerManagerChild and binding it to the child Endpoint. Then IPC is done.
RemoteWorkerdDebuggerManagerChild can also be created in the parent process for workers on the parent process.
This is unnecessary, but providing a general debugging mechanism for all types of Workers is good.
The details flow is similar to the normal flow, but creating Endpoints and RemoteWorkerDebuggerManagerParent when RemoteWorkerService::Observe() the "profile-after-change" signal. Then, RemoteWorkerService::InitailizeOnMainThread() will be called directly on the parent process main thread.
Depends on D230259
Differential Revision: https://phabricator.services.mozilla.com/D231682
In order to clear cache from ChromeUtils.clearResourceCache with variuos
filtering, imgLoader needs a method that are adaptive to the current process,
where in the parent process, clear all processes' cache,
and in the content process, clear the cache in the process.
Refactored the cache methods based on single static method and single IPC
method, this is also necessary to extend the ChromeUtils.clearResourceCache in
bug 1947158.
Differential Revision: https://phabricator.services.mozilla.com/D239138
Another patch will move moz_set_max_dirty_page_modifier() into a different
section of malloc_decls.h where it will be unavailable without defining
MOZ_MEMORY. This patch places #ifdefs around some of its uses.
Differential Revision: https://phabricator.services.mozilla.com/D241134
While much of this is simply converting code (and removing extraneous
`size` parameters), toolkit/xre/GeckoArgs.{h,cpp} has some significant
changes to support sending read-only handles (which is all we need!).
Differential Revision: https://phabricator.services.mozilla.com/D236750
This adds support for the Origin-Agent-Cluster header. A map from principals to
their cached origin-agent-cluster status is maintained in the
BrowsingContextGroup, and synchronized to child processes such that it can be
used to create DocGroups.
Note that this patch does not implement origin-keyed process isolation for
Fission. Fission process isolation still always uses the site-origin.
It's likely we'll want to implement additional hereustics and/or tracking to
decide when to perform origin-keyed process isolation to avoid potential
process count increases when the default is changed to origin-isolated.
Differential Revision: https://phabricator.services.mozilla.com/D236974
While much of this is simply converting code (and removing extraneous
`size` parameters), toolkit/xre/GeckoArgs.{h,cpp} has some significant
changes to support sending read-only handles (which is all we need!).
Differential Revision: https://phabricator.services.mozilla.com/D236750
This is helpful for later patches in this stack because when
multiple folders are dragged and dropped onto a page Content Analysis
needs to get all of their contents.
Differential Revision: https://phabricator.services.mozilla.com/D233536
This is a huge patch, but it is only really refactoring of RFPTarget enum. We used to use RFPTarget as a bitset and now we ran out of bits, so now we need a workaround.
Differential Revision: https://phabricator.services.mozilla.com/D233182
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 patch changes the error returned when dispatching sync IPC to a
dead actor from a `MsgRouteError` error (which is handled as fatal in
most error handlers) to a `MsgDropped` error (which is generally
non-fatal).
This is intended to reflect the effective outcome of the change, which
is that the message is dropped due to the peer actor being dead.
This also removes the `MsgRouteError` error type as it has been fully
replaced by `MsgDropped`. The final use-case of `MsgRouteError` has been
replaced by a normal assertion, as it cannot be triggered by the IPC
layer.
Differential Revision: https://phabricator.services.mozilla.com/D232114
Merge the FontListChanged message sent by the parent when the list is updated
with the more general ForceGlobalReflow. Avoid forcing an update from the
InitOtherFamilyNames task if there is also a LoadCmaps operation in progress;
just ensure it will include the NeedsReframe flag in its message instead.
This should not change observable behavior, but aims to reduce the risk of
font data updates resulting in redundant multiple reflows.
Differential Revision: https://phabricator.services.mozilla.com/D232151
