1730040 - Remove or update probes expiring in Firefox 95: PLACES_BOOKMARKS_TOOLBAR_RENDER_DELAY_MS

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, task)

Description

[telemetry-probes]

The following Firefox probes will expire in the next major Firefox nightly release: version 95 [1].

PLACES_BOOKMARKS_TOOLBAR_RENDER_DELAY_MS

What to do about this:

1. If one, some, or all of the metrics are no longer needed, please remove them from their definitions files (Histograms.json, Scalars.yaml, Events.yaml).
2. If one, some, or all of the metrics are still required, please submit a Data Collection Review [2] and patch to extend their expiry. There is a shorter form for data collection renewal [3].

If you have any problems, please ask for help on the #data-help Slack channel or the #telemetry Matrix room at https://chat.mozilla.org/#/room/#telemetry:mozilla.org. We'll give you a hand.

Your Friendly, Neighborhood Telemetry Team

[1] https://wiki.mozilla.org/Release_Management/Calendar
[2] https://wiki.mozilla.org/Firefox/Data_Collection
[3] https://github.com/mozilla/data-review/blob/master/renewal_request.md

This is an automated message sent from probe-scraper. See https://github.com/mozilla/probe-scraper for details.

Comment 1

[Marco Bonardo [:mak]]

This was added in bug 1680216, I don't know how this data has been used, or whether we should keep it to check for regressions. Gijs may be able to answer that question, but he's out for a few days.
Looking at the dashboard there's about a 1% of cases where it seems to take longer than I'd expect.

Comment 2

[:Gijs (he/him)]

I'm a bit torn on what to do here. I don't really have time to chase making this situation better right now myself. Async places views is still a while off, I believe, though IIRC there are still some relatively low-hanging-fruit ways of making this a little bit better than it is now, I'm not sure they'd address the "bad" cases here.

In the intervening time I'm not sure whether the telemetry is serving a purpose. I think the original aim was establishing whether the delay was going to be significant to the point that we Needed To Do Something Immediately, which I guess so far it hasn't been. Marco, you noted that in about 1% it takes a long time - do you think that's worth spending more time on, and if so, is this probe the right way to do that investigation, and/or how do you feel about next steps here?

Comment 3

[Marco Bonardo [:mak]]

Long term, having a probe to measure time we take to render the toolbar would be useful to detect regressions. But this is not that, we already have FX_BOOKMARKS_TOOLBAR_INIT_MS for that.

IIUC, this measures how much time elapses from first-contentful-paint to the toolbar being initialized. This doesn't tell us whether the toolbar itself was slow, but more whether it appears late. This will also include any third party influence (system busy, something else taking up cpu/gpu in Firefox). Those > 4s cases could be anything.

That limits the usefulness of this for bookmarks, because it only tells us whether we should add a "throbber/skeleton" like thing. But at that point couldn't we use a similar method to tell "if more than X time passed, show a throbber"?
This seems a measurement that is more useful for the skeleton ui development than to bookmarks, personally I'd remove it, because I don't see a value to keep it long term, but I'm ok asking that question to someone who worked on the skeleton ui. So I'm neddinfo-ing Doug to get his opinion.

It did its job anyway, telling us that a couple seconds are not so uncommon, and there's pathologic cases taking more than 4 seconds.

Comment 4

[Alex Thayer [:alexical] (she/her)]

Ack, sorry for the delay on this. Just a quick call out that whatever skeleton UI we might implement here would have to be unrelated to the current skeleton UI from a technical perspective. Though we'd probably want to keep visual similarity here, the current skeleton UI is implemented by drawing raw pixels to a buffer, whereas whatever we do here would be in XUL.

In any case I don't have a huge interest in this probe right now, so given what you all are saying it seems fine to just get rid of it? Do we expect its output to change substantially in the future, or do we kind of already have whatever information we need from it?

Comment 5

[:Gijs (he/him)]

Attachment: Bug 1730040 - drop PLACES_BOOKMARKS_TOOLBAR_RENDER_DELAY_MS probe, r?mak

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4ca3428ff5d0
drop PLACES_BOOKMARKS_TOOLBAR_RENDER_DELAY_MS probe, r=mak

Comment 7

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/4ca3428ff5d0