After enable Fission, we're not able to resume media in the different process, because the current way we use can only notify one process and would cause the media on other process can't be resumed.
Therefore, we should use the browsing context to notify the web content which might be on different processes.
Differential Revision: https://phabricator.services.mozilla.com/D18136
--HG--
extra : moz-landing-system : lando
This is important to allow creating BrowsingContexts outside of the process
where they are going to be used. This is largely a re-arrangement of existing
code.
There is currently no way to do this type of attaching for browsing contexts in
existing BrowsingContextGroups, which creates some limitations, but happens to
be sufficient for us in the current situation.
Differential Revision: https://phabricator.services.mozilla.com/D21095
--HG--
extra : moz-landing-system : lando
This is important to allow creating BrowsingContexts outside of the process
where they are going to be used. This is largely a re-arrangement of existing
code.
There is currently no way to do this type of attaching for browsing contexts in
existing BrowsingContextGroups, which creates some limitations, but happens to
be sufficient for us in the current situation.
Differential Revision: https://phabricator.services.mozilla.com/D21095
--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
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
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 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
This is needed because early in a content process's lifecycle, NeckoParent may
not have been created yet. This leads to issues when trying to redirect into a
fresh process which hasn't performed network loads yet. By sending the message
over PContent, we can be sure the APIs are available.
Differential Revision: https://phabricator.services.mozilla.com/D15608
--HG--
extra : moz-landing-system : lando
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
This has benefits both in terms of performance and memory usage. Aside from
the obvious savings of not loading additional JS scripts in every process,
this also allows us to move more of our expensive data collection work to a
background thread, where it doesn't risk janking both parent and content
processes.
MozReview-Commit-ID: 2A593R7bIKB
Differential Revision: https://phabricator.services.mozilla.com/D13872
--HG--
extra : rebase_source : ec634ee3a3b975809f542aa8077ad32236781452
The implementation is based on a cache (datastore) living in the parent process and sync IPC calls initiated from content processes.
IPC communication is done using per principal/origin database actors which connect to the datastore.
The synchronous blocking of the main thread is done by creating a nested event target and spinning the event loop.