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.
Depends on D8945
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
This patch adds some telemetry histograms:
* CONTENT_PROCESS_LAUNCH_IS_SYNC - boolean, true if the content process
was launched synchronously (blocking the main thread)
* CONTENT_PROCESS_SYNC_LAUNCH_MS - the time consumed by sync launch;
the main thread will be busy or blocked for this entire time
* CONTENT_PROCESS_LAUNCH_TOTAL_MS - the total time elapsed from the
start of async content process launch until the launch promise is
resolved and the ContentParent can be sent IPDL messages
* CONTENT_PROCESS_LAUNCH_MAINTHREAD_MS - the time consumed on the parent
process main thread during async content process launch; typically this
is due to ContentParent::Init.
* CHILD_PROCESS_LAUNCH_MS - for any kind of Gecko child process
(including plugins, GPU, etc.), the time taken in the common process
launch code (which is run off-main-thread)
The probes restricted to async content process launch don't have "async"
in the name because that will eventually become the only kind of content
process launch.
Depends on D8943
Differential Revision: https://phabricator.services.mozilla.com/D8944
--HG--
extra : moz-landing-system : lando
There are several layers to this patch:
1. GeckoChildProcessHost now exposes a promise that's resolved when
the process handle is available (or rejected if launch failed), as a
nonblocking alternative to LaunchAndWaitForProcessHandle.
2. ContentParent builds on this with the private method
LaunchSubprocessAsync and the public method PreallocateProcessAsync;
synchronous launch continues to exist for the regular on-demand launch
path, for the time being.
3. PreallocatedProcessManager now uses async launch, and handles the new
"launch in progress" state appropriately.
Depends on D8942
Differential Revision: https://phabricator.services.mozilla.com/D8943
--HG--
extra : moz-landing-system : lando
The first attempt at async launch tried to hide the asynchrony inside
IPC, by making the process seem to be launched enough to construct new
channels and send it messages, and lazily blocking on the pid/handle.
Unfortunately, in practice we wind up needing the pid/handle immediately,
and this requirement is too deeply embedded in IPC for that to be viable.
(The alternative that will be used instead -- exposing process launch via
an explicitly asynchronous promise interface -- is made simpler by
Project Fission's upcoming rewrite of how the DOM requests new content
processes.)
Depends on D8941
Differential Revision: https://phabricator.services.mozilla.com/D8942
--HG--
extra : moz-landing-system : lando
The CONTENT_PROCESS_LAUNCH_TIME_MS histogram is currently gathering times
from two different spans of the launch process and mixing them together;
it's at best a rough approximation of "launch time".
In addition, with async launch we'll want to gather different metrics
than for sync launch (see comments on bug 1474991).
So I'm removing this histogram and will replace it with separate sync and
async metrics in bug 1474991; I intend to land both bugs' patches at or
near the same time, so we won't have a gap in getting some kind of data.
Depends on D8940
Differential Revision: https://phabricator.services.mozilla.com/D8941
--HG--
extra : moz-landing-system : lando
This fixes/adjusts two things about how content process preallocation is blocked:
1. Processes aren't registered as blockers until after they launch
successfully. The main goal is to not leak a blocker if launch fails,
but we don't need to block *while* launching synchronously, because this
all happens on the main thread.
2. Preallocated processes themselves aren't blockers. The main goal
here is so that async preallocation doesn't need extra complexity to
avoid being blocked by itself when launch completes. This mostly
doesn't affect actual behavior, because we currently support at most
one preallocated process. The difference is the window from when the
process is sent its first PBrowserConstructor until when it's next idle,
where there is now no longer a blocker, but this seems to be relatively
short (~100ms) and we don't even try to launch a new process until at
least 1s + an idle runnable.
This patch does not explicitly RemoveBlocker in ActorDestroy like the
first attempt did, because it's unnecessary: this is handled in the
ipc:content-shutdown observer.
Differential Revision: https://phabricator.services.mozilla.com/D8939
--HG--
extra : moz-landing-system : lando
When popping a dirty root, take the shallowest one first (so we reflow from
outer frames first, to avoid potential duplicate reflow of inner frames).
Prevent duplicate roots (to be reworked in a future bug).
Differential Revision: https://phabricator.services.mozilla.com/D9490
--HG--
extra : moz-landing-system : lando
As mDirtyRoots will be accessed through a more cohesive API, this patch hides
the storage details (nsTArray) -- but provides almost the same API for now.
Differential Revision: https://phabricator.services.mozilla.com/D9489
--HG--
extra : moz-landing-system : lando
This patch tries to reduce the false-positive cases where
ArePointerEventsConsumable returns true even though the input events
won't actually result in panning. It does this by ascertaining the
direction of panning (if possible) in the current input block and
checking to see if panning can actually occur in that direction.
Previously it would just check if panning could occur without taking
into account the actual pan direction of the input events.
Differential Revision: https://phabricator.services.mozilla.com/D12824
--HG--
extra : moz-landing-system : lando
This is an idiot mistake. It refers window.event accidentally and it's still
disabled on Beta and Release channel. Therefore, we should make it refer
aEvent instead.
On the other hand, it might be better to make our lint check whether test
refers window.event directly or not because it may check odd result
accidentally.
Differential Revision: https://phabricator.services.mozilla.com/D12870
--HG--
extra : moz-landing-system : lando
This class wasn't applied due to a typo, and it's unnecessary anyway -- there's
a separate 'fieldset {...}' CSS rule further down in the file that has the same
effect (hiding the border and the textual contents).
Differential Revision: https://phabricator.services.mozilla.com/D12618
--HG--
extra : moz-landing-system : lando
Note that we don't get this correct for form controls yet, so the -002 test is annotated as "fails" for now.
Differential Revision: https://phabricator.services.mozilla.com/D12617
--HG--
extra : moz-landing-system : lando
Note that Firefox doesn't actually match this expectation yet, so I've added a
'fails' annotation to the manifest with the followup bug number.
Also, this patch makes several other improvements to this test:
- remove red background in testcase. This was making the testcase spuriously
fail in Chrome, because Chrome paints (at least) a 1px-tall background-area
on empty buttons, which meant a 1px-tall red area in the testcase vs. a
1px-tall gray area in the reference case.
- clear floats to prevent them from piling up awkwardly.
- use 'vertical-align:top' to turn off baseline alignment in parts of the test
where the testcase has text and the reference case does not (and where we're
not intentionally testing the baseline's influence on layout).
Depends on D12614
Differential Revision: https://phabricator.services.mozilla.com/D12615
--HG--
extra : moz-landing-system : lando
Just adding:
- a missing-but-needed forward-decl (in LayersLogging.h which is
included by files in layout/base).
- a 'using' decl (to provide layers::AnimationInfo).
- a missing-but-needed #include for nsCOMPtr.
Differential Revision: https://phabricator.services.mozilla.com/D12964
--HG--
extra : moz-landing-system : lando
Before, we always ran the "generate JNI wrappers" command and had the
command be smart about updating the output. Now we move the smarts to
the Gradle side to streamline the build.
Differential Revision: https://phabricator.services.mozilla.com/D12795
--HG--
extra : moz-landing-system : lando
This will be exploited later, when we start making the
`withGeckoBinaries` switch conditional on the tasks that Gradle is
going to execute.
Differential Revision: https://phabricator.services.mozilla.com/D12794
--HG--
extra : moz-landing-system : lando
I'm not sure how this ever worked in the `android-gradle-dependencies`
task -- it must have been because of `--continue`.
Differential Revision: https://phabricator.services.mozilla.com/D12793
--HG--
extra : moz-landing-system : lando
This has never been as useful as anticipated: we really aren't seeing
resource mismatches in the wild that need diagnostic aids.
Differential Revision: https://phabricator.services.mozilla.com/D12792
--HG--
extra : moz-landing-system : lando
