This prevents the geckodriver crate from being published to a
package registry like crates.io by mistake.
MozReview-Commit-ID: 7Qc9vaPhdJh
--HG--
extra : rebase_source : ec1f470a69c14c240b2cb522eb4475b22ed4a9da
A release of the webdriver crate is necessary for the release build
to pass on Travis, since testing/geckodriver/Cargo.toml cannot
depend on testing/webdriver as it is exported to the GitHub repository.
MozReview-Commit-ID: 1S2aAtg50t4
--HG--
extra : rebase_source : 53ef155537a44ef2bc141ea30a635e4144625118
This is required for "./mach vendor rust" to pick up on
testing/webdriver's dependency tree. This change should have been
made when the webdriver crate was vendored in the tree in the first place.
MozReview-Commit-ID: 5sqRojm0bGD
--HG--
extra : rebase_source : 16f87eae13151ed6a2d17db924c6e6145a8f8985
This was mainly used to support Universal MacOS builds, which were
removed several months ago.
In theory, someone could be using this feature to build multiple
applications with one build system invocation. But given that client.mk
is no longer the preferred interface to the build system and multiple
applications can be built by running `mach build` with different
mozconfigs, I don't think support for this feature is worth keeping.
This commit removes support for MOZ_BUILD_PROJECTS and related
functionality from client.mk. Support for recognizing
MOZ_CURRENT_PROJECT in configure and mozconfig evaluation has also
been removed. This includes support for the ac_add_app_options
mozconfig function.
Good riddance.
MozReview-Commit-ID: 7xI2jYxDFFr
--HG--
extra : rebase_source : 91068f3b8ae32fbcda4defb5d4bb086a04387598
These variables are unused in the repo. The %_ALL variation is used for
sccache, however.
The last use of these variables was removed when support for MacOS
universal builds was removed.
Someone somewhere may be relying on this functionality. But I don't
think it is worth continuing to support in client.mk. If someone
really needs it, we can reintroduce support for the feature elsewhere,
like in mach or via mozconfig support somehow.
MozReview-Commit-ID: 4KznCmK3JTN
--HG--
extra : rebase_source : 656008f9b4264768a2127fcffdb2ab28ff92991f
There are no references to this variable outside client.mk. AFAICT
it is unused.
The only reasonable justification for retaining this support IMO was
Universal MacOS builds. And those are no longer supported.
MozReview-Commit-ID: 9MnC18Bd1ge
--HG--
extra : rebase_source : 16c96dfceffb89434489b79f3f4ca2c48506840f
This variable has been unused since 683e59dc3094 (bug 1286934).
MozReview-Commit-ID: FZ7D9mSIeME
--HG--
extra : rebase_source : a82409230393bbdd10a4f185d83670f1e0dbdc5e
This should avoid Bug 1249421, but it will also address an
Android-Gradle plugin 3.0 issue, where the plugin requires the
manifest at Gradle configuration time. Currently we don't provide it
until Gradle evaluation time, leading to this error, and to the plugin
failing.
MozReview-Commit-ID: 4NkiQSooLly
--HG--
extra : rebase_source : 21b11e8cb4ff990df3adf18718ec3bda869486a0
Spoon and some Gradle work allowed to run certain JUnit 3 test suites
locally. At the time, running the various test suites was diffficult.
Fast forward, and it's easier to run these suites, and in general they
are only run in Android Studio. This will only get better as we move
the background services tests into a separate module (Bug 1229149).
MozReview-Commit-ID: KZTWmkhwi96
--HG--
extra : rebase_source : 5244e81ffe81e8611034fea1edb07681266a7581
This work-around isn't needed for the moz.build system because there's
no equivalent of the
|mach build| > |mach gradle| > |make gradle-targets|
dependency chain that "re-enters" Make processing. That is, the
nodeps mechanism ensures that nothing in m/a/b/Makefile.in (that knows
about AB_CD) ever sees AB_CD=multi.
MozReview-Commit-ID: qZKAtlLhJw
--HG--
extra : rebase_source : b9dd2f4f4dd8af5c4d594927226c7b8230723b9f
extra : source : c965d3adbcbf35f417dbf0832b44de6c52b89535
It looks like I didn't handle this flow -- which only matters during
l10n multi-locale builds and l10n single-locale repacks -- during the
initial Gradle landing. Now we need to handle it.
Remember that the l10n process runs |mach build && mach package|, and
then modifies the object directory by inserting new localized resource
files. It then runs |mach package| again and expects to regenerate
the ap_ file, ready to splice it into the existing apk file. The
existing code just copied the .ap_ built by Gradle without
regenerating the ap_ file. This commit forces running Gradle again,
which will pick up the new resources in the object directory.
The chain of dependencies is:
|mach package| > gecko-nodeps.ap_ > .aapt.nodeps > .gradle.deps
and the latter two targets are FORCE, so they always get run
(regardless of the freshness of the inputs).
In fact, this runs the entire Gradle process again, including
producing classes.dex. (The moz.build process doesn't compile the
Java source code again.) This patch changes the existing behaviour to
copy the regenerated classes.dex into the repacked apk and avoid the
need for the R.java IDs to line up across the |mach build| and |mach
package| invocations. This turned out to be necessary to support
multi-locale builds with newer Gradle versions, which don't appear to
preserve aapt R.java IDs across the
|mach build|, |mach package|, |mach compare-locales|, |mach package|
chain.
MozReview-Commit-ID: FlhtQPwR5xG
--HG--
extra : rebase_source : ee00d5507a63b47b253cb0e310d2fa9a815442a1
extra : source : 3a6e8fedc00a5c2930e0f2bc3077cd9beed5c5d2
When built as part of a consuming application, a library's bundle*
target is called but not its assemble* target. (When built by itself
for distribution, a library's assemble* target is called.) This
corrects the wrapper dependencies.
MozReview-Commit-ID: 9ooHMNPK2U4
--HG--
extra : rebase_source : 0b9d979a0066eda86ec39e9700a2e11e8073cea6
A FLAC packet may have a size as small as 11 bytes. We should parse as much data as we can and not make assumptions on when to stop early.
MozReview-Commit-ID: 9skvwbt15MY
--HG--
extra : rebase_source : e428ba40fb71a4607af5d3be7f7d61ae98631522
It is unknown if an av_parser is usable after having been drained. So to be certain, we simply tear it down and re-create it.
MozReview-Commit-ID: 6NFMHbRMwxs
--HG--
extra : rebase_source : c31db990ef04ec2586d965b9a08be47532bd87a2
Per FFmpeg documentation: to signal EOF to the av_parser, input length should be 0 (so that the last frame can be output).
MozReview-Commit-ID: F22RcRnT3HS
--HG--
extra : rebase_source : f704e33526347244d38d1ab0b7fa1e5a0cda84cb
This changes the Telemetry enabling logic so that extended telemetry
gets enabled when MOZILLA_OFFICIAL is not defined and the update
channel is "default", which is the case for local developer builds.
MozReview-Commit-ID: 19vlItyHsKp
--HG--
extra : rebase_source : 730568329e579e63fb58fa2516a126893c73e636
Allow assert_same_element to compare web element references (JSON
Objects) with webdriver.Element and vice versa.
Tests will typically look up some element using traditional means
and use that as the trusted comparison when retrieving the same
element using the session.transport.send primitive that returns
the plain JSON Object.
MozReview-Commit-ID: 2DScnviOevb
--HG--
extra : rebase_source : d84fc331cdf2b2eb2bd36b71a184e5239b60bdff
The WPT WebDriver client currently only unmarshals responses for some
commands (notably execute_script, execute_async_script, and find.css).
For the client API we want to unmarshal all response bodies automatically.
This patch moves all JSON serialisation/deserialisation to a new
webdriver.protocol package so that it is not scattered around
the client API. It introduces specialisations of JSONEncoder and
JSONDecoder that allows web element references to be recognised
and converted to complex webdriver.Element objects.
This change means it is no longer necessary for callers to invoke
webdriver.Session._element to convert the response to a web element
as this will be done automatically on any request- and response
body to webdriver.Sesson.send_command.
An important thing to note is that HTTPWireProtocol.send does not follow
this behaviour by default. That is because session.transport.send
is used throughout WebDriver tests in WPT as a way to get the raw
JSON body without having to set up session state manually.
MozReview-Commit-ID: 5UyDAe43Hgf
--HG--
extra : rebase_source : b86495dd0dcd102e6dea87011caafad475b88723
It is more natural for the web element UUID to come first, followed
by the associated session state.
The patch also adds ctor documentation.
MozReview-Commit-ID: 5iV4SZzMeKS
--HG--
extra : rebase_source : e9f68a2a934b2c13a9d1d913204e7e3d9bce6b42
When comparing two instances of webdriver.Element we want to first
check the type, to make sure the "id" attribute is present, then
compare the web element reference UUIDs. These are supposed to be
unique across all browsing contexts.
MozReview-Commit-ID: 68PUBQxPdQ5
--HG--
extra : rebase_source : f0c52efd0db3a13ea1b90dc6c058ebee2de76e1d
When comparing two instances of webdriver.Session we want to first
check that there is a current session, then the type of the object
to compare with to make sure the "session_id" attribute is present,
then finally we compare the session IDs.
MozReview-Commit-ID: 6Ch4Uy2MEhB
--HG--
extra : rebase_source : 252fe31680c57831b122d2bb53fe133b32c322eb
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: 77D61xpSmIl
--HG--
extra : rebase_source : c6162fa3cf539a07177a19838324bf368faa162b
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r "// \* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
####
old="// \* This Source Code Form is subject to the terms of the Mozilla Public"
new=" \* This Source Code Form is subject to the terms of the Mozilla Public"
sed -i s%"^$old"%"$new"% $1
####
MozReview-Commit-ID: Ihx0EAOkT2g
--HG--
extra : rebase_source : 4dc97f234495e3ec1f4904e91d43d00fd3810626
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r " \* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
line1=" \* This Source Code Form is subject to the terms of the Mozilla Public"
line2=" \* License, v\. 2\.0\. If a copy of the MPL was not distributed with this"
line3=" \* file, You can obtain one at http://mozilla\.org/MPL/2\.0/\. \*/"
# Strip off 1 space at beginning:
sed -i s%"^ $line1"%"$line1"% $1
sed -i s%"^ $line2"%"$line2"% $1
sed -i s%"^ $line3"%"$line3"% $1
###
MozReview-Commit-ID: EwCjyajgY4W
--HG--
extra : rebase_source : c61ca17ba556290d1f27af0a0c84e2ccc5371a36
This patch was automatically generated. I found the files to be fixed in this
patch with the following command:
grep -r "^\* This Source Code" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
line1="\* This Source Code Form is subject to the terms of the Mozilla Public"
line2="\* License, v\. 2\.0\. If a copy of the MPL was not distributed with this"
line3="\* file, You can obtain one at http://mozilla\.org/MPL/2\.0/\. \*/"
# Insert 1 space at beginning:
sed -i s%"^$line1"%" $line1"% $1
sed -i s%"^$line2"%" $line2"% $1
sed -i s%"^$line3"%" $line3"% $1
###
MozReview-Commit-ID: HXBMrfnhlVr
--HG--
extra : rebase_source : de4c78563711f8366e2978c5199a5041875fbe38
This patch was mostly[1] automatically generated. I found the files to be fixed
in this patch with the following command:
grep -r "C++; indent-tabs-mode:" gfx
...and then I modified each of these files with the following script
(where $1 is the filename to be modified):
###
old="/\* -\*- Mode: C++; indent-tabs-mode: nil; c-basic-offset: 4 -\*- \*/"
new="/\* -\*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -\*- \*/"
sed -i s%"^$old"%"$new"% $1
###
[1] NOTE: Nearly all of these files use 2-space indentation, so it's correct
(from a consistency perspective and a reflecting-reality perspective) that
we're reducing their "c-basic-offset: 4" down to "c-basic-offset: 2" here. The
one exception is nsDeviceContext.h, which *does* actually use 4-space
indentation right now -- so I'm leaving that file with "c-basic-offset: 4" in
its mode line. This manual change (reverting 1 character from the automated
process) is the only piece of this patch that isn't automated.
MozReview-Commit-ID: L4MbyeYSbfY
--HG--
extra : rebase_source : 8ddbe422471bfd8b0060e96fb1c8cd062f10f290
This patch doesn't modify the mode lines at all -- it just swaps their order,
and makes each one its own C++ comment, separate from the MPL boilerplate
comment.
MozReview-Commit-ID: BEZJVj2sMuK
--HG--
extra : rebase_source : 9e0946c8a8d0b67c11b5932b9d1e51e0e6e8ebef
