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
