nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
In this part, we pass along the navigation type (and index for when using the
dropdown on the back/forward buttons). This allows us to check if there's a
top-level load "between" the start and end pages.
The patch might look a bit strange, since we're passing the navigation
operation to two places from RemoteWebNavigation.js (the normal message passing
that existed before this patch and the HangMonitor channel in this patch). This
is primarily to make it easier to stop passing the navigation info along the
HangMonitor channel once session history is uplifted into the parent process.
At that point, the check for whether there's a top-level load could happen in
TabParent (I think).
Differential Revision: https://phabricator.services.mozilla.com/D23090
--HG--
extra : moz-landing-system : lando
This patch passes a message through the HangMonitor channel when navigating
through history to cancel content JS that could hang the chrome JS in the
content process responsible for history navigation. If the content JS is
actually canceled, this also disables the BF cache for the current page, since
it could end up in an inconsistent state due to the JS cancellation.
Differential Revision: https://phabricator.services.mozilla.com/D23089
--HG--
extra : moz-landing-system : lando
FileCreatorHelper creates a FileBlobImpl on the main-thread and, because of
this, we end up executing I/O operations on that thread, slowing down other
components. With this patch, FileCreatorHelper logic is moved to PBackground.
That the 'type' getter is still called on the main-thread because FileBlobImpl
uses nsIMIMEService which is a non thread-safe component.
Differential Revision: https://phabricator.services.mozilla.com/D27641
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
This code was already present but it had two flaws: the first one was that the
variable used to prevent minidumps from being taken when shutting down was not
being initialized which caused it to be true most of the time and thus
prevented captures even in valid scenarios. The second was that we relied on
the "profile-before-change" change event to detect shutdown but this often
happens after we've already started closing tabs and shutting down processes
thus the minidump generation would often race against it.
Differential Revision: https://phabricator.services.mozilla.com/D24691
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
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.
This devirutalizes a bunch of methods, and moves the entire implementation into
`Content{Parent,Child}` proper. The only purpose left for these types is as a
collection of interfaces and an IID for casting. They should likely be removed
entirely in a follow-up.
Depends on D20552
Differential Revision: https://phabricator.services.mozilla.com/D20553
--HG--
extra : moz-landing-system : lando
These casts are now unnecessary after Part 2, due to all consumers directly
using `ContentParent`.
Depends on D20551
Differential Revision: https://phabricator.services.mozilla.com/D20552
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
This devirutalizes a bunch of methods, and moves the entire implementation into
`Content{Parent,Child}` proper. The only purpose left for these types is as a
collection of interfaces and an IID for casting. They should likely be removed
entirely in a follow-up.
Depends on D20552
Differential Revision: https://phabricator.services.mozilla.com/D20553
--HG--
extra : moz-landing-system : lando
These casts are now unnecessary after Part 2, due to all consumers directly
using `ContentParent`.
Depends on D20551
Differential Revision: https://phabricator.services.mozilla.com/D20552
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
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
Pass sandbox parameters to content processes on the command
line allowing for early sandbox startup. Limited to Nightly
until confirmed to be stable and ready to ride the trains.
Enable early sandbox startup by default on Nightly and use
pref "security.sandbox.content.mac.earlyinit" to disable
early startup for debugging purposes.
Once early startup is 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
Pass sandbox parameters to content processes on the command
line allowing for early sandbox startup. Limited to Nightly
until confirmed to be stable and ready to ride the trains.
Enable early sandbox startup by default on Nightly and use
pref "security.sandbox.content.mac.earlyinit" to disable
early startup for debugging purposes.
Once early startup is 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
