Thanks for the input!
Alex, there's a question here from Romain I'd like your input on:
(In reply to Romain Testard [:RT] from comment #7)
(In reply to Adam Gashlin (he/him) [:agashlin] from comment #6)
I don't plan to do any authentication on the shortcuts to determine whether they were made by our installer, just to check the location (Desktop, Start Menu, Taskbar, other). It would be possible to check for the exact file name that the installer would have used, but I don't think that will be sufficiently helpful given how rare user-created shortcuts are likely to be, and there could be complications around brand name migrations over the years. I could make an effort to tag our shortcuts in such a way as to distinguish them from user-crated shortcuts, but it also doesn't seem worth the complication.
I'll defer to Alex here, unsure if the plan is to test efficiency of scenarios like telling users to right click on taskbar and create a shortcut VS us doing it on their behalf.
Alex? I still think that just checking the location of a shortcut will get us 99% of the information we need.
Also will we be able to segment out sessions that started from a launch of the executable directly as opposed to a shortcut?
The values would be:
- start menu shortcut
- desktop shortcut
- taskbar shortcut
- other shortcut
"other" covers a lot of ground (restarts, OS file type/protocol associations, etc.), but it does include launching the exe directly, and it does not include any kind of shortcut.
Do we want to send an event on every startup, whether Firefox was started from a shortcut or not? This could provide space for future extension along the lines of bug 1243603, and would provide some baseline of all startups. But without being able to distinguish most of the other ways Firefox starts up, e.g. restarts for updates, OS restarts, I'm not sure how useful it would be. I will plan on only sending the event if we are started with a shortcut, but I'll leave the event name generic so it could be naturally extended to other startup methods.
I think it would be useful for at least scenarios where Firefox starts as a result of being default handler for a specific protocol or file extension (both I "think") are feasible but not part of the scope of this bug).
Agreed, those are in principle possible, but let's leave them out for now.
The approach you suggest here would at least help quantify the 'other' bucket to help understand if we need to dig further on braking down what non shortcut initiated sessions are initiated from.
Note: installer telemetry tells us whether launching the executable from the stub was successful so perhaps this is a scenario that is technically addressable (telemetry to identify if Firefox was launched from the stub)
Ok, that makes sense. As Su-Young suggests below I'll use a scalar, but I'll still provide an "other" value so we can distinguish that from the scalar just not being set (e.g. after a subsession split).
(In reply to Su-Young Hong from comment #8)
Thanks for the update. Thoughts below:
For the "is the browser pinned in taskbar or not" telemetry:
- I'm not sure I understand the need to use a histogram here. You mentioned that this state (pinned, yes or no) is expected to change in a session, but I think it makes more sense to split this out into two separate measurements:
- Measurement 1:
is_pinned: (scalar), records once, and just tells us if it's pinned or not at the time of measurement
- Measurement 2:
pin_event: (event), fires off when there's a pinning event.
Splitting it out like this makes more sense for me from an analysis standpoint.
Ok, I can see the reasoning there.
Also, some thoughts on the shortcut-startup measurement:
- it sounds like you're planning to implement this as an event. any specific reason? it seems to me that having this as a scalar inside main pings makes sense. it would make analysis much more straightforward.
No great reason, I just added my first event so I've been somewhat in that frame of mind. If a scalar makes more sense I'll use that, thanks!