At a high level, this change does the following:
- move the pluginchild actor to be a JSWindowActorChild
- move the parent handling from browser-plugins into a JSWindowActorParent
- move the crash handling from ContentCrashHandlers.jsm to the parent actor,
using a `PluginManager` object. It needs to talk to the actors (and vice
versa), so this seemed a better fit than spreading actor implementation
details to other JSMs.
- switch to using plugin IDs to identify plugins cross-process, instead of
combinations of names or other properties of the plugin tag. As part of that,
ensured plugin IDs are unique between "fake" plugins and the other ones.
- drop support for having a notification for more than 1 plugin. We only support
Flash, in practice, so there didn't seem to be much point in the added
complexity of trying to support more than 1 thing.
Some notes:
- the previous implementation mixes runIDs (for NPAPI plugin process "runs")
and GMP pluginIDs when doing crashreporting. AFAICT there is no guarantee
these don't conflict, so I've split them out to avoid issues. There's a
pluginCrashID object I pass around instead that has either a runID or
pluginID. Happy to rename some more for clarity.
- the previous implementation used `pluginInfo` and `plugin` for a bunch of
different types of variables. I've tried to be consistent, where:
* `pluginElement` is a DOM element for a plugin
* `activationInfo` is a JS object used to track click to play state for a plugin
* `plugin` is a plugintag as returned by the pluginhost service
* `pluginCrashID` is an identifier for a crashed plugin (see previous point).
- I'm still using broadcastAsyncMessage to tell the content processes about
gmp plugin crashes and plugin crash submission updates, because there's no
guarantee the actors are instantiated (for gmp plugins) nor can the parent
easily find out which actors to talk to (for either gmp or npapi plugins).
Open to suggestions there, too. I think our best bet might be moving that to
IPDL-based IPC within the GMP code, but that feels like a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D37665
--HG--
rename : browser/base/content/browser-plugins.js => browser/actors/PluginParent.jsm
extra : moz-landing-system : lando
This was kept to support old xul addons. All mozilla-central usages
have been removed and now uses Loader.jsm to get access to this module.
Differential Revision: https://phabricator.services.mozilla.com/D38321
--HG--
extra : moz-landing-system : lando
The rest was legacy code to support old xul add-ons.
All mozilla-central code used to be refactored, but a few places
were still using the old codepaths.
Differential Revision: https://phabricator.services.mozilla.com/D38283
--HG--
extra : moz-landing-system : lando
This is part 1 of the required changes. This just addresses the
storage mechanism and any place that uses experiments in their raw
form. This updates most callers to support studies with multiple
preferences.
We update about-studies to assume only one preference. This seems
counterproductive, but studies with multiple preferences will include
a description field that obviates the need for this.
Differential Revision: https://phabricator.services.mozilla.com/D29293
--HG--
extra : moz-landing-system : lando
The module can dump ELF binaries, Mach-O binaries, and pdb files. So it works
for all our supported platforms.
The module is currently hosted on https://zealous-rosalind-a98ce8.netlify.com/ ,
which is a netlify server that serves files from the following repo:
https://github.com/mstange/profiler-assets
To make all of this look a bit more official, I'm planning on doing two things:
- Move the github repo under the devtools-html organization
- Get a firefox.com subdomain such as profiler-assets.firefox.com for hosting
Depends on D13004
Differential Revision: https://phabricator.services.mozilla.com/D13005
--HG--
extra : moz-landing-system : lando
This adds some missing modules with odd export patterns, along with some full
path overrides for a few modules with duplicate leaf names, which previously
had a single entry with combined export lists of all matching modules.
--HG--
extra : rebase_source : c1cdb20e785c0b6eba712e4f0fbf6ab4dca6d060
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
The restriction preventing fullscreen windows from being dragged is removed.
Differential Revision: https://phabricator.services.mozilla.com/D15075
--HG--
extra : moz-landing-system : lando
With same-compartment chrome globals these would end up in the same compartment.
We need to prevent that because the debugger doesn't support it.
Differential Revision: https://phabricator.services.mozilla.com/D15093
--HG--
extra : moz-landing-system : lando
Creates base classes for providers and muxers. All the classes are exposed
by UrlbarUtils, for 2 reasons:
1. UrlbarProvidersManager on instantiation is importing provider modules, that
may reimport the manager module. Exposing classes from it could cause a
recursive failure.
2. It's nicer if only one of the urlbar modules exports multiple symbols (thus
moving the QueryContext class here too)
Differential Revision: https://phabricator.services.mozilla.com/D14760
--HG--
extra : moz-landing-system : lando
We already have a fallback for items that aren't in a worker scope, we should have the same for ones that are. This means we don't need single maps (foo.js -> foo) in modules.json, and also we can identify more as explicit variables, so that no-unused-vars can detect them.
Differential Revision: https://phabricator.services.mozilla.com/D13299
--HG--
extra : moz-landing-system : lando
We already have a fallback for items that aren't in a worker scope, we should have the same for ones that are. This means we don't need single maps (foo.js -> foo) in modules.json, and also we can identify more as explicit variables, so that no-unused-vars can detect them.
Differential Revision: https://phabricator.services.mozilla.com/D13299
--HG--
extra : moz-landing-system : lando
Move JSON dump loading and CanonicalJSON serialization to a worker to reduce impact on main thread
Differential Revision: https://phabricator.services.mozilla.com/D10064
--HG--
extra : moz-landing-system : lando
Move JSON dump loading and CanonicalJSON serialization to a worker to reduce impact on main thread
Differential Revision: https://phabricator.services.mozilla.com/D10064
--HG--
extra : moz-landing-system : lando
Pages that are whitelisted for displaying on about:about can be
autocompleted in the URL bar.
MozReview-Commit-ID: BYhWUImyiJH
Differential Revision: https://phabricator.services.mozilla.com/D3072
--HG--
extra : moz-landing-system : lando
This factors out the `Prefs` object from UnifiedComplete.js into UrlbarPreferences.jsm and makes required changes so it's not tied to consts and other identifiers local to UnifiedComplete.js. It adds another new module, UrlbarUtils.jsm, for storing consts that both UrlbarPreferences and UnifiedComplete use.
In order to preserve blame as much as possible, I used `hg cp` to copy UnifiedComplete.js to UrlbarPreferences.jsm, and then I removed all the non-Prefs code before making other changes, so this patch looks bigger than it really is. (Maybe I wasn't actually so successful in preserving a lot of blame.)
Differential Revision: https://phabricator.services.mozilla.com/D5626
--HG--
rename : toolkit/components/places/UnifiedComplete.js => browser/components/urlbar/UrlbarPrefs.jsm
extra : moz-landing-system : lando
This creates a basic object with minimal search functionality. It currently uses a dummy ProvidersManager that can be replaced once we get the real one.
There are two test files, the unit one is aiming to test at a unit level - stubbing out the manager, and checking the functionality works correctly.
The second is for checking integration with the providers manager, and it does the right things when linked together. For now, this has just a simple check that uses the dummy ProvidersManager for the case of returning a single result matching the URL.
Depends on D4566
Differential Revision: https://phabricator.services.mozilla.com/D4973
--HG--
extra : moz-landing-system : lando
This is a first stab at the new tokenizer.
It's not expected to be perfect yet, but good enough to be modified and replace the existing code in unifiedComplete with just a few modifications.
It's mostly intended to start setting up a code and tests structure.
Differential Revision: https://phabricator.services.mozilla.com/D2838
--HG--
extra : moz-landing-system : lando
This is a first stab at the new tokenizer.
It's not expected to be perfect yet, but good enough to be modified and replace the existing code in unifiedComplete with just a few modifications.
It's mostly intended to start setting up a code and tests structure.
Differential Revision: https://phabricator.services.mozilla.com/D2838
--HG--
extra : moz-landing-system : lando
The RemotePageManager.jsm contains code both for the parent and child processes, which makes some code to be unecessarily loaded twice. This patch splits it up in various parts:
RemotePageManagerParent.jsm - code meant for the parent process
RemotePageManagerChild.jsm - code meant for child processes
MessagePort.jsm - code used by both the parent and child code paths (the base MessagePort and MessageListener)
MozReview-Commit-ID: 1fUoQ5Y29xM
--HG--
rename : toolkit/modules/RemotePageManager.jsm => toolkit/components/remotepagemanager/MessagePort.jsm
rename : toolkit/modules/RemotePageManager.jsm => toolkit/components/remotepagemanager/RemotePageManagerChild.jsm
rename : toolkit/modules/RemotePageManager.jsm => toolkit/components/remotepagemanager/RemotePageManagerParent.jsm
extra : rebase_source : 828b57b305274abbf55710bc58325a087e5b6cc4