Alloc methods can't take arguments by move reference, whereas Recv
methods can, and we'd like to take OptionalLoadInfoArgs (at least) by
move reference. Since Init is infallible anyway, it doesn't really
matter where we do it, so move it to this separate method to pave the
way for rvalue reference OptionalLoadInfoArgs.
nsSystemInfo is initialzied at first page load. Actually, content process uses
sync IPC to get Android OS information. But now, we can use Java code even if
on content process, so we should use JNI directly instead of sync IPC.
Also, nsSystemInfo still has unused extern android_sdk_version that is for
HoneyComp's DNS hack. So let's remote it.
Differential Revision: https://phabricator.services.mozilla.com/D20129
--HG--
extra : moz-landing-system : lando
Add the origin ContentParent to a CanonicalBrowsingContext's group
when a CanonicalBrowsingContext is created from IPC. With this it is
possible to keep track of all child processes associated with a
BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D19004
--HG--
extra : moz-landing-system : lando
Add the origin ContentParent to a CanonicalBrowsingContext's group
when a CanonicalBrowsingContext is created from IPC. With this it is
possible to keep track of all child processes associated with a
BrowsingContextGroup.
Differential Revision: https://phabricator.services.mozilla.com/D19004
--HG--
extra : moz-landing-system : lando
This patch changes the logic such that we use the new direct
BrowsingContext ParamTraits implementation when possible, and avoids
doing manual lookups.
Depends on D19178
Differential Revision: https://phabricator.services.mozilla.com/D19179
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Alloc/Dealloc methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18131
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
Summary:
The push notifier needs to proxy its calls to the proper process in order to
notify service workers. With parent-intercept enabled, that means making sure
we notify in the parent and without it, that we notify in the content process.
Fortunately, we already have to do this proxying for the observer
notifications, so we can just piggyback on top of that code to make things
work for service workers.
Reviewers: asuth
Reviewed By: asuth
Bug #: 1517406
Differential Revision: https://phabricator.services.mozilla.com/D15634
--HG--
extra : rebase_source : a29216f3a6638592a784e7e830fe9f7842cce7e9
No one is using the aUseTrackingProtection parameter and also tracking
protection related preference in Classify API. And we shouldn't use it
that way in the future.
Differential Revision: https://phabricator.services.mozilla.com/D16798
--HG--
extra : moz-landing-system : lando
Everytime we set the flag on top level BrowsingContext, it would automatically be sync to its corresponding ChromeBrowsingContext.
Differential Revision: https://phabricator.services.mozilla.com/D15436
--HG--
extra : moz-landing-system : lando
The current code assumes that it can get the ServiceWorkerManager in the child
process to send a message to the proper service worker. That isn't true, we
need to ask the parent to do it for us.
Differential Revision: https://phabricator.services.mozilla.com/D14773
--HG--
extra : moz-landing-system : lando
Some prefs need to be available before IPC is started, so we serialize a
snapshot when we start launching the process, and then stream further
changes over IPC messages. However, async launch introduces a window
between the snapshot and when the parent can start sending messages,
during which other code can run on the main thread and change prefs.
In order to not lose those updates, they're queued and sent when the
launch is complete.
Depends on D14089
Differential Revision: https://phabricator.services.mozilla.com/D14090
--HG--
extra : moz-landing-system : lando
We need content processes that are created but not finished launching
(not "alive" yet) to be treated differently from ones that have exited
(no longer "alive"), so the boolean mIsAlive is expanded to a 3-state
enumeration, which could be expanded more in the future if needed.
(This is similar to GeckoChildProcessHost::mProcessState, but it's
synchronized with the rest of the ContentParent's state, which can lag
the GeckoChildProcessHost state due to runnable dispatch.)
This patch also removes mIsAvailable/IsAvailable/MarkAsTroubled, which
are unused as of bug 1459212.
Differential Revision: https://phabricator.services.mozilla.com/D14089
--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
By replacing nsWebBrowser's implementation of the
nsIBaseWindow.initWindow and nsIBaseWindow.create with a new static
nsWebBrowser::Create method we make it possible to pass arguments
directly when creating an nsWebBrowser, for example the opener
BrowsingContext. As a bonus we can do away with
nsWebBrowser::mInitInfo!
Differential Revision: https://phabricator.services.mozilla.com/D12634
--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
This patch also takes the timeout for killing a content process back to its
original value and removes a related but long unused field.
Differential Revision: https://phabricator.services.mozilla.com/D11739
--HG--
extra : moz-landing-system : lando
Cache the sandboxing command line parameters used when starting a new content process, avoiding calls to realpath(3) on the main thread in the parent process for each content process that is started.
Differential Revision: https://phabricator.services.mozilla.com/D10529
--HG--
extra : moz-landing-system : lando
This commit removes the PRenderFrame protocol, while keeping the same ordering
and semantics of graphics IPC initialization.
To do this, some messages are added to PBrowser to simulate the constructor
and destructor of PRenderFrame. Messages that expected a nullable PRenderFrame
are updated to get a boolean instead.
One tricky area is the destruction of PRenderFrame. I've tried to keep it the
same as much as possible, but it's possible it might be slightly semantically
different than IPDL destruction. Destruction will be touched up in a later
patch, so I'm not too concerned.
Differential Revision: https://phabricator.services.mozilla.com/D11057
--HG--
extra : rebase_source : bb8a7896bb4aefb6e9957d8808b755fa76cc00ed
extra : histedit_source : 6377819a946b5b6bc18b15f748229360e42a6f3a
Content process of Android uses sync IPC when initializing LookAndFeel. But
current e10s has LookAndFeel cache for start up of content process.
So we should use it, then remove sync IPC for start up performance
Differential Revision: https://phabricator.services.mozilla.com/D9750
--HG--
extra : moz-landing-system : lando
Pass sandbox parameters to content processes on the command line allowing for early sandbox startup.
Pref'd off behind "security.sandbox.content.mac.earlyinit" until it's ready to be enabled by default.
Once early startup is enabled by default and considered stable, the original sandbox startup code can be removed.
Depends on D6719
Differential Revision: https://phabricator.services.mozilla.com/D6720
--HG--
extra : moz-landing-system : lando
