We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
The database is accessible from the parent process due to to the sandbox thus it is required an IPDL protocol that will transfer the queries and the results
Differential Revision: https://phabricator.services.mozilla.com/D38313
--HG--
extra : moz-landing-system : lando
We implement some helpful functions in MediaControlUtils which can be used to notify controller when media starts/stops playing or become audible/inaudible.
For now, we can temporarily notify these changes in AudioChannelService where we have already known when media has these kinds of status changing.
Differential Revision: https://phabricator.services.mozilla.com/D38144
--HG--
extra : moz-landing-system : lando
This ensures that the object is not discarded while there are still in-flight
messages from the parent process, and vice-versa, which could cause crashes if a
CC was run before any pending messages have arrived.
Differential Revision: https://phabricator.services.mozilla.com/D36995
--HG--
extra : moz-landing-system : lando
Having to namespace these into GeckoChildProcessHost is annoying. The
|using| declarations help to some extent, but it's easier to just put
them in mozilla::ipc.
Differential Revision: https://phabricator.services.mozilla.com/D36538
--HG--
extra : moz-landing-system : lando
Depending on the timing of events, we can invoke InitInternal after
we've already torn down the compositor thread, which can make
CreateContentBridges fail, which in turn makes us unable to make a
correct InitRendering call. Implement the infrastructure to bail out in
this case.
Differential Revision: https://phabricator.services.mozilla.com/D36644
--HG--
extra : moz-landing-system : lando
With Fission enabled, remote types can have the form
webIsolated=<URI>. This is bad, because we store them in telemetry in
some places. This patch adds and uses a method that sanitizes remote
types.
Differential Revision: https://phabricator.services.mozilla.com/D36068
--HG--
extra : moz-landing-system : lando
Waiting for docshells and frameloaders to destroy will leave attached
browsing contexts attached too long. In case the children of a
browsing contexts cannot be cached we want to detach all of them as
soon as possible.
Also normalizes the use of BrowsingContext::mGroup.
Differential Revision: https://phabricator.services.mozilla.com/D33602
--HG--
extra : moz-landing-system : lando
Waiting for docshells and frameloaders to destroy will leave attached
browsing contexts attached too long. In case the children of a
browsing contexts cannot be cached we want to detach all of them as
soon as possible.
Also normalizes the use of BrowsingContext::mGroup.
Differential Revision: https://phabricator.services.mozilla.com/D33602
--HG--
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
This will allow to remove gfxPrefs later. On Windows in particular, the need to decide gfxPrefs vs StaticPrefs for the WMF decoders has caused several bugs in the past.
We will remove the confusion as a consequence.
Differential Revision: https://phabricator.services.mozilla.com/D30589
--HG--
extra : moz-landing-system : lando
This commit removes nsIRemoteTab as a parent class from BrowserParent,
so that BrowserHost is the only concrete implementation of nsIRemoteTab.
Some static_cast's are updated to cast to BrowserHost, and other places
have to be updated to pass a BrowserHost instead of a BrowserParent.
WindowGlobalParent had a getter to return it's managing BrowserParent
as a nsIRemoteTab. I couldn't find a use of this in-tree, so I've just
opt-ed to remove it. If there's a use-case, we can add something back
in.
Differential Revision: https://phabricator.services.mozilla.com/D31444
--HG--
extra : source : 810b7371987139844429d0206f9da6a7701a1efc
This commit replaces the direct use of the IPDL actors in nsFrameLoader with
the RemoteBrowser interface. Some special use cases are adapted to still use
the IPDL actors. In the future, we should burn these use cases down.
Differential Revision: https://phabricator.services.mozilla.com/D31442
--HG--
extra : source : 1bcf9f586c5582ddeb822f4c2be3ca314694337e
This commit removes nsIRemoteTab as a parent class from BrowserParent,
so that BrowserHost is the only concrete implementation of nsIRemoteTab.
Some static_cast's are updated to cast to BrowserHost, and other places
have to be updated to pass a BrowserHost instead of a BrowserParent.
WindowGlobalParent had a getter to return it's managing BrowserParent
as a nsIRemoteTab. I couldn't find a use of this in-tree, so I've just
opt-ed to remove it. If there's a use-case, we can add something back
in.
Differential Revision: https://phabricator.services.mozilla.com/D31444
--HG--
extra : rebase_source : 63070e3c2b90c9134f9106028e124935c8dad009
extra : histedit_source : 807f2ff684d86008077be07b0894f39a925fe778
This commit replaces the direct use of the IPDL actors in nsFrameLoader with
the RemoteBrowser interface. Some special use cases are adapted to still use
the IPDL actors. In the future, we should burn these use cases down.
Differential Revision: https://phabricator.services.mozilla.com/D31442
--HG--
extra : rebase_source : f3a53c733cfaee33bec4a74615f87fd636ddd22a
extra : histedit_source : 10c5071221fe61418ee7dc72668c99243f50087d
In GeckoView the nsINetworkLinkService doesn't work in the content process, as
we don't seem to have an AndroidBridge there, so just maintain the network
connection type on the ContentChild.
(I had considered keeping this on the NeckoChild, but the creation of that is
initiated from the content process side, and there's not an easy and clean way
to have the parent process send us the connection type after construction of
the NeckoParent, other than have the NeckoChild request it either
synchronously, or doing it async and hoping it's not asked for the value before
the response comes in.)
Differential Revision: https://phabricator.services.mozilla.com/D26232
--HG--
extra : moz-landing-system : lando