This improves consistency with the child process case, and will make it easier
to attach additional state without needing to thread it through every child
process callsite manually.
Differential Revision: https://phabricator.services.mozilla.com/D153619
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
dom/media/ipc/RDDProcessManager.cpp(320,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
gpuProcessPid != -1 ? gpuProcessPid : base::GetCurrentProcId();
~~~~~~~~~~~~~ ^ ~~
dom/media/ipc/RDDProcessManager.cpp(332,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (gpuProcessPid != -1) {
~~~~~~~~~~~~~ ^ ~~
gfx/layers/ipc/SharedSurfacesParent.cpp(360,38): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (!gpm || gpm->GPUProcessPid() != -1) {
~~~~~~~~~~~~~~~~~~~~ ^ ~~
ipc/glue/MessageChannel.cpp(2145,13): error: comparison of integers of different signs: 'int32_t' (aka 'int') and 'const base::ProcessId' (aka 'const unsigned long') [-Werror,-Wsign-compare]
if (pid != base::kInvalidProcessId &&
~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
Differential Revision: https://phabricator.services.mozilla.com/D144688
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
In the following patch we are going to change the signature of
ShouldSanitizePreference to take a Pref object. Pref is only
known to the Preferences compilation unit; so to keep this member
(whose signature will change) we would need to expose the Pref
class. However it will only be a forward declaration, one could
not construct a Pref object in e.g. the gtest.
It is simpler to just remove the member entirely and call
ShouldSanitizePreference unconditionally - the member was only
used for the gtest, and while the gtest will be less robust
because of this change, it will still do some testing.
Depends on D141419
Differential Revision: https://phabricator.services.mozilla.com/D141420
To do the correct thing in Preferences::SerializePreferences
(which is used during subprocess startup) we need to know if
the destination process is a web content process or not.
We add parameters to
SharedPreferenceSerializer::SerializeToSharedMemory that let
us figure that out.
In Preferences::SerializePreferences we fix the call to
aShouldSanitizeFn to pass the correct destination.
Depends on D141415
Differential Revision: https://phabricator.services.mozilla.com/D141416
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This patch is to delay starting `UntrustedModulesProcessor` to avoid
processing a massive amount of loaded modules in the browser process
during startup.
To achive that, this patch introduces "unblock-untrusted-modules-thread"
notification. Before the notification, `UntrustedModulesProcessor` is
created but marked as not ready. This means the processor does not
go beyond `ScheduleNonEmptyQueueProcessing`. Once the notification is
observed, we propagate it to all existing child processes, and afterward
`UntrustedModulesProcessor` in new processes will be marked ready from
the beginning.
Differential Revision: https://phabricator.services.mozilla.com/D140123
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
This extends on the changes in part 12a and consumes the new PortRef-based API
in all existing process types other than the fork server. The IPDL C++ unit
tests were already broken before this change, and were not updated.
Differential Revision: https://phabricator.services.mozilla.com/D112777
In all those cases, the current nsISerialEventTarget is either the main thread or the MessageChannel's nsISerialEventTarget (since bug 1634846)
Differential Revision: https://phabricator.services.mozilla.com/D81966
