This helps ensure that when running `--fix` across the entire tree, all places that can be are fixed correctly.
Differential Revision: https://phabricator.services.mozilla.com/D37272
--HG--
extra : moz-landing-system : lando
This picks up various improvements, especially to how configurations are handled and some new rules.
Differential Revision: https://phabricator.services.mozilla.com/D37271
--HG--
extra : moz-landing-system : lando
All .xul files have been loading as HTMLDocuments for a few weeks now, so
it should be safe to remove the XULDocument implementation.
Differential Revision: https://phabricator.services.mozilla.com/D41238
--HG--
extra : moz-landing-system : lando
browsertime depends on a few architecture and OS specific packages:
- sharp (libvips)
- geckodriver
- chromedriver
Our toolchain task packages up `tools/browsertime/node_modules` and
we'd like to use the resulting toolchain archive across all of our
test platforms. Since in automation we don't require sharp (which is
only used for screenshotting), and we provide `geckodriver` and
`chromedriver` at the task level, the simplest way is to make these
`optionalDependencies` at the NPM level and not install them in our
toolchain task.
Differential Revision: https://phabricator.services.mozilla.com/D38772
--HG--
extra : moz-landing-system : lando
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 case is expected in the mozlint world (e.g, when running all linters).
This will still print a warning, just a far less scary one and will still
return 0. There is a case to be made that we should silently ignore this as no
other linters print this warning, but it's useful enough to warrant keeping.
Differential Revision: https://phabricator.services.mozilla.com/D37414
--HG--
extra : moz-landing-system : lando
This moves the html plugin enabling from the ./mach command line to the configuration, which means editors can pick this up automatically.
Differential Revision: https://phabricator.services.mozilla.com/D35414
--HG--
extra : moz-landing-system : lando