This commit moves the actual implementation of nsIRemoteTab from BrowserParent
to BrowserHost, without any functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D31445
--HG--
extra : source : d25963c72ff7981990660050182a82ea3e935f53
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 adds a link from BrowserParent to it's owning BrowserHost
if it is the root BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D31441
--HG--
extra : source : d3b2ac8d5ca4bd350603085c3cb9f6a51269e075
This reduces the amount of code that assumes that BrowserParent implements nsIRemoteTab.
Differential Revision: https://phabricator.services.mozilla.com/D31430
--HG--
extra : source : 5f1c1b609ec1ecc28734e1b6daeeb3f6854ded38
This commit moves the actual implementation of nsIRemoteTab from BrowserParent
to BrowserHost, without any functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D31445
--HG--
extra : rebase_source : 2e6533dfa69a3278300eb70d5258bcd0a3aba68b
extra : histedit_source : a26ba68b78eb6d16cdffbc630f4410c5dd46a367
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 adds a link from BrowserParent to it's owning BrowserHost
if it is the root BrowserParent.
Differential Revision: https://phabricator.services.mozilla.com/D31441
--HG--
extra : rebase_source : 8cb8fa816198fd2bf660f092227e92e69bc63c97
extra : histedit_source : 1597cb06d341ec87c27c67a1b8aa858fe0bfe8bc
This reduces the amount of code that assumes that BrowserParent implements nsIRemoteTab.
Differential Revision: https://phabricator.services.mozilla.com/D31430
--HG--
extra : rebase_source : d639864ba86001cf90a8b3d42b6eda97a7f829ac
extra : histedit_source : 6f6f1e0b6d3561e478391ce9e72a8a2dbc280983
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
The BrowserParent's IPC receive methods for nsIWebProgress events in the
BrowserChild were all doing the same set up to ensure they had the correct
state to process them. This has now been refactored out into a single method.
Differential Revision: https://phabricator.services.mozilla.com/D30730
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
The BrowserParent's IPC receive methods for nsIWebProgress events in the
BrowserChild were all doing the same set up to ensure they had the correct
state to process them. This has now been refactored out into a single method.
Differential Revision: https://phabricator.services.mozilla.com/D30730
--HG--
extra : moz-landing-system : lando
When changing processes and therefore destroying/rebuilding
frameloaders, add ability to keep the browsing context around and add
it to the new frameloader.
Differential Revision: https://phabricator.services.mozilla.com/D26267
When changing processes and therefore destroying/rebuilding
frameloaders, add ability to keep the browsing context around and add
it to the new frameloader.
Differential Revision: https://phabricator.services.mozilla.com/D26267
The next easy step is to move the getters below the static methods.
Differential Revision: https://phabricator.services.mozilla.com/D30156
--HG--
extra : rebase_source : a609823f9f19a51f73fe61fa910bc513c614378e
extra : source : 2e91e4b9d847b74f1514a14720c618bf1634d91e
extra : histedit_source : bd641bf544aa378544fb401b0b0a6768d63b48f3
The methods in BrowserParent are a bit disorganized. There's a lot to
do to fix that, but an easy first step is to move static methods to
the top of the class.
Differential Revision: https://phabricator.services.mozilla.com/D30155
--HG--
extra : rebase_source : 2fb0b7ad48030ba4682e6d0ded06b67494a0c330
extra : source : 05002949953c3df7a647e78a8a65975a19e23631
extra : histedit_source : a6b997485d7576962ce23dcfe86b419686c19b78
This is the followup to the previous patch, and attempts to organize
state to be a bit more logical.
Differential Revision: https://phabricator.services.mozilla.com/D30154
--HG--
extra : rebase_source : e85426e0c03857ceb4b89fab3fdb557e66ab9f2f
extra : source : c0221209ace4c85d66cd9b667e0699f50b923f1a
extra : histedit_source : 16d5f4a458dab48ab96741e449d50b8e8b48c5eb
Somehow all of the member variables of BrowserParent have been
spread around the class. This makes it really hard to understand
what state there is. This commit moves all member variables
(preserving order) to the bottom of the class.
Differential Revision: https://phabricator.services.mozilla.com/D30153
--HG--
extra : rebase_source : 377f5b55e5393a9ac6f88389f0589eb6fd66848c
extra : source : 033e99403d147fd11eaf7b2037f36e156d2598ff
extra : histedit_source : c20e5d02ca67c3f3eff3c1d77abb0f871a9025d2
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
We now also only access the document when the state is
nsIWebProgress::STATE_STOP. The comments in the previous code indicated that
touching the document inside the event handler when the state is not STATE_STOP
would result in the content creating a new about:blank document to retrieve the
values from. However, it then went on to do this in another location, causing a
document to be created whenever we received an onStateChange event. This should
no longer occur.
Differential Revision: https://phabricator.services.mozilla.com/D28125
--HG--
extra : moz-landing-system : lando
***
Removed IPC References in PCContent
***
Removed IPC References on nsContentPermissionHelper
***
Remove IPC Principal from PBrowser
***
Remove IPCPrincipal from the PaymentRequest
***
Remove IPCPrincipal from the PPresentation
***
Remove IPC Principal from PNecko
Differential Revision: https://phabricator.services.mozilla.com/D28650
--HG--
extra : moz-landing-system : lando