It's useless if the tab is already visible (i.e., has renderLayers=true), per
the previous patches, and that's the only point at which it gets called.
Differential Revision: https://phabricator.services.mozilla.com/D47131
--HG--
extra : moz-landing-system : lando
The ipc::browser-destroyed message must be sent when a top-level remote browser is destroyed.
Currently this is done by BrowserParent::ActoryDestroy and relies on having access to
mBrowserHost. This can break if we start clearing out this pointer. This commit moves
the trigger to fire in BrowserHost::DestroyComplete. Semantically this is different,
but from the users of this observer, I don't see any risk.
Differential Revision: https://phabricator.services.mozilla.com/D37171
--HG--
extra : rebase_source : c863fb8d8a3a540d3dec42472c71342bed8ba541
extra : amend_source : aae3d054d453e63c10fec8707c8cda0497580a87
This lets us get the TabId for the PBrowser created via PBrowserBridge in the embedding process.
Differential Revision: https://phabricator.services.mozilla.com/D33565
--HG--
extra : rebase_source : 32f4b465426e4d19e4a81df0fc67076b0132038b
extra : source : 5e938107e10ed489477d104c70e413e0c4e6091d
extra : histedit_source : 24bda5ef39697eb4ba9e691d4a3afcc5f144737b
Code outside of BrowserParent should just get the LayersId from a getter
and not worry about RenderFrame.
Differential Revision: https://phabricator.services.mozilla.com/D33562
--HG--
extra : rebase_source : 63f9f9680a7cb16a18d9e56999e02a124aa63429
extra : source : e86839ca63260b09184755c98890fa8abf371530
extra : histedit_source : 34333f5f78ecf9b4f3e12c6175a6e81724a41fb2
This patch makes several changes to the kinds of URLs where we can cancel
content JS when navigating between them:
1) When navigating directly to a URL (e.g. by typing something into the
location bar and hitting Enter), we allow canceling content JS if the URLs
differ in any way *except* their ref ("#"). To help with this, we also
attempt to fix up the URL (e.g. by prepending "http://" to it).
2) When navigating through history, we allow canceling content JS if the
`prePath` part of the URLs differ. Most notably, this allows canceling
content JS when one of the URLs is an `about:` page (e.g. when hitting the
Home button).
3) We explicitly disallow cancelling content JS if the currently-running JS
is trusted or if the page being navigated away from is anything but
http(s): or file:.
4) We also disallow cancelling content JS for windows that are still being
created (e.g. when creating a new tab or window via `window.open`). For
more background on this, see the comments about `mCreatingWindow` in
dom/ipc/BrowserParent.h.
5) We ensure that, when attempting to cancel JS, the tab ID of the
currently-running script matches the original tab that requested the
cancellation. This avoids a race condition in which a particular JSContext
has already moved on to executing another tab's JS by the time we hit our
interrupt callback.
Differential Revision: https://phabricator.services.mozilla.com/D31875
--HG--
extra : moz-landing-system : lando
Currently, BrowserChild rendering is enabled and disabled by `RecvRenderLayers`, and this
method is called only by the tab switching code.
This commit does several things.
1. It factors out the code to enable/disable rendering to MakeVisible/MakeHidden so it can
be used outside of `RecvRenderLayers`
2. We track the current value of RenderLayers and use it in conjunction with EffectsInfo to
determine if we need to be rendering at any given moment
3. We only apply RenderLayers to the root OOP browser (not OOP-iframes)
These changes together make it so that BrowserChild will render IFF 'visible' || 'renderLayers',
and will only apply 'renderLayers' to the root browser.
Differential Revision: https://phabricator.services.mozilla.com/D31473
--HG--
extra : rebase_source : 12ad66f514cf1217899af42ca3891fe7b3f897dc
extra : intermediate-source : 3cb9ddccccf320b19f0deae88cd990982b703022
extra : source : e2197dd98aaeeb3d80b65c9892a82d41c4adc80d
This commit adds RemoteBrowser::UpdateEffects for updating a remote browser's
EffectsInfo over IPC.
A following commit will actually use the EffectsInfo for
enabling/disabling rendering for a remote browser, and another
commit will actually use these IPDL methods.
Differential Revision: https://phabricator.services.mozilla.com/D31472
--HG--
extra : rebase_source : 304d843d2c4a35f468aa847ee66005a932bb7eb2
extra : intermediate-source : d31b7d33efc711fb8115663f4cfc5bc98fd58d73
extra : source : 5aea122dea2120efe107c639b17678e0464b1389
This method wasn't correct for what mconley needed and is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D31506
--HG--
extra : moz-landing-system : lando
It's possible for front-end references to nsIRemoteTab to outlive the IPDL actor. When
this happens, we should ignore methods and property accesses.
The one special case is that some code expects to be able to
access the TabId after the browser has been destroyed. For this
we can just cache the ID.
Differential Revision: https://phabricator.services.mozilla.com/D31449
--HG--
extra : source : 9b79caa460a01a7bdf9c27ede487de0ec642ae0b
extra : histedit_source : ec32bc78fac57f523b4c1b2aef08fddfccfbe546%2C8770eefa09a764733a09d8256ef9b3e2f04244df
BrowserParent is cycle collected and supported weak references, so this commit adds support
for these things to BrowserHost.
Differential Revision: https://phabricator.services.mozilla.com/D31448
--HG--
extra : source : e65cb2d4c5a55e3049922df02af643337b7a58b2
This commit finally updates some nsIRemoteTab methods to apply
to the whole tree of BrowserParent's.
Differential Revision: https://phabricator.services.mozilla.com/D31447
--HG--
extra : source : 99f971a02d87941ee49a391de0e0626c170c0821
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 implements nsIRemoteTab in BrowserHost by delegating to nsIRemoteTab. In a
future commit, these methods will be implemented by BrowserHost.
Differential Revision: https://phabricator.services.mozilla.com/D31443
--HG--
extra : source : ee10a825448133635dbd933c3d60fe427400647b
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 commit implements the RemoteBrowser interface for BrowserHost and BrowserBridgeHost.
For BrowserHost, most methods delegate to the root BrowserParent. In the future, we
should move these over to BrowserHost. For BrowserBridgeHost, most methods are taken
from BrowserBridgeParent.
Differential Revision: https://phabricator.services.mozilla.com/D31439
--HG--
extra : source : 697774dd89848fb992355abaae97bba35b8c74ba
RemoteBrowser is a common interface between the chrome/content process cases for nsFrameLoader,
that allows us to abstract IPC details away. BrowserHost is a concrete implementation for
the chrome process, while BrowserBridgeHost implements the content process case.
Differential Revision: https://phabricator.services.mozilla.com/D31438
--HG--
extra : source : eadeacbe44838a0db21d5f535fd14bfd62455a22
It's possible for front-end references to nsIRemoteTab to outlive the IPDL actor. When
this happens, we should ignore methods and property accesses.
The one special case is that some code expects to be able to
access the TabId after the browser has been destroyed. For this
we can just cache the ID.
Differential Revision: https://phabricator.services.mozilla.com/D31449
--HG--
extra : rebase_source : 06791db921203a5dfc6cc386e420bfa0de113941
extra : histedit_source : 4617c237d14e01cdbfff66d391069bcdf2267c51
BrowserParent is cycle collected and supported weak references, so this commit adds support
for these things to BrowserHost.
Differential Revision: https://phabricator.services.mozilla.com/D31448
--HG--
extra : rebase_source : a69b461b202600f6a9421e646fb425adac60bee3
extra : histedit_source : 78f526f4aecf7172a1c9629c991dcade4585b3ce
This commit finally updates some nsIRemoteTab methods to apply
to the whole tree of BrowserParent's.
Differential Revision: https://phabricator.services.mozilla.com/D31447
--HG--
extra : rebase_source : 902ba51c6ac3e808bb607e7ef5a0d52893a7b1b9
extra : histedit_source : 01377150da3f7acc2afe020a42bfc74e0aba3f21
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 implements nsIRemoteTab in BrowserHost by delegating to nsIRemoteTab. In a
future commit, these methods will be implemented by BrowserHost.
Differential Revision: https://phabricator.services.mozilla.com/D31443
--HG--
extra : rebase_source : aa2e71aadfd9bd99cc70b5d31d50a5cf52843027
extra : histedit_source : a2e0240467df745edbbb9836797d3dc97bd1a5ff
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 commit implements the RemoteBrowser interface for BrowserHost and BrowserBridgeHost.
For BrowserHost, most methods delegate to the root BrowserParent. In the future, we
should move these over to BrowserHost. For BrowserBridgeHost, most methods are taken
from BrowserBridgeParent.
Differential Revision: https://phabricator.services.mozilla.com/D31439
--HG--
extra : rebase_source : e049abd08cbf969efee536ce6b73ac061248add3
extra : histedit_source : 3e7d0b623066ae60a2d3e197ea54b80b4c701d5e
RemoteBrowser is a common interface between the chrome/content process cases for nsFrameLoader,
that allows us to abstract IPC details away. BrowserHost is a concrete implementation for
the chrome process, while BrowserBridgeHost implements the content process case.
Differential Revision: https://phabricator.services.mozilla.com/D31438
--HG--
extra : rebase_source : 3518e45799a46f9bef57a36049fd7ae10f03aee6
extra : histedit_source : c8ea0b064234163284b9a161523c6bb2b6cba6c2
Anny Gakhokidze
Daniel Varga
Emilio Cobos Álvarez
Ehsan Akhgari
Ryan Hunt
Kashav Madan
Noemi Erli
Jim Porter
Mike Conley
Gurzau Raul