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
This patch changes the logic such that we use the new direct
BrowsingContext ParamTraits implementation when possible, and avoids
doing manual lookups.
Depends on D19178
Differential Revision: https://phabricator.services.mozilla.com/D19179
--HG--
extra : moz-landing-system : lando
This will be useful as both an ID for PWindowGlobal, as well as a mechanism for
taking advantage of already synchronized information. As an example, LoadInfo
objects contain the inner window IDs of the window requesting the load, which
can now be used to obtain a reference to the corresponding WindowGlobalParent
in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9396
This serves 2 purposes:
1. Provides an object corresponding to an inner window which Chrome JS can hold onto.
2. Provides the object to JS which Chrome JS per-window actors will be attached to.
3. Provides useful information to Chrome JS in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9394
This allows getting the set of all window globals for a given browsing context.
This is less useful at the moment as the active window global is not exposed as
such. That will be added as a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D9393
This actor can be used for communicating with individual frames, without
depending on walking the tree in the content process.
This is not yet complete. No tests have been written for it, the
WindowGlobalParent objects need to be exposed to chrome JS, and a form of JS
actors should be installed under them.
In addition, BrowsingContextChrome objects should be updated to allow access to
the current WindowGlobalParent in that context.
Differential Revision: https://phabricator.services.mozilla.com/D4623
