This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
The crash helper process is started when the first exception handler is set
on desktop platforms and before loading libxul on Android. In both cases
starting this process happens asynchronously so that neither the main process
nor child processes have to wait for it to come up. If a crash happens before
the crash helper has started, the crashed process will wait for it to fully
come up and then proceed with regular crash generation.
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
The crash helper process is started when the first exception handler is set
on desktop platforms and before loading libxul on Android. In both cases
starting this process happens asynchronously so that neither the main process
nor child processes have to wait for it to come up. If a crash happens before
the crash helper has started, the crashed process will wait for it to fully
come up and then proceed with regular crash generation.
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This involved moving the logic into ProcessIsolation.cpp, closer to the rest of
the process selection logic. The existing method is preserved, to be used as a
convenience for callers.
As the new logic is closer to the rest of the process selection logic, this
also simplifies the remote type parsing logic to perform direct string compares
against the remoteType's site-origin. If origin keying of processes is added in
the future, this will likely need to be updated to handle that case.
Differential Revision: https://phabricator.services.mozilla.com/D241879
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
This implements the crash helper service used to move child process crash
report generation out of the main process and into its own process. This is
implemented as a separate executable that is launched on startup by the main
process on the desktop platforms and as a service hosted by a separate process
on Android.
One limitation of the current code is that the crash helper process needs to
be running before we can start setting exception handlers in child processes.
This limitation is due to how Breakpad exception handlers register themselves
with the crash generator and prevents us from lazily starting the helper (or
restarting it on Android).
IPC with the crash helper is implemented using Unix sockets on Linux and macOS
with the former using sequential packets and the latter using stream sockets.
On Windows we use named pipes. In all cases the choice of IPC was dictated both
by the requirement to eventually talk directly to child processes from within
the sandbox, and to external processes in case of Windows as the Windows
Error Reporting exception handler must be able to reach out to the helper from
within a restricted context. These particular requirements are not used yet but
will be as we move more logic out of the main process logic.
Differential Revision: https://phabricator.services.mozilla.com/D231083
Without this change if we're in a new process, we won't lower the priority when
navigating a background browser into the process. This should ensure we always
re-compute priority after creating a new BrowserParent, even if the
BrowsingContext is not active.
Differential Revision: https://phabricator.services.mozilla.com/D229548
Use LayoutDevice units for most these things, since it's what they are:
ScreenIntSize(presContext->AppUnitsToDevPixels(size.width), ...
Is clearly a lie :)
Differential Revision: https://phabricator.services.mozilla.com/D228586
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
The canceledReason is added to the RequestData used to build the
RemoteWebProgressRequest. This canceledReason is useful for consumers such
as WebDriverBiDi which need to emit different error messages depending on
the reason why a specific navigation request was canceled.
Differential Revision: https://phabricator.services.mozilla.com/D223174
Currently, `EventStateManager` handles some content commands only in the parent
process. Therefore, if `eSetSelection` event or something is being handled in
the focused remote process, the command may be disabled yet.
Avoiding the race conditions, we should handle the content command events in the
focused process.
Differential Revision: https://phabricator.services.mozilla.com/D222789
Currently, `EventStateManager` handles some content commands only in the parent
process. Therefore, if `eSetSelection` event or something is being handled in
the focused remote process, the command may be disabled yet.
Avoiding the race conditions, we should handle the content command events in the
focused process.
Differential Revision: https://phabricator.services.mozilla.com/D222789
This comment assumes dom.events.datatransfer.protected.enabled=false. when
dom.events.datatransfer.protected.enabled=true (which matches the spec and is
not the default), the behavior is fine as-is.
Since bug 1871222 (by one perspective) moved drag sessions from PContents to
PBrowsers, we need to update permission handling for in-process "remote"
sessions (ones that started on one PBrowser and currently target another). When
the target and source are in the same process, they don't properly handle
privileged DataTransfer access. We are currently denying privileged access to
some in-process principals because we incorrectly use the system principal. The
system principal always happens to give the right result for out-of-process
remote sessions, which were the only kind that existed before bug 1871222.
This solution creates the "remote" DataTransfer with the "correct" (not system)
principal of its source content. However, this misses the case where two
different browsers are at the same location (same principal) -- each would
incorrectly get privileged access to the other's DataTransfer in a drag. We
avoid that case by limiting the change to extension processes. This means that
remote DataTransfers created in the extension process will check for protected
access using a principal check against the drag-source-element's principal but,
otherwise, DataTransfers will continue to use the system principal for the
check.
Differential Revision: https://phabricator.services.mozilla.com/D219074
MustUpdateDataTransfer is a simple function that makes more sense on
nsIDragSession.
MaybeAddBrowser records BrowserParents for processes with existing drag
sessions. There may be such processes before the parent process
even has a drag session, so they cannot be tied to drag sessions. We tie
them to the drag service, until the service creates a drag session in
the process, at which point we move them to the drag session. Since
the session and service are still the same object and each now has methods
with these names, we leave part of session's implementation commented out
so that we run correctly instead of looping infinitely. The code is
exposed when the objects separate later in the patch series.
Finally, the implementation of TakeSessionBrowserListFromService currently
amounts to a nop, but it will have substace when the service and session
are separated.
Differential Revision: https://phabricator.services.mozilla.com/D211081
nsBaseDragService keeps track of the processes that might need to cancel a drag with EndDragSession and this is technically correct since the drag session is a singleton in the child process, but this series of patches changes those sessions to be per-PuppetWidget/BrowserChild. This allows content processes to distinguish which of its browsers is engaged in a drag.
Differential Revision: https://phabricator.services.mozilla.com/D211062
Updates each client of the nsContentUtils method to get the right drag session -- the one for the widget that is currently the source or target of the drag session.
The change to nsDOMWindowUtils::DispatchDOMEventViaPresShellForTesting() supports the change to WidgetDragEvent::InitDropEffectForTests() and enabled a
large number of test fixes in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D211067
Add synthesizeMockDragAndDrop test function to test elements
drag-dropped inside of Firefox. This uses the new MockDragService to
avoid native DND. It is a more-complete variant of synthesizeDragAndDrop
and synthesizePlainDragAndDrop. It works by:
1. Creating the environment for the test.
2. Gathering coordinates of the source and target elements from their
respective content processes.
3. Setting up event handlers on the elements to detect any relevant events
they may receive. This allows us to detect not only events that aren't sent
when they should be but also events that are sent that shouldn't be.
4. Synthesizing mouse events to initiate the drag-session. This and
the remaining steps work by first telling the relevant content process(es)
what events to expect (and which not to), then sending the event, and
finally collecting the results and submitting them to mochitest.
5. Synthesizing drag events with the MockDragServiceController, to emulate
the behavior of (Windows) native drag-and-drop. This is a coarse
approximation of the Win32 API DoDragDrop.
6. Cleaning up the event handlers.
The test does not yet try to mock things like the drag cursor image, although
that should be possible without native DND behavior. The same is true for
some more minor aspects of the platform-specific behavior of our DND.
Differential Revision: https://phabricator.services.mozilla.com/D205641
This is a fairly significant patch, however it would be difficult to break it
down into smaller patches:
1) The various mechanisms used to manage ContentParent lifecycles have been
merged together into a common "KeepAlive" system. A process will
begin shutdown when its keepalive count reaches 0. (though it will
still wait for all BrowserParents to also be dead before sending the
actual shutdown message as before).
This replaces a number of bespoke systems for tracking BrowserParent
instances in different lifecycle states, remote workers, ongoing
process switches, and preallocated processes.
2) KeepAlives are now managed automatically by a UniquePtr variant
(Unique[Threadsafe]ContentParentKeepAlive). This makes the hand-off
over KeepAlive lifecycles explicit, even for workers.
3) All KeepAlives are now keyed by a BrowserId, which will be 0 for keepalives
not associated with a specific tab. This allows the new process
selection logic to count all tabs other than the one being navigated
when deciding which process to use.
4) The process switching logic now tracks it's KeepAlive with a BrowserId,
meaning that ongoing process switches are considered when performing
process selection, even if the BrowserParent hasn't been created yet.
Differential Revision: https://phabricator.services.mozilla.com/D213338
