This asserts that the embedder is always set soon enough that we don't run into
the situation which caused the null deref fixed by bug 1565489.
Differential Revision: https://phabricator.services.mozilla.com/D39187
--HG--
extra : moz-landing-system : lando
This should help ensure that the embedder is always set soon enough that we
don't run into the situation which caused the null deref fixed by bug 1565489.
This patch also adds an assertion earlier in WindowGlobalParent's lifecycle to
ensure that the condition is satisfied. This assertion will fail before the
changes in part 1.
Differential Revision: https://phabricator.services.mozilla.com/D38723
--HG--
extra : moz-landing-system : lando
The crash appears to be being caused by the GetEmbedderWindowGlobal call
returning a null value. This patch simply avoids the crash in this case, and
returns a reasonable default value of false, as it should never be true for a
BrowsingContext with a parent without Fission enabled.
This patch should be small enough to safely uplift if necessary.
Differential Revision: https://phabricator.services.mozilla.com/D38722
--HG--
extra : moz-landing-system : lando
This also adds an extra assertion against browsing context mismatches that
happen when we don't get this right.
Differential Revision: https://phabricator.services.mozilla.com/D36852
--HG--
extra : source : 4b07deb4cd2ef4c98b6d6ee961a20705f4f2deae
This change comes in two parts. First, the code in WindowGlobalChild was changed
to detect the in-process case, and instruct the nsFrameLoader to become a
non-remote nsFrameLoader, and second the logic in WindowGlobalParent was updated
to ensure that the OwnerProcessID is updated after the change.
Differential Revision: https://phabricator.services.mozilla.com/D35060
--HG--
extra : moz-landing-system : lando
This adds an API for fetching security info per frame, no matter if we have
a certificate error or a valid certificate.
I tried to make this work in a Fission-compatible way, let me know if this
is the right approach.
Differential Revision: https://phabricator.services.mozilla.com/D34354
--HG--
extra : moz-landing-system : lando
This should hopefully allow the parent process to tell whether a given document
is the initial about:blank document.
Differential Revision: https://phabricator.services.mozilla.com/D33542
--HG--
extra : moz-landing-system : lando
This allows for the getter to be used in IProtocol's destructor, and generally
brings IProtocol more in line with IToplevelProtocol.
Differential Revision: https://phabricator.services.mozilla.com/D32042
--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 code currently works for remote subframes assuming that nsIRemoteTab is implemented
by BrowserParent, but will break when nsIRemoteTab is only for a top-level BrowserParent.
What this code really wants is a content process ID to retarget the channel to. This
commit switches the interfaces to pass this around instead of nsIRemoteTab.
Differential Revision: https://phabricator.services.mozilla.com/D31435
--HG--
extra : source : 757b4f595cc4b18ae35483d23edff4896d15d4b1
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 code currently works for remote subframes assuming that nsIRemoteTab is implemented
by BrowserParent, but will break when nsIRemoteTab is only for a top-level BrowserParent.
What this code really wants is a content process ID to retarget the channel to. This
commit switches the interfaces to pass this around instead of nsIRemoteTab.
Differential Revision: https://phabricator.services.mozilla.com/D31435
--HG--
extra : rebase_source : be3303c2d38d704a6a1817fa45fd76700fae6287
extra : histedit_source : c7bf1e496f4328acc9ee70fcccdff98ea2cce5df
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
nsITabParent is exposed to frontend code and is generally used as a representation of a remote tab. We could just rename the interface to nsIBrowserParent and worry about it later, but I think it's better to rename the interface to nsIRemoteTab so that we can later work on splitting the interface away from the PBrowser protocol.
Note: Some frontend code refers to a TabParentId. This commit renames this to RemoteTabId. We need to figure out the purpose of TabId with fission.
Differential Revision: https://phabricator.services.mozilla.com/D28132
--HG--
rename : dom/interfaces/base/nsITabParent.idl => dom/interfaces/base/nsIRemoteTab.idl
extra : rebase_source : 9d8a1790a7bb10195ad063644d1a93d63b2afb72
File renames cause some unified build issues. This commit adds the missing headers.
Differential Revision: https://phabricator.services.mozilla.com/D28130
--HG--
extra : rebase_source : 1bc74b73e90caddfa80503b1cb0283142e32c462
This adds a single new method, which acts like sendAsyncMessage, but
also returns a promise. This promise is fulfilled when the promise
returned from the receiveMessage callback is resolved.
```
partial interface JSWindowActor {
[Throws]
Promise<any> sendQuery(DOMString messageName,
optional any obj,
optional any transfers);
}
```
Differential Revision: https://phabricator.services.mozilla.com/D27809
--HG--
extra : moz-landing-system : lando
When a remote type mismatch is found for a subframe, this patch checks if
fission is enabled for that window. If it is, it triggers a process switch,
continuing the load in a new process.
With this patch, subframes will only change process when navigating to a HTML
subframe, and not when navigating to a non-HTML subframe. That will be fixed in
a follow-up. This patch also does not change the remote type selection logic,
so only very limited types of remote iframes are supported.
Differential Revision: https://phabricator.services.mozilla.com/D27513
--HG--
extra : moz-landing-system : lando
This avoids a racy situation early during WGP creation where a null documentURI
can be read incorrectly.
Differential Revision: https://phabricator.services.mozilla.com/D26555
--HG--
extra : moz-landing-system : lando
WindowGlobalChild.cpp was relying on several headers already included by other
files in its unified build translation unit, but the addition of the
RemoteWebProgressRequest in the next change bumps them into another translation
unit and breaks the build.
The missing `#include` and `using namespace` statements have been added,
allowing builds to succeed.
Differential Revision: https://phabricator.services.mozilla.com/D24937
--HG--
extra : moz-landing-system : lando
Due to adding a new CPP file in the next change, the unified build fails due to
files being shuffled around between translation units. This change fixes the
build.
Differential Revision: https://phabricator.services.mozilla.com/D24810
--HG--
extra : moz-landing-system : lando
