We still need to explicitly set the progress when loading stops, so the progress
bar animates to completion before updateProgressState hides it, but in all other
cases calling just updateProgressState is enough to set the new progress value.
MozReview-Commit-ID: 9mQr5s83i9F
--HG--
extra : rebase_source : 7ce8751a97ea4220df7f3502c268507cd53a00dc
All they do is clutter up the log with "HighlightsRanking: Skipping invalid
highlight item." entries, so we should just skip them in the query already.
MozReview-Commit-ID: 1ra7LcYxp4m
--HG--
extra : rebase_source : 5f150e9ed5fd293f27f110cd2973525d5b82e86d
When checking settings categories, if category not found, scroll down; if still
not found, scroll up. This allows for the (apparently rare) case where settings
are initially rendered scrolled down, obscuring the top choice(s).
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
This marks **/docs/** as exclusively docs, and code that is autodoc'd as
inclusively docs.
That means that a change that purely modifies documentation files will *only*
run `docs` tasks, while a change that modifies autodoc'd source code will
*additionaly* run `docs` tasks. The tasks do not run by default.
MozReview-Commit-ID: G9tOK0AwtrI
--HG--
extra : rebase_source : 8dd971e5c9b0eb5f47895664a4ea49442f303ecb
extra : source : 0881de9b2b5e36ec37cc866f1d4af109da57a919
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : 04a8e4b89153a2a11e8a793e893a2e626cbc877a
This also verifies that we have Google Play Services (via
MOZ_NATIVE_DEVICES=1) if we ask to build with GCM. This was just an
oversight earlier.
MozReview-Commit-ID: BvJi7Sfo4pu
--HG--
extra : rebase_source : 009c13d53663553ded4d3645c926f12ecee9da0b
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 4184f40d82bcd44c2bb380d1a8ab534967818af5
Historically, we used MOZ_NATIVE_DEVICES to proxy for Google Play
Services. (MOZ_NATIVE_DEVICES was the first GPS-consuming feature in
Fennec.) With Python moz.configure, we can easily add the real
top-level flag that distributions like F-Droid actually want, which is
to build without (non-free) Google Play Services entirely.
MozReview-Commit-ID: 7YJKw3G1lQA
--HG--
extra : rebase_source : 1a6f7414c0b8108862701dca896befd815d2ac16
This also verifies that we have Google Play Services (via
MOZ_NATIVE_DEVICES=1) if we ask to build with GCM. This was just an
oversight earlier.
MozReview-Commit-ID: BvJi7Sfo4pu
--HG--
extra : rebase_source : 63e4eaab1cf81b765503750c9b356fcc4a2470dd
Right now, the MMA glue is built into constants.jar. constants.jar is
the home of preprocessed Java code; it's built very early in the build
process and intended to be a tiny kernel of shared definitions. The
fact that the MMA glue has to live there is just a sad consequence of
the non-Gradle build system, which makes dependency injection
difficult. Unfortunately, another consequence is that it's not
possible to move reference org.mozilla.gecko.{gcm,push} in the MMA
glue, because those packages are built after constants.jar.
Instead, this patch lifts some of the logic into AppConstants, which
is part of constants.jar. We had grown a twisty maze of indirection
around the GCM sender IDs and it just wasn't necessary; this just
lifts the static pieces up a level and removes a bunch of interface
indirection.
What surprises me is that asking Google's InstanceId.getToken for a
GCM token with a "comma,separated,list" of GCM sender IDs works -- and
indeed, has worked since we added the second MMA sender ID. I didn't
expect that and can't explain it, but this doesn't change that logic
and local testing (both of the existing APKs, and APKs with this
modification) looks good.
MozReview-Commit-ID: 3hObfAwNlPH
***
a0c07e53 o draft Bug 1419581 - Part 1: Move MMA setGcmSenderID from MmaDelegate to MmaLeanplumImp. r=nechen
MozReview-Commit-ID: A4hrk6pVqGW
--HG--
extra : rebase_source : 0547c79ecf404688972fc55658f09bdfce07b613
Those are all remnants of APIs that are now gone for good.
MozReview-Commit-ID: 266GvgbES3s
--HG--
extra : rebase_source : d160f559bfcb805ecf02f53784777534ede943f4
This thorn in my side turns out to be unnecessary! For reasons
unknown, brand.dtd is not localized for mobile/android/ in the way it
is for browser/. That means we can just pull from the branding
directory, which avoids a frustrating issue where single-locale
repacks couldn't actually produce strings.xml since the subtle
dependency on the branding directory being built first wasn't
satisfied.
MozReview-Commit-ID: CBBaxfj5lMW
--HG--
extra : rebase_source : f020c82a78bb2d14760ba6cfb5d586795471bd8d
This got mixed up by Bug 1411654, which migrated to Android-Gradle
3.0+. However, it's also much easier to fix due to the changes in the
new version! This patch uses the new audience flavor dimension to
control the version of LeakCanary included.
Note that this turns off LeakCanary for builds produced by |mach
build|, because |mach build| always builds the official audience
flavor dimension. We could use MOZILLA_OFFICIAL to differentiate, but
it's not worth it: local developers who care about LeakCanary
will/should be running a local audience flavor dimension from Android
Studio.
MozReview-Commit-ID: ASgxhNOMsWc
--HG--
extra : rebase_source : a5de2b6fdaf92a1d91739ca0b480a9d04d434b8c
Gurzau Raul
Dão Gottwald
Grigory Kruglov
Jan Henning
Mike Conley
Narcis Beleuzu
Geoff Brown
Shane Caraveo
Ciure Andrei
Jim Chen
Tiberius Oros
Ryan VanderMeulen
Noemi Erli
Dustin J. Mitchell
Nick Alexander
Tad
Margareta Eliza Balazs
Eugen Sawin