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
Alex Gaynor
Brindusan Cristian
Nika Layzell
Tarek Ziadé
Boris Zbarsky
Ciure Andrei
Noemi Erli
Nathan Froyd
Andreea Pavel
Christoph Kerschbaumer
Andreas Farre
Makoto Kato
Bogdan Tara
Jan Varga
Oana Pop Rus
Blake Kaplan
Dimi Lee
Alastor Wu
Michael Froman
Cosmin Sabou
Andrea Marchesini
Peter Van der Beken
Ehsan Akhgari
Jed Davis