The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
When `TabParent::ReconstructWebProgressRequest` was introduced in
31b206e2046f63af31424489e3d61d7761805878, it mistakenly was unconditionally
constructing an `nsIRequest` from the received `RequestData`, even when the URI
was null.
Additionally `ReconstructWebProgressRequest` has been updated to use the Gecko
style for out parameters (accepting an `nsIFoo**` and passing
`getter_AddRefs(...)` instead of `nsCOMPtr<nsIFoo>&`).
Differential Revision: https://phabricator.services.mozilla.com/D34445
--HG--
extra : moz-landing-system : lando
The `WebProgress#sendLoadCallResult` method only existed to send a empty async
message and was only called from the `WebNavigationChild`. Since
`WebNavigationChild` is in the process of being removed, it makes sense to
inline the replaced method into its call site.
Differential Revision: https://phabricator.services.mozilla.com/D34566
--HG--
extra : moz-landing-system : lando
When `TabParent::ReconstructWebProgressRequest` was introduced in
31b206e2046f63af31424489e3d61d7761805878, it mistakenly was unconditionally
constructing an `nsIRequest` from the received `RequestData`, even when the URI
was null.
Additionally `ReconstructWebProgressRequest` has been updated to use the Gecko
style for out parameters (accepting an `nsIFoo**` and passing
`getter_AddRefs(...)` instead of `nsCOMPtr<nsIFoo>&`).
Differential Revision: https://phabricator.services.mozilla.com/D34445
--HG--
extra : moz-landing-system : lando
The nsFrameLoader for the BrowserParent is always the toplevel
<xul:browser>'s, but we actaully want to skip the detach for the
browsing context for the current browser child.
Differential Revision: https://phabricator.services.mozilla.com/D34237
--HG--
extra : moz-landing-system : lando
This is done by sending a message over PBrowser and PBrowserBridge when the
event would fire to fire it in the correct process.
Differential Revision: https://phabricator.services.mozilla.com/D33083
--HG--
extra : moz-landing-system : lando
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
RenderFrame is a very poor name for what this class does. RemoteLayerTreeOwner
isn't perfect (it's not the only thing that owns layer trees), but it's
hopefully clearer.
Differential Revision: https://phabricator.services.mozilla.com/D33564
--HG--
rename : layout/ipc/RenderFrame.cpp => layout/ipc/RemoteLayerTreeOwner.cpp
rename : layout/ipc/RenderFrame.h => layout/ipc/RemoteLayerTreeOwner.h
extra : rebase_source : 890e54b93f5979a2430c35028110aa7f2091c550
extra : source : f50dd4cde03beb99ed27397e06f81748ae87b727
extra : histedit_source : 2d7eed25156829b2502f1712880df962a781adcf
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
DocAccessibleParent already has IsTopLevel(), which identifies a document at the top level of the hierarchy; i.e. it has no parents.
Now that we have out-of-process iframes, we need to be able to identify and retrieve documents at the top level of their content process, even if they are embedded by another remote document.
DocAccessibleParent::IsTopLevelInContentProcess() has been introduced to achieve this.
BrowserParent::GetTopLevelDocAccessible() now uses this instead of IsTopLevel(), since we want to be able to get the top DocAccessibleParent even for a BrowserParent for an out-of-process iframe.
Differential Revision: https://phabricator.services.mozilla.com/D32282
--HG--
extra : moz-landing-system : lando
This is done by sending a message over PBrowser and PBrowserBridge when the
event would fire to fire it in the correct process.
Differential Revision: https://phabricator.services.mozilla.com/D33083
--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
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