|getReportsForThisProcess| differs from |getReports| in that it is limited to current process and is synchronous. When asynchronous memory reporters are added the function will no longer be able tobe synchronous. There isn't much utility in only measuring the current process, so we can remove the function and switch existing users to |getReports|.
The calculation of |explicit| relies on the synchronous |getReportsForThisProcess|, once we have asynchronous reporters this will no longer work. As it is currently referenced in the about::memory tests we can just remove it.
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
By making the updated system add-on install location return an empty set when
in safe mode it causes us to rescan and enable the default system add-ons.
The complication is calling the uninstall method on the updated add-ons when
switching to safe mode, for that we have to cache the fact that an add-on
can run in safe mode in the bootstrappedAddons data so it persists to the
next restart and can be accessed when the updated add-on has been hidden.
--HG--
extra : commitid : 2BJfLTeXSwu
extra : rebase_source : 79d6df358d6cec2d5e4b8df265a56da049d6fd58
byron jones
Wes Kocher
Shu-yu Guo
Eric Rahm
Carsten "Tomcat" Book
Phil Ringnalda
Kit Cambridge
Gijs Kruitbosch
Mike Conley
Matthew Noorenberghe
Bob Owen
J. Ryan Stinnett
Luca Greco
Gervase Markham
Nicholas Nethercote
Michael Layzell
Kate McKinley
Gabor Krizsanits
Nick Alexander
Justin Dolske
Dave Townsend
Florian Quèze