Android mercilessly kills the parent in low memory situations, and we
don't want that to trigger a crash when the child is abruptly
disconnected.
Differential Revision: https://phabricator.services.mozilla.com/D16234
--HG--
extra : moz-landing-system : lando
Launching processes takes enough time that we should avoid blocking the
parent process's IPC I/O thread for it; it's less bad for responsiveness
than blocking the main thread, but it's not good.
On Windows we need to use a dedicated thread, because the sandbox isn't
thread-safe and it asserts that the same thread is used for every
launch. Otherwise, a thread pool is used. (Or, in the Web Replay
middleman process, where there isn't enough of XPCOM for any of this,
launching the actual content processes remains on the I/O thread.)
Depends on D15886
Differential Revision: https://phabricator.services.mozilla.com/D8946
--HG--
extra : moz-landing-system : lando
We can directly set environment variables for the child process on
all platforms now, instead of changing the parent's environment and
inheriting the changes. This simplifies memory management, but more
importantly it's necessary for thread safety to allow launching
processes from a thread pool.
Depends on D8944
Differential Revision: https://phabricator.services.mozilla.com/D8945
--HG--
extra : moz-landing-system : lando
MozPromise most common use is to have an single or exclusive listener. By making the MozPromise generated by IPDL exclusive we can also use move semantics.
While at it, we also use move semantics for the ResponseRejectReason and via the callback's reject method so that the lambda used with the MozPromise::Then can be identical to the one used by the IPDL callback.
As it currently is, it provides no advantage over a copy as it's just an enum; however, this will facilitate future changes where it may not be.
Differential Revision: https://phabricator.services.mozilla.com/D13906
--HG--
extra : moz-landing-system : lando
When shutting down a content process, we call `Close` on the
`IToplevelProtocol`. This causes the MessageChannel to be `Close`-ed,
which in turn sends a `GOODBYE_MESSAGE`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#2852
This message is intercepted on the I/O thread in the content process,
before any code is informed in content, and used to set the
`mChannelState` property to `ChannelClosing`:
https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/ipc/glue/MessageChannel.cpp#1176
Once this state has been set, which is performed as soon as the
message is received, whether or not other messages have been processed
yet, no messages can be sent back to the parent process. This is
usually what causes the 'Too late to send/recv' message spam in the
console, as we're still trying to send messages at this time.
Usually this is fine - the message send fails, but we gracefully
recover, and the process begins shutting down like normal.
Unfortunately, child actor constructors currently have code
automatically generated in them which causes a process crash if the
send fails. As it's impossible for the main thread to know that the
channel has been closed ahead of time (due to this happening
out-of-band), we can then cause random content process crashes
during shutdown due to actor construction.
Unfortunately, we can't just destroy the actor, as our caller may
(and often do) depend on the actor reference they gave us still being valid
after calling Send*Constructor. Fortunately, if a message send failed, it means
we're in the process of being shut down.
This patch handles this by ignoring ctor send errors, and treating them like
messages which successfully were queued to send, but got lost due to the other
side hanging up. The actor will be gracefully destroyed in DestroySubtree when
its manager is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D12695
This allows getting the set of all window globals for a given browsing context.
This is less useful at the moment as the active window global is not exposed as
such. That will be added as a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D9393
This actor can be used for communicating with individual frames, without
depending on walking the tree in the content process.
This is not yet complete. No tests have been written for it, the
WindowGlobalParent objects need to be exposed to chrome JS, and a form of JS
actors should be installed under them.
In addition, BrowsingContextChrome objects should be updated to allow access to
the current WindowGlobalParent in that context.
Differential Revision: https://phabricator.services.mozilla.com/D4623
This will be useful as a basis for asynchronous actors which would like to exist
both when crossing the process boundary (managed by PContent), and when
displaying an in-process window.
Differential Revision: https://phabricator.services.mozilla.com/D4622
To create a more generic interface for interacting both within the main thread
of the parent process and between the parent and child processes, it would be
nice to support IPDL actors within the main thread of the parent process. This
requires the underlying MessageChannel actor to support intra-thread links.
This change adds support for intra-thread links to the underlying MessageChannel
object using ThreadLink, and an extra boolean flag.
Differential Revision: https://phabricator.services.mozilla.com/D4620
Cosmin Sabou
James Willcox
Coroiu Cristina
Michael Froman
Jed Davis
Nathan Froyd
Dave Townsend
Jacek Caban
David Major
Jeff Walden
Andrea Marchesini
Alex Gaynor
Gabriele Svelto
Bogdan Tara
Sylvestre Ledru
Razvan Maries
Bob Owen
Dorel Luca
Jean-Yves Avenard
Ted Campbell
Nika Layzell
Jan Varga
Tooru Fujisawa