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.
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.
The data reporting notification was over-complicated. It wasn't
displayed for +24hr after first run and it had a weird, non-required
policy around what constituted acceptance of the policy.
The notification is now shown shortly after first startup.
The logic around "notification accepted" has been greatly simplified by
rolling it into "notification shown." Where we once were checking
whether the notification has been "accepted," we now check whether it
has been displayed. The overly complicated logic around the implicit
acceptance of the policy has also been removed.
The end result is the code for managing the state of the notification is
greatly simplified.
The data reporting notification was over-complicated. It wasn't
displayed for +24hr after first run and it had a weird, non-required
policy around what constituted acceptance of the policy.
The notification is now shown shortly after first startup.
The logic around "notification accepted" has been greatly simplified by
rolling it into "notification shown." Where we once were checking
whether the notification has been "accepted," we now check whether it
has been displayed. The overly complicated logic around the implicit
acceptance of the policy has also been removed.
The end result is the code for managing the state of the notification is
greatly simplified.
--HG--
extra : rebase_source : 808efdf1edd103552f6aa10b5c4309b64e514773
extra : amend_source : e4252e6a850a348d1b5aca733121dd07cbc6a70a
extra : histedit_source : 10ec20a07677674a8c9a705a3ffb4dc46a22b890%2Ca9442934d5964f16e9ad1101b786b4d094ac228d
The upcoming build system patches don't support hypthens in path names.
Changing this for that reason is kind of silly, but it's the easiest
way. Besides, nothing else uses hyphens in directory names.
--HG--
extra : rebase_source : 42dda2b1f16a3c0bfe17397a70092362e400530f
Previously, it was technically possible for the FHR client to have
multiple simultaneous uploads. While this should never occur in
well-behaving systems, server logs have indicated that this behavior
might be occurring.
This patch adds a lock around uploading to ensure only 1 upload
operation may be active at a given time.
To measure the impact of this change in the wild, we added a counter
that increments whenever a held lock is encountered.
--HG--
extra : rebase_source : f0bb5065a3618cd335b6b6f31e4e68850f31f151
The error message comes from abouthealth.js not checking if a variable
is null before access. That bug is fixed.
However, the underlying issue of "the reporter is null" still remains.
Logging has been added to hopefully catch issues. The signature of the
failure will change.
--HG--
extra : rebase_source : bc887406a3570a767bae5407b5836314157ac421
extra : amend_source : f22cad2eae46bd08ae25a7d376fbf8e2d1d0ea92
