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
The root PBrowser actor needs special case visibility behavior to satisfy the async tab
switcher. This commit adds a flag to track whether a BrowserChild is part of the root
actor.
Differential Revision: https://phabricator.services.mozilla.com/D33046
--HG--
extra : rebase_source : 5f7cb11f77d41f3265d211e99713a1dad6ae2579
extra : intermediate-source : 49e4d0e4fc7ccfa7b2c58bb9b64534c2d569a881
extra : source : adcc870662770a99962e721bd3c5ff4c2616c21d
This bug will use the browsing context to notify content tab to mute/unmute media, instead of using MessageManager. We would use the top level canonical browsing context to
set the media mute property for the top level window and propagate it to other top level windows in other processes.
If we don't do so, we're not able to mute/unmute media in the different process when we we enable Fission, because the current way we use can only notify one process and would cause the media on other process can't be muted/unmuted.
Differential Revision: https://phabricator.services.mozilla.com/D32077
--HG--
extra : moz-landing-system : lando
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
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
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
This makes restoring from bfcache send less messages. It also
separates detach/attach from the caching logic, making it more clear
that caching is going on.
Differential Revision: https://phabricator.services.mozilla.com/D28670
--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
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
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
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
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
Dorel Luca
Garvan Keeley
Ciure Andrei
Erica Wright
Bas Schouten
Andreas Farre
Noemi Erli
Jonathan Kingston
Matt Woodrow
Matthew Gregan
Ryan Hunt
Johann Hofmann
John Dai
Alastor Wu
Andrea Marchesini
Chris Pearce
Liang-Heng Chen
Andreea Pavel
Perry Jiang
Jonathan Kew
Bogdan Tara
Nika Layzell
Eden Chuang
Cameron McCormack
Cosmin Sabou
Thomas Nguyen