We have a new remote protocol in Firefox that is based on the Chrome
DevTools Protocol (CDP). This is a low-level debugging interface with
which you can inspect the state and control execution of documents
running in web content, instrument Firefox in interesting ways, simulate
user interaction for automation purposes, and debug JavaScript execution.
This patch hooks the server part of this implementation, known as the
remote agent, up to the build system. The remote agent is not enabled
in the default build, so the following is needed in mozconfig to build it:
ac_add_options --enable-cdp
A subsequent change to enable the remote agent in Nightly builds only
will follow in due course. That would allow us to run TaskCluster
test jobs to verify the remote protocol's functional integrity.
Differential Revision: https://phabricator.services.mozilla.com/D22729
Building off the work from Bug 1451159, this creates a new ./testing/extensions directory and adds it to the list of directories to check for moz.build files in ./toolkit/toolkit.mozbuild.
This will enable developers to run custom tests on their extensions locally and on the Try server by following the steps in the ./testing/extensions/README.txt file.
The ./testing/extension/moz.build file is required by the build system, but it will be overwritten with the developer's own moz.build file.
Differential Revision: https://phabricator.services.mozilla.com/D17568
--HG--
extra : moz-landing-system : lando
Building off the work from Bug 1451159, this creates a new ./testing/extensions directory and adds it to the list of directories to check for moz.build files in ./toolkit/toolkit.mozbuild.
This will enable developers to run custom tests on their extensions locally and on the Try server by following the steps in the ./testing/extensions/README.txt file.
Differential Revision: https://phabricator.services.mozilla.com/D17568
--HG--
extra : moz-landing-system : lando
Moves bspatch.h and bspatch.cpp into new folder
Adds LICENSE, moz.yaml, and moz.build for bspatch
Alters bsdiff and updater build files to account for the new location of bspatch
Renames toolkit/mozapps/update/common/errors.h to toolkit/mozapps/update/common/updatererrors.h for
breaking windows builds. It collided with MSVCRT's exported errors.h after being added to the export list for
the 'updatercommon' library
Differential Revision: https://phabricator.services.mozilla.com/D13735
--HG--
rename : toolkit/mozapps/update/common/errors.h => toolkit/mozapps/update/common/updatererrors.h
rename : toolkit/mozapps/update/updater/bspatch.cpp => toolkit/mozapps/update/updater/bspatch/bspatch.cpp
rename : toolkit/mozapps/update/updater/bspatch.h => toolkit/mozapps/update/updater/bspatch/bspatch.h
extra : moz-landing-system : lando
With patches from other bugs in place to use the right C compiler and cflags,
we can enable geckodriver on cross-compiles for macOS.
MozReview-Commit-ID: 5wqBiA6UCf
Overall, this makes the whole setup less fragile, and make it work with
LTO in more situations.
--HG--
extra : rebase_source : de968c61dc4ef337fdc28745c202334ac41763cd
Most of this module is dead code, intended to convert directory listings into
RDF data sources for a XUL front-end which no longer exists.
Rather than keep the remaining code which still has any effect, I opted to
just replace it with a JS stub, which winds up being much simpler.
MozReview-Commit-ID: CiBpV0mrOo0
--HG--
extra : source : 2ea9f1f5269ed5291275a174a633b23dc92667de
extra : histedit_source : fdc195bff4684a84f610b90c0d9820b860c5ff40
When building with a --enable-project that is neither js nor a
toolkit-based one (like browser or mobile/android), we don't want to be
building things that are specific to gecko and/or spidermonkey.
At the same time, this lifts the exception that js standalone doesn't
have an app.mozbuild included, and makes the moz.build parsers that
don't set a MOZ_BUILD_APP get the same information as they were through
toolkit.mozbuild.
We still keep mfbt, build and a few other DIRS set from the top-level,
because at the moment, there aren't really any --enable-project that
would benefit from those not being recursed.
This feature isn't currently used or being planned to be used in the near
future and has some overhead that makes it hard to justify to keep around,
so it's better to remove it and revive it from VCS history if we need it
later.
security/ is already skipped through top-level moz.build. For
convenience, we skip the DIRS that end up adding GYP_DIRS, avoiding
reindenting their entire moz.build.
--HG--
extra : rebase_source : 346aba5f4ec29112cb2ce035844e57f13a214482
It is technically possible to move it even further up with adjustments
to the top-level moz.build, but that would either be too hackish, or
more involved (and possibly risky for other targets), so I'd rather
keep that for a followup.
--HG--
extra : rebase_source : f70a9a69d8ddba3d60bd09300752d0f41a4c7cac
It is technically possible to move it even further up with adjustments
to the top-level moz.build, but that would either be too hackish, or
more involved (and possibly risky for other targets), so I'd rather
keep that for a followup.
--HG--
extra : rebase_source : 11048687e6c56f528fe4f674c8b951630a10aebd
geckodriver compilation was disabled by default in
https://bugzilla.mozilla.org/show_bug.cgi?id=1368084 due to issues
building it locally on Windows.
This re-enables building of geckodriver in automation, but gives
developers an option, --enable-geckodriver, to opt-in to building
it locally.
geckodriver is implied on supported platforms when MOZ_AUTOMATION is
set, but we also provide the option for developers to use. This means
geckodriver will be built in CI by default, but not in developers'
local environments.
MozReview-Commit-ID: ACkO97ekVsi
--HG--
extra : rebase_source : 067e25911f72d80a54e662f24cc71dedde53a4e1
geckodriver fails to cross-compile on the TaskCluster x86_64 VMs to
Linux i686. This patch disables building on that platform, and I have
filed https://bugzilla.mozilla.org/show_bug.cgi?id=1367519 to follow up
on this.
MozReview-Commit-ID: 7GEx2Oog2fS
--HG--
extra : rebase_source : ed722e066a4de1e4bd73c32ba98aed8916c34fd2
One of the Rust crates that is built as part of geckodriver's dependency
chain uses a build script to compile some C code.
Because mozbuild does not yet pass the compiler wrapper down to where
the gcc crate can find it, we need to avoid building on geckodriver when
this is the case.
When compiling the browser for the rooting hazard analysis build (labelled
H on Treeherder), the MOZ_HAZARD environment variable will be set and
available to moz.build descriptions.
MozReview-Commit-ID: GprFKtvXvOE
--HG--
extra : rebase_source : f45aa5d8c86673c8287371efcfa703755c2b2073
geckodriver is the Mozilla implementation of the WebDriver remote
control interface for Gecko, and provides an HTTPD proxy that
translates the WebDriver protocol to Marionette.
Building this as part of the Firefox build will allow us to run
WPT WebDriver tests to verify our implementation of Marionette and
geckodriver. It also makes it less painful to make changes across
projects.
This change will cause the geckodriver program to be built as part
of regular Firefox builds, except on macOS and Android, and when artifact
builds are enabled.
RUST_PROGRAMS in cross-compile environments cause the wrong linker to
be used. When this bug is fixed, we should be able to enable building
of geckodriver on macOS. This work is tracked in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1329737
On Android, we may one to build a binary for the host system to use
(x86_64), instead of an ARM binary for the emulator.
MozReview-Commit-ID: FG5tmPv4iut
--HG--
extra : rebase_source : 091728fd2582458325689fc6e3d8b317428802d8
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
Its content is a no-op since bug 1322707.
The code in the same directory, though, is meant to move to gtests
(bug 1316611).
--HG--
extra : rebase_source : fa269a034fd327856fde8d0673de58eba9b02d8e
Historically, we had support for some GNOME VFS protocols through the
gnomevfs library, and this was under extension. This may not have been
built by default when it was introduced, but GNOME upstream moved those
things into Gtk itself, and we then got support for the new Gio-based
protocol, similar to what we had through the gnomevfs library.
Time passes, and we switched off the gnomevfs library entirely, and
enabled the Gio-based protocol handlers by default. We then removed
everything related to the gnomevfs library.
Fast forward to now, and disabling Gio support in Firefox just doesn't
make sense, and leaving the gio protocol handler as an extension doesn't
make sense either.
As it is a protocol handler, its natural place is under
netwerk/protocol, which is where we're moving it here.
The netwerk/protocol subdirectories being handled automatically, we
don't need to add the moved directory in any DIRS variable.
--HG--
rename : extensions/gio/moz.build => netwerk/protocol/gio/moz.build
rename : extensions/gio/nsGIOProtocolHandler.cpp => netwerk/protocol/gio/nsGIOProtocolHandler.cpp
extra : rebase_source : 071a9cb1769f013717357458df24e2fd9570ccf4
Ehsan Akhgari
Jesse Schwartzentruber
Andreas Tolfsen
Dave Townsend
Coroiu Cristina
Bianca Danforth
Noemi Erli
June Wilde
Mike Hommey
Ted Mielczarek
Kris Maglione
Sylvestre Ledru
Rob Wood
Csoregi Natalia
Narcis Beleuzu
Prathiksha
Andreea Pavel
Tom Ritter
James Willcox
Marco Castelluccio
Jean-Yves Avenard
Sebastian Hengst
Andreas Tolfsen
Ralph Giles
Ehsan Akhgari