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 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
We concatenate JSMs together so we use less compartments and therefore
less memory. This is intended to be a temporary hack until the overhead
of compartments is less.
We have introduced a new background service that captures session state
in preferences. Firefox Health Report now moves entries from preferences
to its database at payload generation time.
We've also introduced a few random APIs, such as enqueueTransaction()
and the ability for providers to have access to their own pref branch.
Wes Kocher
Georg Fritzsche
Gregory Szorc
Blair McBride
Nick Alexander
Richard Newman