This should be rather safe. We can do more refactoring and renaming once LegacyExtension support is fully removed (ie Fx 65 hits release)
Differential Revision: https://phabricator.services.mozilla.com/D15383
--HG--
extra : moz-landing-system : lando
This patch remove the usage of `Services.appShell.createWindowlessBrowser` from the
webextension target actor (that runs in a child process when the extension is in oop-mode).
As a fallback window (needed when an extension doesn't have an extension page yet, e.g. while
the extension is being reloaded, or when the extension doesn't have a background page), the actor
is going to search for the window related to the XUL browser element created to connect into
the extension process.
If the extension runs in the child process (e.g. as it currently happens on all platforms supported
by Firefox Desktop), the TabParent/TabChild's tabId is used to identify the fallback window.
On the contrary, when the extension runs in the parent process (e.g. as it currently happens on
Firefox for Android), the XUL browser's ownerGlobal innerWindowID is used to identify the
fallback window.
Differential Revision: https://phabricator.services.mozilla.com/D8573
--HG--
extra : moz-landing-system : lando
TabClient appears to be a client for any actor that inherits from browsing context target actor.
So let it be a front for that.
MozReview-Commit-ID: KmpClxJ53N7
Depends on D7457
Differential Revision: https://phabricator.services.mozilla.com/D7458
--HG--
extra : moz-landing-system : lando
TabClient appears to be a client for any actor that inherits from browsing context target actor.
So let it be a front for that.
MozReview-Commit-ID: KmpClxJ53N7
Depends on D7457
Differential Revision: https://phabricator.services.mozilla.com/D7458
--HG--
extra : moz-landing-system : lando
Now that xpcshell no longer uses ParentProcessTargetActor, we can remove comments about it using it.
We can also remove a couple of null checks against docShell that were specific to this usecase.
MozReview-Commit-ID: 67sugv4bZC3
Depends on D7416
Differential Revision: https://phabricator.services.mozilla.com/D7726
--HG--
extra : moz-landing-system : lando
Summary:
create LazyActorClass based off ObservedActorFactory and RegisterdFactory classes for use in RootActor and BrowsingContextActor;
Depends on D6468
Reviewers: ochameau
Reviewed By: ochameau
Bug #: 1473513
Differential Revision: https://phabricator.services.mozilla.com/D6470
--HG--
rename : devtools/server/actors/common.js => devtools/shared/protocol/lazy-pool.js
extra : rebase_source : 09a1c8eac3cbb5856a5e3e61a1c0540efe32e5bd
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
