JS classes, unlike var or const, are not automatically made part
of the global scope in JSMs. This makes it impossible to import
ActorChild this way:
const {ActorChild} = ChromeUtils.import("resource://gre/modules/ActorChild.jsm", {});
By assigning the ActorChild class to this we work around this problem.
Differential Revision: https://phabricator.services.mozilla.com/D17080
--HG--
extra : rebase_source : 88feda088b4e66a1166c7624d834e6a1565ced9b
extra : source : 4b6549b8a6012efa6a3b250b26fff7cf0d1ca564
JS classes, unlike var or const, are not automatically made part
of the global scope in JSMs. This makes it impossible to import
ActorChild this way:
const {ActorChild} = ChromeUtils.import("resource://gre/modules/ActorChild.jsm", {});
By assigning the ActorChild class to this we work around this problem.
Differential Revision: https://phabricator.services.mozilla.com/D17080
--HG--
extra : moz-landing-system : lando
This patch adds a messaging mechanism to actors that work like this:
If browser.fission.simulate is true, messages handled by ActorManagerChild will only be dispatched to an actor tied to a specific frame, specified either by its frameId (outerWindowId) or by its browsingContextId. Messages that lack the information about the destination frame will be considered meant for the top-level frame.
In addition, a sendMessage API is added to ActorChild that automatically adds the id information to the outbound message, making it easier for it to be handled in the parent.
The frameId support is to ease the transition of some code that is already using outerWindowIds. For new code, it is preferred to use the browsing context ids, together with bug 1496840
Differential Revision: https://phabricator.services.mozilla.com/D7933
--HG--
extra : moz-landing-system : lando
This fixes the addEventListener in ActorChild that I got wrong on bug 1490810, as it was still directly adding the events to the message manager, instead of going through the dispatcher (which can simulate the Fission process boundaries). ActorChild.addEventListener is meant for actors to add more events after they are constructed (that were not declared in nsBrowserGlue or ActorManagerParent)
Differential Revision: https://phabricator.services.mozilla.com/D7932
--HG--
extra : moz-landing-system : lando
If the pref browser.fission.simulate is true, the event dispatcher in ActorManagerChild will not dispatch events to actors that aren't associated with the same window as the event's target.
In addition, when that pref is on, the actors associated with sub-frames will have their content property bound to the correct content window, that might differ from the message manager's window (which is always related to the top level).
Then, in order to write Fission-compatible code, that specific actor will need to be declared with allFrames = true, meaning that it wants to be instantiated for every frame, and not just top-level ones
Differential Revision: https://phabricator.services.mozilla.com/D6358
--HG--
extra : moz-landing-system : lando
This adds the basic framework for defining IPC actors which are lazily
instantiated for the appropriate frame loaders based on DOM events, message
manager messages, and observers. Actual actors are defined in follow-up
commits.
MozReview-Commit-ID: Jb6CWWW7v3v
--HG--
extra : rebase_source : 6c465c492ef423616346d70047c4fd4b074af303
Felipe Gomes
Andreas Tolfsen
Dorel Luca
Kris Maglione