This bug will use the browsing context to notify content tab to mute/unmute media, instead of using MessageManager. We would use the top level canonical browsing context to
set the media mute property for the top level window and propagate it to other top level windows in other processes.
If we don't do so, we're not able to mute/unmute media in the different process when we we enable Fission, because the current way we use can only notify one process and would cause the media on other process can't be muted/unmuted.
Differential Revision: https://phabricator.services.mozilla.com/D32077
--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
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
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
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 should not have any major behaviour changes, with the following exceptions:
1. The method for receiving messages from IPC is called `receiveMessage` rather
than `recvAsyncMessage`. This is more consistent with existing code, so
should be OK.
2. Exceptions will be correctly reported when thrown within a callback.
Differential Revision: https://phabricator.services.mozilla.com/D26547
--HG--
extra : moz-landing-system : lando
We add a [MOZ_CAN_RUN_SCRIPT_BOUNDARY] opt-out for now to keep the tree
compiling. The naming purposefully matches the C++ annotation that has a
similar effect, top make it easy to search for.
Differential Revision: https://phabricator.services.mozilla.com/D23520
--HG--
extra : moz-landing-system : lando
After enable Fission, we're not able to resume media in the different process, because the current way we use can only notify one process and would cause the media on other process can't be resumed.
Therefore, we should use the browsing context to notify the web content which might be on different processes.
Differential Revision: https://phabricator.services.mozilla.com/D18136
--HG--
extra : moz-landing-system : lando
This was introduced in bug 1018324 for the DOM Inspector addon but we no longer
support those kinds of addons.
Differential Revision: https://phabricator.services.mozilla.com/D22872
--HG--
extra : moz-landing-system : lando
