Closed Bug 1518669 Opened 1 year ago Closed 1 year ago

gfx.omtp.paint_wait_ratio telemetry has expired


(Core :: Graphics: Layers, defect, P3)

40 Branch



Tracking Status
firefox66 --- fixed


(Reporter: erahm, Assigned: rhunt)




(2 files)

+++ This bug was initially created as a clone of Bug #1386968 +++

The gfx.omtp.paint_wait_ratio telemetry scalar has expired and is now causing debug test (and local) log spam:

WARNING: NS_FAILED internal_GetScalarByEnum for CHILD: file /var/dev/erahm/mozilla-unified/toolkit/components/telemetry/core/TelemetryScalar.cpp, line 2161

The warning itself isn't super helpful, but I was able to track down the expired scalar by debugging.

Ryan, it looks like you "own" this scalar.

Flags: needinfo?(rhunt)

Oh. I was getting that log spam and was really annoyed by that. I guess it's my fault :)

I'll try and get it renewed, it's pretty useful for detecting regressions.

Assignee: nobody → rhunt
Flags: needinfo?(rhunt)
These performance probes are important to monitor regressions to our current
painting code's performance. I'd like to make them never expire as we don't
forsee not wanting to know this information.

Chris, would renewing these telemetry probes and moving them to not expire require a data review?

Flags: needinfo?(chutten)

It does!

Flags: needinfo?(chutten)
Attached file omtp-data-review.txt

Sounds good.

Attachment #9035748 - Flags: review?(chutten)

Comment on attachment 9035748 [details]

Preliminary notes:

For never-expiring probes it is a good idea to have automated tests ensuring they continue to work into the future.


Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes. These collections are Telemetry so are documented in their definitions files (Histograms.json, and Scalars.yaml), the Probe Dictionary, and on's Measurement Dashboards.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. These collections are Telemetry so can be controlled through Firefox's Preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, rhunt is responsible.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, Technical.

Is the data collection request for default-on or default-off?

Default-on, prerelease channels only.

Does the instrumentation include the addition of any new identifiers?


Is the data collection covered by the existing Firefox privacy notice?


Does there need to be a check-in in the future to determine whether to renew the data?

No. These collections are being made permanent.

Result: datareview+

Attachment #9035748 - Flags: review?(chutten) → review+
Pushed by
Move some OMTP performance probes to never expire. r=me, data-review=chutten
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
You need to log in before you can comment on or make changes to this bug.