This will allow mozharness tooling, which does not run through `mach`,
to fish these paths.
Differential Revision: https://phabricator.services.mozilla.com/D38775
--HG--
extra : moz-landing-system : lando
The Rust port of mozbase passes all the lints, but there are ~20
warnings. The warnings will not make the rustfmt job on Treeherder fail.
Differential Revision: https://phabricator.services.mozilla.com/D39367
--HG--
extra : moz-landing-system : lando
Includes geckodriver and the webdriver crate in the rustfmt job
on Treeherder.
Enabling this does not cause any errors, but we are seeing 93 warnings.
These are not fatal and do not cause the job to fail in continuous
integration.
Differential Revision: https://phabricator.services.mozilla.com/D39368
--HG--
extra : moz-landing-system : lando
In browsertime.zip we should have:
browsertime/
package.json
package-lock.json
node_modules/
.bin/
browsertime -> ../browsertime/bin/browsertime.js
browsertime/
...
The idea is that we'll fetch browsertime.zip in a generic-worker
environment and be able to run Node.js from within the top level
browsertime/ directory.
Differential Revision: https://phabricator.services.mozilla.com/D38773
--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
Changes:
- remove `media` from python2 and python3 linter blacklist due to no errors
Differential Revision: https://phabricator.services.mozilla.com/D38126
--HG--
extra : moz-landing-system : lando
Changes:
- change how the modules are imported with the `absolute_import` changes
- satisfy python2 linter
Differential Revision: https://phabricator.services.mozilla.com/D37525
--HG--
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
Update the browsertime snapshot to 4989d0c22bba3a165078b8d784e8d303a727a119 which uses lodash 4.7.14 and lodash.merge 4.6.2.
Differential Revision: https://phabricator.services.mozilla.com/D37806
--HG--
extra : moz-landing-system : lando
Rather than relying on the mar-channel-id set in the `mar` binary, set the channel
explicitly from taskcluster. This allows us to re-use the `mar` binary between
builds/channels.
Differential Revision: https://phabricator.services.mozilla.com/D37481
--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
