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.
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.
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.
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.
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.
