If GetMainThreadIdleScheduler is called after IPC is destroyed it can
attempt to start it as if it's the first use, which crashes. Instead check
if we've already destroyed the scheduler once and if so then return early.
Differential Revision: https://phabricator.services.mozilla.com/D119251
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
mozilla-central has some imported files of build_config.h from Chromium.
Actually although they doesn't have riscv64 defines yet, I would like to
add it to build Firefox for riscv64.
Differential Revision: https://phabricator.services.mozilla.com/D119051
This patch launches content processes with the `MOZ_HEADLESS` env var set
if they're using GTK with an X11 display (and there's no other reason
they'd need GTK).
The goal is to avoid exhausting Xorg's default limit of 256 clients if
there are many content processes due to Fission. If these conditions
are met, the content process doesn't need to eagerly connect to the X
server. This does not affect the sandbox policy, and content processes
can still use X if needed for, e.g., WebGL.
The boolean pref `dom.ipc.avoid-gtk`, set by default, controls this
feature. In the future it could also be extended to minimize GTK use
with Wayland displays.
Note that disabling `widget.non-native-theme.enabled`, which is also
enabled by default, will restore the use of X11 in all content processes
even if this pref is set; the alternative is that widgets wouldn't render
in that case.
This change will also save some memory for now-unnecessary instances of
GTK's global state, and improve content process startup time.
Remove also the temp pref dom.ipc.remote-mozIcon because it cannot work
anymore with the content process being headless.
Differential Revision: https://phabricator.services.mozilla.com/D112197
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This removes the last form of unique link between two MessageChannels so that
all MessageChannels communicate using PortLink, as it is fairly straightforward
to use PortLink to communicate between two threads in-process.
Differential Revision: https://phabricator.services.mozilla.com/D116672
This adjusts how all actors created using `Endpoint` behave so that they now
use ports instead of creating a unique native channel connection between each
pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D116670
These port attachments are stored directly on the IPC::Message until the
message is ready to be routed to another process, at which point they will be
attached to the port in WillBeRoutedExternally. When the message is then
received on the other side, the ports will be re-extracted from the
UserMessageEvent before it is discarded and re-added to the IPC::Message so
that serializers only need to interact directly with the IPC::Message type.
Differential Revision: https://phabricator.services.mozilla.com/D116669
This is used because, unlike in Mojo, we cannot get from the IPC::Message
object to its enclosing UserMessageEvent object to attach more ports to it, and
this extra parameter makes that easy to do.
Differential Revision: https://phabricator.services.mozilla.com/D116668
This unfortunately requires a new method to be added to BufferList to
support truncating the buffer to a particular iterator.
Differential Revision: https://phabricator.services.mozilla.com/D116666
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 also consumes the existing channel created when launching a process to
create the the conneciton required by NodeController for communicating between
processes. In part 12b, consumers of the broken APIs will be adjusted to use
the new interface.
The new routing approach is not used for the fork server process, as an IO
thread and the NodeController object cannot be initialized before the fork has
been performed, and the IPC requirements of that process are fairly minimal.
Differential Revision: https://phabricator.services.mozilla.com/D112776
The NodeController and NodeChannel types act as the backbone connecting the
existing IPC logic and driving the ports routing code. Individual NodeChannel
objects wrap and respond to messages from IPC::Channel, and the NodeController
orchestrates all messaging for a process.
The design of these types are inspired by the types with the same names from
Mojo but have been simplified and streamlined to only support features used by
Gecko.
Support for attaching ports or handles to messages hasn't been added yet, but
can be added in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D112775
These will be used to serialize extra event metadata into IPC messages when
they're sent over the ports infrastructure. In the future better integration
may be used to reduce the overhead of this if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D112773
The ports library import came with 2 gtests. This patch gets them running under
our gtest runner to ensure we don't break the ports functionality.
Differential Revision: https://phabricator.services.mozilla.com/D112768
This removes the last form of unique link between two MessageChannels so that
all MessageChannels communicate using PortLink, as it is fairly straightforward
to use PortLink to communicate between two threads in-process.
Differential Revision: https://phabricator.services.mozilla.com/D116672
This adjusts how all actors created using `Endpoint` behave so that they now
use ports instead of creating a unique native channel connection between each
pair of processes.
Differential Revision: https://phabricator.services.mozilla.com/D116670
These port attachments are stored directly on the IPC::Message until the
message is ready to be routed to another process, at which point they will be
attached to the port in WillBeRoutedExternally. When the message is then
received on the other side, the ports will be re-extracted from the
UserMessageEvent before it is discarded and re-added to the IPC::Message so
that serializers only need to interact directly with the IPC::Message type.
Differential Revision: https://phabricator.services.mozilla.com/D116669
This is used because, unlike in Mojo, we cannot get from the IPC::Message
object to its enclosing UserMessageEvent object to attach more ports to it, and
this extra parameter makes that easy to do.
Differential Revision: https://phabricator.services.mozilla.com/D116668
This unfortunately requires a new method to be added to BufferList to
support truncating the buffer to a particular iterator.
Differential Revision: https://phabricator.services.mozilla.com/D116666
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 also consumes the existing channel created when launching a process to
create the the conneciton required by NodeController for communicating between
processes. In part 12b, consumers of the broken APIs will be adjusted to use
the new interface.
The new routing approach is not used for the fork server process, as an IO
thread and the NodeController object cannot be initialized before the fork has
been performed, and the IPC requirements of that process are fairly minimal.
Differential Revision: https://phabricator.services.mozilla.com/D112776
The NodeController and NodeChannel types act as the backbone connecting the
existing IPC logic and driving the ports routing code. Individual NodeChannel
objects wrap and respond to messages from IPC::Channel, and the NodeController
orchestrates all messaging for a process.
The design of these types are inspired by the types with the same names from
Mojo but have been simplified and streamlined to only support features used by
Gecko.
Support for attaching ports or handles to messages hasn't been added yet, but
can be added in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D112775
These will be used to serialize extra event metadata into IPC messages when
they're sent over the ports infrastructure. In the future better integration
may be used to reduce the overhead of this if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D112773