Determine how to migrate histograms that clear themselves in non-test code: PWMGR_* in _gatherTelemetry()
Categories
(Toolkit :: Password Manager, task, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox137 | --- | fixed |
People
(Reporter: chutten, Assigned: chutten)
References
Details
(Whiteboard: [fog-migration])
Attachments
(1 file)
In our effort to migrate histograms to use Glean APIs in bug 1935420 we've found some uses of the JS per-histogram clear()
API in non-test contexts. We're not entirely certain what to do about these uses without the aid of the people who own them.
For this bug we're specifically looking at the histograms being written to in _gatherTelemetry()
in LoginManager.sys.mjs:
PWMGR_BLOCKLIST_NUM_SITES
PWMGR_NUM_SAVED_PASSWORDS
PWMGR_NUM_HTTPAUTH_PASSWORDS
PWMGR_SAVING_ENABLED
PWMGR_USERNAME_PRESENT
PWMGR_LOGIN_LAST_USED_DAYS
PWMGR_NUM_PASSWORDS_PER_HOSTNAME
Some questions:
- Are the data generated by these instrumentation in use?
- Because if they're not, we can just remove them and be on our merry way.
- Can we encode this data in a different way to continue satisfying the same uses, or is it important that they all e.g. remain histograms despite holding single values?
- If we can, then we'll move these to Scalars if you'd like them to remain in Legacy Telemetry, or just to Glean if you don't need them in there any more.
- We'll need to decide about
PWMGR_NUM_PASSWORDS_PER_HOSTNAME
independently since it does actually record multiple values, albeit in a very non-histogram way -- if its data is important to keep static independent of the frequency that_gatherTelemetry
is called, we've got some work ahead of us.
:mkmelin, as someone who has touched this file somewhat recently, would you happen to know the answers to these questions? Or to whom we should instead direct them?
Comment 1•8 months ago
|
||
Unfortunately I know very little about it. I don't think Thunderbird cares about this telemetry data.
Passing the buck (wild guess)
Comment 2•8 months ago
|
||
Thanks! Let me check with the team to see what we want to do with this telemetry.
One question: Chris do you know when and how often this idle-daily notification is dispatched to the main thread?
Updated•8 months ago
|
Assignee | ||
Comment 3•8 months ago
|
||
"idle-daily"
is notified the first 3min-wide idle period that is 24h after the previous "idle-daily"
notification, at least according to my reading of this code.
(( Now, I did also in looking this up just find that DiscoveryStream might also notify on its own recognizance for some reason? I haven't found anything that actually triggers that, so maybe this is dead code. But still. Wow. ))
So, in full, "gather-telemetry"
should happen once a day, tops. But also note the comment: it shouldn't matter overmuch how frequently it happens because it'll stop happening at all as soon as bug 1127907 lands. Which I'm sure will be any decade now.
Assignee | ||
Updated•8 months ago
|
Assignee | ||
Updated•7 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
Assignee | ||
Comment 4•6 months ago
|
||
:mtigley in conversation on Slack agrees that we could delete the existing probes entirely so long as we still report the number of passwords somewhere, especially if solely in Glean.
I hope to have a patch that does this up soonish.
Assignee | ||
Comment 5•6 months ago
|
||
PWMGR_SAVING_ENABLED and PWMGR_NUM_SAVED_PASSWORDS are removed,
with Glean alternatives implemented. The new metrics always have the correct
value and will report them in every "metrics" ping.
PWMGR_BLOCKLIST_NUM_SITES, PWMGR_NUM_HTTPAUTH_PASSWORDS,
PWMGR_USERNAME_PRESENT, PWMGR_LOGIN_LAST_USED_DAYS, and
PWMGR_NUM_PASSWORDS_PER_HOSTNAME are merely removed.
Backed out for causing causing mass failures.
Assignee | ||
Comment 9•6 months ago
|
||
Oh, LoginHelper
is used on child processes? Okay, should just be a one-line fix.
Comment 10•6 months ago
|
||
Comment 11•6 months ago
|
||
bugherder |
Description
•