This container formerly defined a special Gradle project for fetching
dependencies. This patch lays the ground-work to use the in-tree
Gradle project instead. Using the in-tree project looks like first
starting a local Nexus repository to collect downloaded dependencies
(before.sh); then running a build which populates that repository; and
then packaging up the downloaded dependencies (after.sh). The patch
after this will define the build which populates the repository.
Sadly there's no easy way to *inherit* from desktop-build, so this is
a copy-paste-modify clone.
MozReview-Commit-ID: Dd5Hj8hkJVk
--HG--
extra : rebase_source : dcfe245b23eb28e99b1506eebe053142c9e242b3
extra : histedit_source : f21014636de958c5ddf27ca2a1eb156e3c88bd78
This is a version produced locally from
1d07987217.
I used |./gradlew install| and then copied the pieces out of ~/.m2/repository.
Local builders should never download using this plugin, since |mach configure|
ensures that all the relevant pieces can already be found. It's just useful in
automation; and as an eventual replacement for chunks of |mach bootstrap|.
MozReview-Commit-ID: 9JiFe0xLr99
--HG--
extra : rebase_source : 5bbe5ada7fce0d3e8a702a09da7ff70fd639dc67
extra : histedit_source : aa7049abefafd652b0db2bd03ab15310967e0ad0
The alternative is to define an interface and two conditional
implementations, and then build only one depending on MOZ_ANDROID_GCM.
That's what we did for Adjust, and it works; but it's awkward here
because the the PushService code is truly part of the browser, and the
conditional code is compiled very early (much earlier than the
browser). (The Adjust library was built even earlier than the
existing conditional code, so this wasn't an issue.) To work around
this, we'd want to add conditional code to the main browser, which
complicates the build. This is expedient until we get to a proper
dependency injection scheme (for example, Dagger).
MozReview-Commit-ID: 18usWz8oC3B
The return values from the different element search functions in searchFn
have inconsistent return types, and a null check is usually not what
we want. In order to have findElement consistently return a no such
element error, we need to do a loose false test.
This bug has affected the findElement command when using the tag
name, name, class name, link text, and partial link text selectors.
Other selectors were unaffected.
MozReview-Commit-ID: C26R3YrqKyf
--HG--
extra : rebase_source : dc723ae147b9208b4274ffc4a5338f0107ddd0ed
The Benchmark class is now taking a MediaDataDemuxer argument. Options allow to decode any videos and measure the decoding speed.
MozReview-Commit-ID: C017I1cGqPL
Rather than passing around a bool flag to indicate if we should be creating
an AnimationCollection when none is found, it would be a lot easier to read
if we simply introduce a separate method for this.
MozReview-Commit-ID: 6bg8jGoH5pL
By moving GetAnimationCollection to AnimationCollection itself, we can remove
a bunch of virtual methods on the animation managers, simplify call sites,
and provide better type safety by ensuring a correspondence between element
property names and concrete animation types.
One change in behavior, however, is that in doing this we can no longer
add any newly-created AnimationCollection to the corresponding manager's linked
list of collections inside GetAnimationCollection. Instead we take a bool
outparam to indicate if a new collection was created and leave managing the
linked list to the manager. This is just a temporary measure, however, since
by the end of this patch series will will eliminate this linked list altogether
along with this flag.
MozReview-Commit-ID: 1jsc4QcmVDg
Nick Alexander
Tim Nguyen
Xidorn Quan
Matthew Noorenberghe
Krishna
cijo
Margaret Leibovic
Eddy Bruel
Jalpreet Singh Nanda
Mike de Boer
Carsten "Tomcat" Book
Jordan Santell
Jean-Yves Avenard
ffxbld
Wes Kocher
Andreas Tolfsen
Rail Aliiev
Jim Blandy
Anthony Jones
Nicholas Nethercote
Matt Woodrow
Heiher
Ryo Motozawa
Terrence Cole
Brian Birtles