This patch adds support for value arrays to the internal_JSHistogram_Add method.
The histogram.add() js method can now be called with a single value or an array of values.
The accumulation is "all-or-nothing", i.e. if there is even a single invalid value in the
array, then nothing is accumulated.
The logic for type checking arguments before accumulation has been moved into a separate
function: internal_JSHistogram_CoerceValue. This function can also be used for
internal_JSKeyedHistogram_* methods in the future. This patch includes logic for clamping
values greater than UINT32_MAX to UINT32_MAX.
Added xpcshell tests in telemetry/tests/unit/test_TelemetryHistograms.js to check functionality.
Before Firefox 58 we collected extended collection from users on nightly,
aurora, and beta. Then we had to change things (see bug 1406391).
In doing so, we accidentally stopped receiving data from "release candidate"
beta builds. This patch resumes that collection by detecting an RC build as
having a MOZ_UPDATE_CHANNEL of "release", but an app.update.channel of "beta"
MozReview-Commit-ID: 3EzzDtQj8Kw
This patch adds data collection for 6 different data points:
- number of live bookmarks the user has
- number of times the user subscribes to a feed
- number of times we attempt to open feed preview
- number of times the user opens a feed popup in the UI
- number of times the user opens an entry from a feed popup in the UI.
MozReview-Commit-ID: DG9JDFXCjai
We need to clamp accumulations to fit in our data representation (int). This
patch records the number of times, and for which probes, we had to do so.
MozReview-Commit-ID: GSs3oFvLKlL
Internally Histograms use int, which is signed.
Our API uses uint32_t, which is not.
Our JS API uses ToUint32, which takes provided values modulo UINT32_MAX.
This patch consolidates behaviour so that all values greater than INT_MAX will
be correctly recorded in the highest bucket of a Histogram... instead of
having values between INT_MAX and UINT32_MAX end up as 0s, and values above
UINT32_MAX being taken modulo UINT32_MAX, but only from the JS API.
MozReview-Commit-ID: CzaaNZkPEji
On macOS, the paths for the special directories `GreD` (Resources) vs. `GreBinD`
(MacOS) are different. On other platforms, they are the same.
With scalar loading for artifact builds, we need to load a file from
`Resources`, so `GreD` should be used for this case.
MozReview-Commit-ID: 91JFwOISQCk
On macOS, the paths for the special directories `GreD` (Resources) vs. `GreBinD`
(MacOS) are different. On other platforms, they are the same.
With scalar loading for artifact builds, we need to load a file from
`Resources`, so `GreD` should be used for this case.
MozReview-Commit-ID: 91JFwOISQCk
Provides an optional resolver mechanism for Firefox that allows running
together with or instead of the native resolver.
TRR offers resolving of host names using a dedicated DNS-over-HTTPS server
(HTTPS is required, HTTP/2 is preferable).
DNS-over-HTTPS (DOH) allows DNS resolves with enhanced privacy, secure
transfers and improved performance.
To keep the failure rate at a minimum, the TRR system manages a dynamic
persistent blacklist for host names that can't be resolved with DOH but works
with the native resolver. Blacklisted entries will not be retried over DOH for
a couple of days. "localhost" and names in the ".local" TLD will not be
resolved via DOH.
TRR is preffed OFF by default and you need to set a URI for an available DOH
server to be able to use it. Since the URI for DOH is set with a name itself,
it may have to use the native resolver for bootstrapping. (Optionally, the
user can set the IP address of the DOH server in a pref to avoid the required
initial native resolve.)
When TRR starts up, it will first verify that it works by checking a
"confirmation" domain name. This confirmation domain is a pref by default set
to "example.com". TRR will also by default await the captive-portal detection
to raise its green flag before getting activated.
All prefs for TRR are under the "network.trr" hierarchy.
The DNS-over-HTTPS spec: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-03
MozReview-Commit-ID: GuuU6vjTjlm
Disk corruption can lead to the stored length of a value to be
unreasonably large and trigger an OOM.
Since values are all currently <= 32 bytes, we can safely enforce
a 256-byte upper bound.
MozReview-Commit-ID: XygReOpEK3
bug 1397293 introduced a mechanism by which we would bail out early in trying
to send a ping if we were trying to send it after the network had been torn
down.
Unfortunately, it did so indistinguishably from the case where we weren't
allowed to send pings, so we neglected to save the ping (as "pending") and
just archived it.
This change cleanly rejects the ping, and correctly tests that the rejected
ping is persisted, not just ephemerally hanging in memory for but a few moments
longer.
MozReview-Commit-ID: 2g8cpeBEzSE
