1588257 - Telemetry histogram enum doesn't let me add DOM use counters for properties whose names differ only in case

Status: NEW

(Toolkit :: Telemetry, enhancement, P3)

Description

[Boris Zbarsky [:bzbarsky]]

I tried to add two DOM use counters with entries like so in UseCounters.conf:

method Window.defaultStatus
method Window.defaultstatus

This fails because TelemetryHistogramEnums.h just ends up with a single USE_COUNTER2_WINDOW_DEFAULTSTATUS_DOCUMENT entry and a single USE_COUNTER2_WINDOW_DEFAULTSTATUS_PAGE entry, and then static asserts in Document.cpp fail because the DOM use counter enum doesn't match the Telemetry histogram enum.

I guess I'll skip measuring one of those for now, but it sure would be nice to measure both...

Comment 1

[Chris H-C :chutten]

Well that's a use case that wasn't covered by USE_COUNTER2's design. Nice catch. Gonna +Cc Alessio on this so we catch this for any future Glean-powered Use Counter system.

Hm, what to do. To my knowledge, everything would explode if we introduced case sensitivity to Telemetry probes of any kind. (maaaaybe we could get away with it for Events, but I really recommend not trying even that). This means to solve this our USE_COUNTER2 system would need some kind of an encoding scheme for when it detected two counters that differ only in case. That'll require us to care about the order of UseCounters.conf to ensure we only apply the encoding to the newer (further down the file) of the two (in case the older of the two has history we wish to preserve by preserving its name).

This'll be a chunk of work. How much do you need this and how quickly?

Comment 2

[Boris Zbarsky [:bzbarsky]]

This isn't really blocking me in a serious way; I just figured I should get this on file. For now I added a use counter for just one of the two properties, and in this specific case we can also get a lot of the data we want out of Chrome's use counters for those same properties, so it's not a big deal.