The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
The regression is fixed by the backout of bug 1175354 and this
should ensure it doesn't happen again.
--HG--
extra : commitid : 7mVa6zNb0uq
extra : rebase_source : b83744e2fc37fbf41a1d91104861b3bc41c00a05
This will make the following SDKs, tools and libraries available:
* Android SDK 6.0 / API 23
* Android tools r24.4
* Android build tools 23.0.1
* Android Support Repository (Support Library 23.0.1)
* Google Support Repository (Google Play Services 8.1.0)
To support gradually switching the Android 5.1 SDK (API 22) and Android build tools 22.0.1
are still included in the linked archive.
--HG--
extra : commitid : ESkIoGj3q2f
extra : rebase_source : f30a24432876e839980a07fe4109b324f090c096
It's quite challenging to both wait for "load", and wait for something
to happen in the DOM, since the DOM isn't prepared until after "load"
has fired. This test therefore has a small race window: it is
possible that we could wait for the mutation only after the logins
have been loaded and the 'logins-list' DOM element is inserted. The
logging should be good enough to identify this case; and in practice,
this is very unlikely.
Since I was here, I converted this to use SpawnTask.js.
--HG--
extra : commitid : 1cCEXRuq146
extra : rebase_source : f458ec34f684bbdefa5794fcfb0b18b1ac6b0926
Right now, in response to "load" (on the window), we're:
1) updating the DOM to show the spinner;
2) loading the logins with a main-thread janking synchronous load;
3) updating the DOM to hide the spinner.
This is all on the main-thread, so we only see a layout and paint
after 3). Thus no interstitial is ever visible, and the logins list
pops in after a long delay.
This patch ensures that 2) occurs at least one layout after 1). This
allows a paint to occur with the interstitial visible. Since the
animated CSS spinner is carefully designed to hit the off-main-thread
animation pipeline, it animates smoothly even though the main-thread
janking synchronous load blocks JavaScript progress.
There is a small race window between the promises resolving and the
_logins member being accessed by the filter. It's not clear that this
was ever well guarded, so I haven't tried to mitigate.
--HG--
extra : commitid : 9nKfLhK3JOa
extra : rebase_source : 8eb67ac9322372aa6e049d7154542c31e9de0d43
This collects client-side fxa-content-server data. The data covers
only the about:accounts experience until:
* the fxa-content-server provides the LOADED message; or
* connection failure is observed.
Nota bene: a healthy fxa-content-server always delivers the LOADED
message! In future, we might want to timeout the load (and observe
said timeouts) separately.
We collect no data after the fxa-content-server LOADED message. The
intention is for the server-side metrics flow to capture the valuable
"bounce rate" metrics, since the fxa-content-server team are in
position to quickly improve the web-based UI flow.
The client-side data collected is intended to answer the following
questions:
1) How many remote content loads started;
2) How many loads completed;
3) What proportion of loads made it to the LOADED message, as opposed
to failed;
4) How long it took each successful load to observe the LOADED
message;
5) How long it took each failing load to observe failure.
All of these are keyed by the fxa-content-server endpoint path (like
'settings' or 'profile/avatar'), since I observe differences between
the time-to-LOADED for each endpoint path.
There is a privacy trade-off here. Mozilla is collecting data to
understand the user experience when about:accounts is connecting to
the specific fxa-content-server hosted by Mozilla at
accounts.firefox.com. However, we don't want to observe what
alternate servers users might be using, so we can't collect the whole
URL. Here, we filter the data based on whether the user is /not/
using accounts.firefox.com, and then record just the endpoint path.
Other collected data could expose that the user is using Firefox
Accounts, and together, that leaks the number of users not using
accounts.firefox.com. We accept this leak: Mozilla already collects
data about whether Sync (both legacy and FxA) is using a custom server
in various situations: see the WEAVE_CUSTOM_* Telemetry histograms.
--HG--
extra : commitid : 6ablpwYytrm
extra : rebase_source : bb04e263adf4fd34d36b51610ca170f3dd9c8328
This is hygiene that completes the set of paths through this part of
the code. If we wrapper.{init,retry}, we are guaranteed to have a new
promise; and now that promise will always be fulfilled. It is
technically possible, but not anticipated, for an in-flight promise to
be replaced. Such a situation should not occur, but if it does, the
obsolete promise will still exist but never be fulfilled (since
loading or errors only touch the most recent promise). Eventually it
will be safely garbage collected.
--HG--
extra : commitid : 9gE08vjgVdF
extra : rebase_source : b920d6c1ae45e28128fcc3702cba219d66f7b1ab
The new API for onReceivedError() has just been introduced in API 23 / Android 6.0.
However our minSdkVersion is 9 currently.
--HG--
extra : commitid : 7fnyh1z1PeS
extra : rebase_source : e3d2682b357a66027c9a33546c929b6bf7106255
extra : amend_source : c4545b7b0cb8fbf3866a53d1753849f0cdf5c10a
Right now, in response to "load" (on the window), we're:
1) updating the DOM to show the spinner;
2) loading the logins with a main-thread janking synchronous load;
3) updating the DOM to hide the spinner.
This is all on the main-thread, so we only see a layout and paint
after 3). Thus no interstitial is ever visible, and the logins list
pops in after a long delay.
This patch ensures that 2) occurs at least one layout after 1). This
allows a paint to occur with the interstitial visible. Since the
animated CSS spinner is carefully designed to hit the off-main-thread
animation pipeline, it animates smoothly even though the main-thread
janking synchronous load blocks JavaScript progress.
There is a small race window between the promises resolving and the
_logins member being accessed by the filter. It's not clear that this
was ever well guarded, so I haven't tried to mitigate.
--HG--
extra : commitid : IReBJuG3b15
extra : rebase_source : 6e14f7ad7419e334bafef4bc9f0ac4dcf4355b2a
extra : amend_source : 39e97f5d2cd0e13a691a78e4c65044d379076fa6
This bumps the NDK version to r10e.
Previously, we used brew to install android-sdk and a custom version
of android-ndk. That makes it hard to control the installed versions.
This installs from downloaded archives, which unifies the Mac OS X
approach with the straight-forward Linux approach.
--HG--
extra : commitid : E7hEqsyy8Gw
extra : rebase_source : 9ea27e7d2ae3fbaaa3efbabdd701521981bec877
extra : histedit_source : c07c80c50ac066dc6808e7ccf96f0bc14dc09df2
For popular modules used by many DevTools add-ons, add shim files which wrap the
modules and make them available at their previous location.
Each shim includes a deprecation warning to make devs and users aware of the
issue.
--HG--
rename : devtools/server/dbg-server.jsm => devtools/server/shims/dbg-server.jsm
rename : devtools/shared/client/dbg-client.jsm => devtools/shared/shims/dbg-client.jsm
extra : commitid : H7Y9k2ADf0u
extra : rebase_source : 2bd193ecd4f2baeb8b14c14c63884d3a318a0840
In a following patch, all DevTools moz.build files will use DevToolsModules to
install JS modules at a path that corresponds directly to their source tree
location. Here we rewrite all require and import calls to match the new
location that these files are installed to.
--HG--
extra : commitid : F2ItGm8ptRz
extra : rebase_source : b082fe4bf77e22e297e303fc601165ceff1c4cbc
The GMP manager uses a copy of the update service's url formatting code and has
since fallen out of sync. We'll also want to use the same formatting code for
the system add-on update checks so this just exposes it in a shared API.
I've moved the contents of UpdateChannel.jsm to UpdateUtils.jsm and exposed
formatUpdateURL there as well as a few properties that the update service still
needs access to.
UpdateUtils.UpdateChannel is intended to be a lazy getter but isn't for now
since tests expect to be able to change the update channel at runtime.
--HG--
extra : commitid : KsbH21csjH4
extra : rebase_source : bc7c08de1ec6e802261b8cd294d88ee2c4e75c2d
Rather than just add suport for a new homepage, I think it's wise that we add support for android preferences from distro files.
I've added support from within the preferences.json file, an example file would look like this:
{
"Global": {
"id": "sample",
"version": 1.0,
"about": "Sample Distribution"
},
"Preferences": {
"privacy.donottrackheader.enabled": true
},
"LocalizablePreferences": {
"browser.search.defaultenginename": "Bugzilla@Mozilla"
},
"AndroidPreferences": {
"homepage": "http://www.mozilla.com"
}
}
--HG--
extra : commitid : INGL1YVHSdf
extra : rebase_source : 8b0ebc5a94e653c86254232ca6c752f09602a4b7
extra : amend_source : b5627935333b0f1dbae8a9e76c427eef21c962ca
The GMP manager uses a copy of the update service's url formatting code and has
since fallen out of sync. We'll also want to use the same formatting code for
the system add-on update checks so this just exposes it in a shared API.
I've moved the contents of UpdateChannel.jsm to UpdateUtils.jsm and exposed
formatUpdateURL there as well as a few properties that the update service still
needs access to.
UpdateUtils.UpdateChannel is intended to be a lazy getter but isn't for now
since tests expect to be able to change the update channel at runtime.
--HG--
extra : commitid : FuPUB9X4oYJ
extra : rebase_source : cfcd31d7da5f5b636a2ec11546dbada973d681de
extra : histedit_source : 3df840dc502c6ee4177f1858920d1260e4dc27af
The new tar.xz file was produced by taking the existing file, removing
extras/*/support, and copying over the extras/*/m2repository from my
local machine. These directories are all the same across all
installs, to the best of my knowledge. I used |xz --compress| with no
additional options.
--HG--
extra : commitid : 3gSpjaOw7Xj
extra : rebase_source : 2cdc5039cc2046f8f716ca650f18d53e8d700877
extra : histedit_source : 52eeb368a09cf7a39af82dca1b85c173a101c070
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
The GeckoEditable instance doesn't change for each nsWindow instance.
However, because a GeckoInputConnection is associated with a GeckoView,
when we create a new GeckoView, we need to attach a new
GeckoInputConnection to the existing nsWindow's GeckoEditable. This
patch makes us do that inside nsWindow::Natives::Open by calling
GeckoEditable.OnViewChange.
This patch removes the GeckoEditable code in GeckoAppShell, and make
nsWindow create a GeckoEditable for itself when opening a window.
Instead of calling GeckoAppShell, nsWindow can now call GeckoEditable
methods directly.
InputConnectionHandler really doesn't belong in the gfx package, and
the code to call key event handlers really doesn't belong in LayerView.
This patch refactors things, so that InputConnectionHandler is renamed
to org.mozilla.gecko.InputConnectionListener, and the interface is now
used by GeckoView instead of by LayerView.
The PROCESS_OBJECT GeckoEvent is used to set the layer client object in
Gecko once Gecko is done loading. This patch converts it to a native
call in GeckoView.Window.
When we queue native calls in GeckoThread, we try to deduce the
types of the arguments through Object.getClass(). However, there are
cases where this could fail. For example, the argument could be null,
or could be a String instance but the parameter type is really
CharSequence.
This patch introduces a way to optionally include parameter types for
the queued call. When a passed-in argument is a Class instance, it is
treated as the type for the next queued parameter, and the next argument
is treated as the value for the queued parameter. For example,
> // Queue a call with CharSequence parameter, using a String argument.
> GeckoThread.queueNativeCall(..., CharSequence.class, "123");
> // Queue a call with String parameter, using a null argument.
> GeckoThread.queueNativeCall(..., String.class, null);
Deduction is still performed when the type is missing:
> // Queue a call with int, String, and boolean parameter.
> GeckoThread.queueNativeCall(..., 42, "123", true);
> // Queue the same call but with a null argument.
> GeckoThread.queueNativeCall(..., 42, String.class, null, true);
This commit is us getting out of our own way. We were specifying
-classpath twice, once in $(JAVAC) and once in java-build.mk. Only
the latter of these is active. This a problem for ANDROID_EXTRA_JARS
-- those JARs should be on the classpath and input to $(DX) -- and
JARs that should be on the classpath but *not* input to $(DX). This
commit removes the global flags to $(JAVAC) and adds
JAVA_{BOOT}CLASSPATH_JARS. This required some hijinkery moving
wildcards to moz.build files, but everything seems to work.
As well as clarifying some parts of the build, part 2 uses this work
to modify the classpath.
--HG--
extra : commitid : 25Ft0BFs88O
extra : rebase_source : 05e3d1da8d42fa89d06ef48baee17bb77df5bd59
extra : histedit_source : 95b82309aca15c5a3c5f5a0eafbdcf75c5e8dfc0
This patch also adds the new base (sic) library play-services-basement.
Note that the package names have changed too:
* play-services-base: com.google.gms -> com.google.gms.base
* play-services-basement: * -> com.google.gms
--HG--
extra : commitid : EcmxZA10rzV
extra : rebase_source : f39b361807a0b8227f3fb9a6d73e066241c8e36c
Carsten "Tomcat" Book
Wes Kocher
Nathan Froyd
Allison Naaktgeboren
Sebastian Hengst
Reuben Morais
Chenxia Liu
Michael Comella
Mark Finkle
Sebastian Kaspari
Mike Hommey
Sergej Kravcenko
vivek
Kalpesh Krishna
Ahmed Khalil
Nick Alexander
Phil Ringnalda
Justin Dolske
Jonathan Almeida [:jonalmeida]
slayerjain
Martin Thomson
Jordan Lund
Tooru Fujisawa
Jim Chen
Kartikaya Gupta
James Willcox
Fabrice Desré
Jean-Yves Avenard
Eugen Sawin
Martyn Haigh
Ehsan Akhgari
Margaret Leibovic
Panos Astithas
Bill McCloskey
J. Ryan Stinnett
Anirudh S
Christian Schmitz
Dave Townsend
Prateek Arora
Prabhjyot Sodhi
Josh Matthews
dominique vincent
Seth Fowler
Shu-yu Guo
Chris Peterson
Stephanie Ouillon
Chris Pearce
Jonathan Almeida [:jonalmeida]