mozilla / probe-dictionary

Tool that makes Firefox Telemetry probe information searchable

probe-dictionary

A tool that makes the Telemetry probe data in Firefox more discoverable and searchable.

This front-end allows answering questions like

• "do we have any probes in Firefox 55 that tell us about tab usage?"
• "which Firefox versions is this probe in anyway?"

To achieve this, it uses data extracted by the probe-scraper project. This pulls probe registry files (Histograms.json, Scalars.yaml, Events.yaml) from different Firefox versions together into one dataset. Also, probes outside of Histograms.json - like the CSS use counters - are included in the output data.

Currently this supports:

• release, beta & nightly channels
• major releases only
• all probes registered in separate files (histograms, scalars, events)
• some select environment data points (more to come)

This project was bootstrapped with Create React App.

Development

To run locally:

run npm start To launch the cypress test runner: run npm run test

The production data endpoints should work just fine locally.

probe-dictionary's Issues

probe dictionary version expiry inconsistent / unclear

I was trying to figure out when this probe expired:

https://telemetry.mozilla.org/probe-dictionary/?search=preferences&detailView=histogram%2FFX_PREFERENCES_CATEGORY_OPENED_V2

The page above says:

Recorded in versions:
beta 54 to 58, nightly 55 to 58, release 54 to 58
Expiry:
beta stopped recording in 66, nightly stopped recording in 66, release stopped recording in 66

After some help from chutten and tdsmith, this bug indicates that it indeed expired in 66, yet the most recent valid version is FF64.

I believe the recorded in versions section is mistake, however it also wasn't clear without that bug as a reference that I needed to filter my data to version 64.

Possibly incorrect recording range for probe

The active_ticks scalar was never uplifted, but shows up as starting on Nightly 56 & Beta 55.

This was around the Project Dawn cycle, so something around the version tracking there might be special.

HDD binary model says "Available in: hardware report - view what hardware and operating systems Firefox users have." although not visible in hardware report.

https://telemetry.mozilla.org/probe-dictionary/?detailView=environment%2Fsystem.hdd.binary.model
there is says "Available in: hardware report - view what hardware and operating systems Firefox users have."
but when visiting https://data.firefox.com/dashboard/hardware , there are no HDD statistics visible.

Modernize the front-end code

Currently the front-end code here uses plain JS + some jquery.
We should use a more modern frame-work (Angular, React, Vue).

Use bootstrap loading bar

After #1 is done, we should be able to use the bootstrap loading bar (instead of the current gif-based solution).

Improve the C++ guard display

In the detail view, the C++ guard field:

• should move further down
• show e.g. italic "None" when its empty

Clean up references to `aurora`

The probe scraper is not scraping aurora data anymore. I think we can get rid of the various special case handling within explore.js.

Back/Forward breaks if you close details with the 'x'

STR:

1. Open a detail view
2. Click 'x' to close
3. hit the browser back button.

Basically 'x' needs to pop the history state.

Remove error "Bootstrap tooltips require Tether"

After #1 we see an error in the console:

Error: Bootstrap tooltips require Tether (http://tether.io/)

We should either avoid triggering it or just add Tether.

Linkify URLs in descriptions

Add row to Details view for links to DXR & searchfox searches for the probe name

For Environment stuff direct them to TelemetryEnvironment.jsm

Histograms will probably mostly work except for ones composed by macro (some families of networking probes do this)

Scalars are often composed from category&name, javascript collections can be more easily composed, so links to searches may not be as helpful.

Events... events may be tricky.

Detail view never shows bug numbers

In the detail view of a probe, e.g. A11Y_CONSUMERS, no bug numbers are shown.

They should be.

Toolbar apparently inoperative when viewing a probe

STR:
Search for a probe, pick one.
Click the "Stats" button at the top.

Expected:
Something happens

Actual:
Nothing happens until you click the tiny x up in the far right corner.

This looks and behaves very much like a new page, except for that little x. But the change in style does not hint at the presence of the x and I completely missed it. I then wondered why I couldn't see anything.

Remove reference to main summary for events

Events have not been on the main ping since we started sending the main ping, and newer events will never show up there. We should remove the reference to main_summary on event detail pages since the events dataset includes events from both main and event pings

Show "last update" in the users local time

Currently we just add the "last update" value directly to the page.
Per this the value should now be a full ISO date string, including the time.
We should show it as the users local date & time (probably with just a precision of minutes).

Clean up repository layout & contents

The only used code in this repository is in data/.
The other parts got moved over to the probe-scraper project and can be removed.
This means we can just move the contents of data/ to the top level of the repository.

react: pull probe data from probe info service

Rather than the stale JSON fixtures served from my personal domain. May need to consult with Jason as needed.

Find new location for link to GitHub project

We are dropping the GH banner in #1.
Maybe we can instead link to the project page in the top bar somewhere?

Change the API endpoint to https://probeinfo.telemetry.mozilla.org/

The probe dictionary needs to use the new API endpoint, as the old one might end up not being updated.

Extend the `environment.json` file

We should add the missing environment data (see here) to the environment.json file

Use MetricsGraphics.js on stats page

Display the updated expiry version for histograms that were updated

The expiration for the WEBEXT_BACKGROUND_PAGE_LOAD_MS probe was extended to 67 on May 2.
However, its entry in the probe dictionary still reports a recorded in versions "nightly 55 to 62" instead of "nightly 55 to 67".

Add bucket label information to histogram details

Once we have detail views of probes per #2, we should add information about their bucket labels.
Currently there is no easy obvious place to get them (although the simulator happens to show them if you enter all the right parameters).

Confusing or wrong version information about probe

I might be incorrectly reading the dictionary, but INPUT_EVENT_RESPONSE_COALESCED_MS claims that it was recorded in versions "release 54 to 60". It seems to still be recorded in 64 - in fact the dictionary (correctly) says that "release never expires" which is consistent with the source.

Am I misinterpreting what "Recorded in versions" means or is it wrong?

Make the header links more discoverable

It's hard to find the "Find probes" and "Stats" links at the top of the page. We should make them more discoverable (e.g. underline them).

Remove reference to main summary for events

Events have not been on the main ping since we started sending the main ping, and newer events will never show up there. We should remove the reference to main_summary on event detail pages since the events dataset includes events from both main and event pings

#53

Implement the Probe Dictionary in React

This is a bug to track the status of the already opened PR: #58

The original request was made by @georgf with @chutten taking later ownership. Much of the probe filtering/details functions were implemented almost verbatim (without jQuery this time) so any behavior/bugs might still persist.

Share JS code between stats and search page

Currently the stats and search page use completely separate code, explore.js and stats.js.

Much of the setup & filtering code should actually be shared though.

Add more data to the detail view

Add more data to the detail view, specifically:

• probe owners / emails
• bug numbers
• categorical labels
• version range this is recorded in

Link to the source revision & file

Link to the specific revision of the source files (e.g. Histograms.json) that data came from.

Probe Dictionary Shouldn't Include Measurement Dashboard Links for Data That Won't Show Up

It'll 404 in the backend and will display nothing helpful, so we might as well omit the link.

"Add a keyword for this search" uses `?text_search=` instead of `?search=`

In the React version, if you right-click>Add Keyword for this Search>(then provide a keyword). That keyword search in Firefox will have the pattern https://probe-dictionary.herokuapp.com/?text_search=%s

Which is a problem because the actual query param for the search term is search, not text_search

Add pagination

As the number of probes we need to show grows (especially as we remove the probe filtering as specified in #67) the size of the DOM for a probe dictionary page grows, negatively impacting performance and user experience. Adding pagination to the UI will help resolve this issue.

Describe which stores pings are collected in to

It's now possible to collect probes into different stores, like the new-profile and main stores. It would be useful for the probe dictionary to be able to display that information.

Wiki changes

FYI: The following changes were made to this repository's wiki:

• defacing spam has been removed

• Restricting write access to contributors is strongly encouraged. Please make that change (documentation).

These were made as the result of a recent automated defacement of publically writeable wikis.

Use basic bootstrap style

The current style is pretty incidental/basic; we should make this use the basic bootstrap style instead.

New probes (only on Nightly or Beta) are not being rendered when searching

When filtering the probes by name (searching), if a channel is not explicitly set (i.e. is set to any), probes that are not on the release channel are not being displayed.

This is is due to the rendering code assuming that the probes are on all channels and not wanting to display multiple entries for the same probe.

Move this project to an official Mozilla repository

With #1 and #10 resolved, this project is starting to look much better.
I think after #5 we should move this to an official Mozilla repository.

CODE_OF_CONDUCT.md file missing

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

Add recorded processes to Histogram detail views

It looks like the recorded processes data is missing from the probe-scraper data.
We should add this and show it in the detail views.

Remove probe filtering based on datasets.json

In the older probe dictionary, the datasets.json file was used to specify the subset of probes that the dictionary should expose. Now that we've moved to the GCP infrastructure, all of the probes are available in our data sets, so we no longer need this filter... the probe dictionary should expose all of the probes. The means we no longer need the datasets.json mechanism to specify which probes should be shown.

Add is_equal as a constraint

This will support exact match for links when we know the probe name.

Show more probe details

Currently we only show the probe info details that are available in the list view.
However, the backing data actually has more details.

We can just add a "(+)" button or similar, that shows a detail view for each probe, with all the detail from the backing data.

A first cut could just show the data in <probe id>/history/<channel>/details.
Later (in a separate issue) we could maybe expand this to actually show the probe details across channels.

Multiple search terms would be nice

I can search for probes with the word video in any text field and get a number of results.

I can search for probes with the word time in any text field and get a number of results.

However when I type video time, video and time, or video & time I get no results. I presume because no text fields contain those literal phrases, not because there are no probes with both the words video and time.

Sticky search results table header

In the search results, it would be great if the table header is always in view, no matter where you scroll to.

Sort channel+ver lists to have nightly,beta,release order

At present the "Recorded in versions" and "Expiry" rows in the details view order their channels alphabetically: beta, nightly, release.

I'm thinking we should custom-sort these to nightly, beta, release to match train order.

Add categorical histogram lables to UI

In mozilla/probe-scraper#111 we updated the probe scraper to include the labels for categorical histograms. They can be found in the details object of the JSON. This should be included in the UI for categorical histograms.

Add "see also" link for addons etc.

We recently added more environment data, including addons.

This and other environment data can be objects or arrays, that contain multiple items with more properties. E.g. entries in addons.activeAddons[addonId] have multiple properties like

• addons.activeAddons[addonId].appDisabled
• addons.activeAddons[addonId].installDay

It would be great for discovery, if we could show a link to "show me all of the addons.activeAddons properties".
I propose that in detail views like the one for addons.activeAddons[addonId].appDisabled, we show a new row called "See also", which has a link to "All properties for addons.activeAddons[addonId]".

For Glean, we should support markdown in a probe's description

Glean doesn't restrict how to format the text description of a probe.
It would be nice to support rendering Markdown, when displayed in the probe-dictionary.
The glean_parser is already able to generate a Markdown document from the defined metrics (e.g. see metrics.md of Fenix). If there's markdown-like syntax in the description it will be unescaped in the generated docs.

I leave it to you whether we need to take any precautions in filtering anything (e.g. don't allow images or raw html tags).
For now probe-dictionary only covers Mozilla products, so we have control over what's in there.

(This is moving Bug 1561597 to the right project).

Only show URL params that have non-default values

We store a lot of values in the URL params. We could greatly shorten the links if we only use params for non-default values.