This is required for deserializing nsIPrincipal instances from PrincipalInfo to
be threadsafe, as setting domain with `SetDomain()` is only safe on the main
thread, due to it enumerating and updating JS wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D163036
This will provide us with more information with which to discover what
IPC messages are being sent extremely frequently, especially from
background processes, and what we can do to avoid unnecessary wakeups.
This is intended for power usage work, and is being tracked in a similar
way to the thread wakeups work, based on process types, such that the
data can be compared between the two.
Differential Revision: https://phabricator.services.mozilla.com/D157855
This introduces a new type to ContentParent which acts as a weak handle to the
actor and is safe to hold and manipulate from any thread.
This replaces accesses of the `ContentParent` type from the background thread,
as they were error-prone due to ContentParent not being threadsafe-refcounted.
The bulk of this patch is piping the new type through to the places it is
required, and removing now-unecessary extra complexity.
Differential Revision: https://phabricator.services.mozilla.com/D162346
This is done using slightly different mechanisms for each of LoadInfo and
nsDocShellLoadState, and will be used in the next part to validate document
loads based on the RemoteType responsible for the load.
For subresource loads, the TriggeringRemoteType is fairly straightforward - it
is the process which created the channel. We can handle this by getting the
current remote type when creating the channel, and then using the remote type
of the sending process when receiving the LoadInfo over IPC to either replace
the triggering remote type, or validate it.
For document loads, the situation is a bit more complex, as there are at least
3 (potentially-)different processes responsible for different parts of the
navigation:
1. The "Triggering Process" is the process which provided the URI to load.
This is also the process which provides the Triggering Principal. This is
the process being tracked in this patch.
2. The "Loading Process" is the process which actually creates the channel and
starts the load. This may be the same as the triggering process, or may be
a different process starting the navigation on behalf of the triggering
process. In general this is the process hosting the current docshell,
though it may be the parent process in the case of parent-initiated loads.
3. The "Final Process" is the process which receives the response and renders
the final document. This isn't known at channel creation time, and is
determined by the result principal and process isolation policy.
This change uses a serializer and special field on nsDocShellLoadState to track
the "Triggering Process" for the load, even as the load state is serialized
between processes by tracking which loads were sent into which content
processes, and matching them up when the parent process sees them again. The
information is then copied into the LoadInfo before configuring the real
channel, so it can be used for security checks.
The "Triggering Process" is overridden to be the parent process for history
loads, as history loads are often started in processes which wouldn't normally
be able to navigate to those pages. This is OK thanks to the changes in part 1
which validate history loads against the real session history when SHIP is
enabled.
Differential Revision: https://phabricator.services.mozilla.com/D161198
Using ipc::Shmem causes unbounded shmem use growth until e.g. a Worker
yields to the event loop. If a Worker never yields, Shmems sent to WebGLParent
are never released.
Specifically the manager (PCanvasManager) for WebGLParent calls
DestroySharedMemory, which sends/enqueues for WebGLChild's manager a
matching call to ShmemDestroyed. However, while WebGLChild refuses to spin its
event loop (such as a no-return WASM Worker), the ShmemDestroyed events
will just pile up. Closing e.g. the tab frees the shmems, but they accumulate
unbounded until the Worker yields to the event loop.
This is true for other users of ipc::Shmem (or RaiiShmem) as well, but
entrypoints other than DispatchCommands are rarer and can be handled
later similarly.
Differential Revision: https://phabricator.services.mozilla.com/D162946
Using ipc::Shmem causes unbounded shmem use growth until e.g. a Worker
yields to the event loop. If a Worker never yields, Shmems sent to WebGLParent
are never released.
Specifically the manager (PCanvasManager) for WebGLParent calls
DestroySharedMemory, which sends/enqueues for WebGLChild's manager a
matching call to ShmemDestroyed. However, while WebGLChild refuses to spin its
event loop (such as a no-return WASM Worker), the ShmemDestroyed events
will just pile up. Closing e.g. the tab frees the shmems, but they accumulate
unbounded until the Worker yields to the event loop.
This is true for other users of ipc::Shmem (or RaiiShmem) as well, but
entrypoints other than DispatchCommands are rarer and can be handled
later similarly.
Differential Revision: https://phabricator.services.mozilla.com/D162946
This will provide us with more information with which to discover what
IPC messages are being sent extremely frequently, especially from
background processes, and what we can do to avoid unnecessary wakeups.
This is intended for power usage work, and is being tracked in a similar
way to the thread wakeups work, based on process types, such that the
data can be compared between the two.
Differential Revision: https://phabricator.services.mozilla.com/D157855
This will provide us with more information with which to discover what
IPC messages are being sent extremely frequently, especially from
background processes, and what we can do to avoid unnecessary wakeups.
This is intended for power usage work, and is being tracked in a similar
way to the thread wakeups work, based on process types, such that the
data can be compared between the two.
Differential Revision: https://phabricator.services.mozilla.com/D157855
This is less of lie and avoids calling Mapped() twice. Once during
SharedMemoryBasic::Create and once during SharedMemoryBasic::Map.
This fixes shmem-mapped giving the appearence of leaking because
of the double counting.
Differential Revision: https://phabricator.services.mozilla.com/D160990
It seems RHEntryInfoToRHEntry may sometimes fail because deserializing the
principal fails. However, in this case `NS_ENSURE_SUCCESS(rv, rv);` does
nothing and is probably just a left-over from a refactoring.
If we don't bail early we may wind up with a nullptr in the redirectHistory
chain, which is most unexpected.
Differential Revision: https://phabricator.services.mozilla.com/D159373
Yulia Startsev
Sebastian Hengst
Manuel Bucher
Csoregi Natalia
Nika Layzell
Alexandre Lissy
Kelsey Gilbert
Marian-Vasile Laza
Magnus Melin
Noemi Erli
Dana Keeler
Jan Varga
Randell Jesup
Butkovits Atila
Nicolas Silva
Cristian Tuns
Cosmin Sabou
Iulian Moraru
Sandor Molnar
Jeff Muizelaar
Bobby Holley
Stanca Serban
Jens Stutte
Valentin Gosu