Use counters are used to report Telemetry statistics on whether individual documents use a given WebIDL method or attribute (getters and setters are reported separately), CSS property, or deprecated DOM operation. Custom use counters can also be defined to test frequency of things that don’t fall into one of those categories.
The process to add a new use counter is different depending on the type feature that needs to be measured. In general, for each defined use counter, two separate boolean histograms are generated:
- one describes the use of the tracked feature for individual documents and has the
- the other describes the use of the same thing for top-level pages (basically what we think of as a web page) and has the
Using two histograms is particularly suited to measure how many sites would be affected by removing the tracked feature.
- Site X triggers use counter Y. We report “used” (true) in both the
- Site X does not trigger use counter Y. We report “unused” (false) in both the
- Site X has an iframe for site W. Site W triggers use counter Y, but site X does not. We report one “used” and one “unused” in the individual
_DOCUMENThistogram and one “used” in the top-level
Deprecated DOM operations¶
Use counters for deprecated DOM operations are declared in the nsDeprecatedOperationList.h file. The counters are
registered through the
DEPRECATED_OPERATION(DeprecationReference) macro. The provided
parameter must have the same value of the deprecation note added to the IDL file.
See this changeset for a sample deprecated operation.
The UseCounters registry¶
Use counters for WebIDL methods/attributes and CSS properties are registered in the UseCounters.conf file. The format of this file is very strict. Each line can be:
- a blank line
- a comment, which is a line that begins with
- one of four possible use counter declarations:
method <IDL interface name>.<IDL operation name>
attribute <IDL interface name>.<IDL attribute name>
property <CSS property method name>
custom <any valid identifier> <description>
The CSS property method name should be identical to the
method argument of
CSS_PROP() and related macros. The only differences are that all hyphens are removed and CamelCase naming is used. See ServoCSSPropList.h for further details.
Custom use counters¶
The <description> for custom counters will be appended to “When a document ” or “When a page “, so phrase it appropriately. For instance, “constructs a Foo object” or “calls Document.bar(‘some value’)”. It may contain any character (including whitespace). Custom counters are incremented when SetDocumentAndPageUseCounter(eUseCounter_custom_MyName) is called on an ns(I)Document object.
WebIDL methods and attributes¶
Additionally to having a new entry added to the UseCounters.conf file, WebIDL methods and attributes must have a
[UseCounter] extended attribute in the Web IDL file in order for the counters to be incremented.
Both additions are required because generating things from bindings codegen and ensuring all the dependencies are correct would have been rather difficult, and annotating the WebIDL files does nothing for identifying CSS property usage, which we would also like to track.
The processor script¶
The definition files are processed twice:
- once to generate two C++ headers files, included by the web platform components (e.g. DOM) that own the features to be tracked;
- the other time by the Telemetry component, to generate the histogram definitions that make the collection system work.
The histograms that are generated out of use counters are set to never expire and are opt-in.
This script is called by the build system to generate:
PropertyUseCounterMap.incC++ header for the CSS properties;
UseCounterList.hheader for the WebIDL, out of the definition files.
Interpreting the data¶
The histogram as accumulated on the client only puts values into the 1 bucket, meaning that
the use counter directly reports if a feature was used but it does not directly report if
it isn’t used.
The values accumulated within a use counter should be considered proportional to
here). The difference between the values of these two histograms
and the related use counters below tell us how many pages did not use the feature in question.
For instance, if we see that a given session has destroyed 30 content documents, but a
particular use counter shows only a count of 5, we can infer that the use counter was not
used in 25 of those 30 documents.
Things are done this way, rather than accumulating a boolean flag for each use counter, to avoid sending histograms for features that don’t get widely used. Doing things in this fashion means smaller telemetry payloads and faster processing on the server side.